WSS4J
  1. WSS4J
  2. WSS-146

Upgrade opensaml dependency to 2.x line

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.6
    • Component/s: None
    • Labels:
      None

      Description

      WSS4J has a dependency on opensaml 1.1. OpenSAML 1.1 is, for the most part, no longer supported (https://spaces.internet2.edu/display/OpenSAML/OS1Status).

      2.1 has been out for a while, and 2.2 was released in Oct. '08. The 2.x line is not backwards compatible with 1.1 so unfortunately it's not as simple as dropping in the newer jar.

      1. wss4j-1.5.8-saml.patch
        378 kB
        Todd Dunst
      2. wss4j_opensaml2.2.3.patch
        106 kB
        Brian McDonald
      3. wss4j_opensaml2.1.0.patch
        542 kB
        Wim Vandenhaute
      4. wss4j_opensaml2.1.0_correct.patch
        575 kB
        Wim Vandenhaute
      5. saml_port.patch.2
        139 kB
        Colm O hEigeartaigh

        Issue Links

          Activity

          Hide
          Wim Vandenhaute added a comment -

          I have made an effort on upgrading to opensaml 2.1.0. I have not used the SAML v1 token profile in a live environment yet but the unit tests are passing.

          There is some basic support for SAML v2 token profile, no message security is yet implemented for this.

          Show
          Wim Vandenhaute added a comment - I have made an effort on upgrading to opensaml 2.1.0. I have not used the SAML v1 token profile in a live environment yet but the unit tests are passing. There is some basic support for SAML v2 token profile, no message security is yet implemented for this.
          Hide
          Wim Vandenhaute added a comment -

          opensaml 2.1 patch with basic saml 2.0 support

          Show
          Wim Vandenhaute added a comment - opensaml 2.1 patch with basic saml 2.0 support
          Hide
          Brian McDonald added a comment -

          Wim, I also took a crack at adding opensaml2 support. I took a different approach though, wrapping both saml1 and saml2 assertions into a single wrapper object. It allows for fewer changes to how you use the library (just need to change SAMLAssertion -> AssertionWarpper for the most part)

          Like Wim, I too have the unit tests functioning, but don't have a comprehensive set of tests to ensure everything is still working properly. Note, I upgraded to v 2.2.3, xerces 2.9.1, and xalan 2.7.1.

          Wim, you didn't seem to include the new files in your patch (items you added to org.apache.ws.security.saml2).

          Show
          Brian McDonald added a comment - Wim, I also took a crack at adding opensaml2 support. I took a different approach though, wrapping both saml1 and saml2 assertions into a single wrapper object. It allows for fewer changes to how you use the library (just need to change SAMLAssertion -> AssertionWarpper for the most part) Like Wim, I too have the unit tests functioning, but don't have a comprehensive set of tests to ensure everything is still working properly. Note, I upgraded to v 2.2.3, xerces 2.9.1, and xalan 2.7.1. Wim, you didn't seem to include the new files in your patch (items you added to org.apache.ws.security.saml2).
          Hide
          Wim Vandenhaute added a comment -

          correction of previous patch, includes new saml2 source files

          Show
          Wim Vandenhaute added a comment - correction of previous patch, includes new saml2 source files
          Hide
          Wim Vandenhaute added a comment -

          Brian, nice to see another effort at this.

          Thanks for notifying I missed some files in the patch.

          Show
          Wim Vandenhaute added a comment - Brian, nice to see another effort at this. Thanks for notifying I missed some files in the patch.
          Hide
          Todd Dunst added a comment -

          Brian,

          Thank you so much for posting your patch! I have tried something very similar to your AssertionWrapper approach. but I am getting the following exception:

          java.lang.ClassCastException: org.apache.xerces.dom.ElementNSImpl

          in the org.apache.ws.security.util.WSSecurityUtil.prependChildElement call. I am running a test case which attempts to use the modified library with an Axis2 Soap client. I have also upgraded to v 2.2.3, xerces 2.9.1, and xalan 2.7.1. I see that you have added a toDOM() method to the SAMLUtil class, and that you call this method whenever you are converting your OpenSaml assertions to org.w3c.dom.Element. I am not doing this, and I am wondering if this is why I am getting the class cast exception?

          On another note, do you have a version of your custom WSS4J source with all of your changes applied that I could try out?

          Show
          Todd Dunst added a comment - Brian, Thank you so much for posting your patch! I have tried something very similar to your AssertionWrapper approach. but I am getting the following exception: java.lang.ClassCastException: org.apache.xerces.dom.ElementNSImpl in the org.apache.ws.security.util.WSSecurityUtil.prependChildElement call. I am running a test case which attempts to use the modified library with an Axis2 Soap client. I have also upgraded to v 2.2.3, xerces 2.9.1, and xalan 2.7.1. I see that you have added a toDOM() method to the SAMLUtil class, and that you call this method whenever you are converting your OpenSaml assertions to org.w3c.dom.Element. I am not doing this, and I am wondering if this is why I am getting the class cast exception? On another note, do you have a version of your custom WSS4J source with all of your changes applied that I could try out?
          Hide
          Brian McDonald added a comment -

          I manually modified the patch file before uploading and mistakenly caused a conflict with SAMLUtil. I'll upload a fixed patch later today with instructions for applying the patch to a clean 1.5.4 source download.

          Show
          Brian McDonald added a comment - I manually modified the patch file before uploading and mistakenly caused a conflict with SAMLUtil. I'll upload a fixed patch later today with instructions for applying the patch to a clean 1.5.4 source download.
          Hide
          Brian McDonald added a comment -

          I've updated the wss4j_opensaml2.2.3.patch file. If you download it into a standard wss4j 1.5.4 source distribution (so it's a peer to the src directory), you can run the patch command to update the source code:

          > patch -p1 < wss4j_opensaml2.2.3.patch
          patching file src/org/apache/ws/security/WSSecurityEngineResult.java
          ...

          Show
          Brian McDonald added a comment - I've updated the wss4j_opensaml2.2.3.patch file. If you download it into a standard wss4j 1.5.4 source distribution (so it's a peer to the src directory), you can run the patch command to update the source code: > patch -p1 < wss4j_opensaml2.2.3.patch patching file src/org/apache/ws/security/WSSecurityEngineResult.java ...
          Hide
          Todd Dunst added a comment -

          Thanks for the update Brian.

          I have applied your patch, and can verify that it works when sender vouches is selected for the subject confirmation method (I haven't tested holder-of-key yet.. I'll let you know). I have also created a new version, essentially merging your approach with mine to allow the AssertionWrapper to generate both SAML v1.1, as well as SAML v2.0 compliant assertions. The code now reads a new property from the saml.properties file (org.apache.ws.security.saml.version) in order to control which version SAML specification version to use for both assertion statement creation and validation. I have tested this with the sender vouches subject confirmation method, and can now create and validate either SAML v1.1 or SAML v2.0 assertions by simply switching the value in the properties file.

          I also now understand why I was getting the class cast exception that I mentioned earlier. The toDOM() method in the OpenSAMLUtil class was still not doing the right thing. It worked when running JUnits within the WSS4J project, but failed when I attempted to use the patched library with the Apache Axis2 SOAP framework. The reason for this is that Axis2 makes use of a completely different DOM implementation (Axiom) than the OpenSaml2 marshaller implementation (which simply uses the Xerces DOM from the environment). As soon as I attempted to add the OpenSaml2 marshalled assertion to the Axis2 Axiom DOM, I received the class cast exception. I fixed this by making a simple modification to the OpenSAMLUtil.toDom() method which now correctly imports the foreign DOM into the Axiom DOM so that you can combine the output of OpenSaml2 with that of Axis2. I have tested this modification with the JUnits of WSS4J, as well as with a full blown Axis2 SOAP client and server and it works perfectly in both instances.

          I will post a patch early next week which include all of these modifications.

          Show
          Todd Dunst added a comment - Thanks for the update Brian. I have applied your patch, and can verify that it works when sender vouches is selected for the subject confirmation method (I haven't tested holder-of-key yet.. I'll let you know). I have also created a new version, essentially merging your approach with mine to allow the AssertionWrapper to generate both SAML v1.1, as well as SAML v2.0 compliant assertions. The code now reads a new property from the saml.properties file (org.apache.ws.security.saml.version) in order to control which version SAML specification version to use for both assertion statement creation and validation. I have tested this with the sender vouches subject confirmation method, and can now create and validate either SAML v1.1 or SAML v2.0 assertions by simply switching the value in the properties file. I also now understand why I was getting the class cast exception that I mentioned earlier. The toDOM() method in the OpenSAMLUtil class was still not doing the right thing. It worked when running JUnits within the WSS4J project, but failed when I attempted to use the patched library with the Apache Axis2 SOAP framework. The reason for this is that Axis2 makes use of a completely different DOM implementation (Axiom) than the OpenSaml2 marshaller implementation (which simply uses the Xerces DOM from the environment). As soon as I attempted to add the OpenSaml2 marshalled assertion to the Axis2 Axiom DOM, I received the class cast exception. I fixed this by making a simple modification to the OpenSAMLUtil.toDom() method which now correctly imports the foreign DOM into the Axiom DOM so that you can combine the output of OpenSaml2 with that of Axis2. I have tested this modification with the JUnits of WSS4J, as well as with a full blown Axis2 SOAP client and server and it works perfectly in both instances. I will post a patch early next week which include all of these modifications.
          Hide
          Colm O hEigeartaigh added a comment -


          Hi guys, thanks for the patches...I'm just getting a chance to look at this issue now. Todd, do you have an update on the new patch? I'm willing to merge it to trunk + update trunk to be 1.6-SNAPSHOT because of the opensaml upgrade.

          Show
          Colm O hEigeartaigh added a comment - Hi guys, thanks for the patches...I'm just getting a chance to look at this issue now. Todd, do you have an update on the new patch? I'm willing to merge it to trunk + update trunk to be 1.6-SNAPSHOT because of the opensaml upgrade.
          Hide
          Todd Dunst added a comment -

          Hi! I could upload the patch today if you would like, but I would still like to add a couple of pieces. Perhaps you could take a look at what I currently have, evaluate it, and begin the merge process while I am finishing up the following items:

          1.) I have added a configurable SAMLCallbackHandler (an instance of javax.security.auth.callback.CallbackHandler) and a SAMLCallback that users can leverage to extract data from their local applications and provide it to WSS4J for use in creating the various SAML statement types. In my case, I am using Spring Security, so I have provided a callback handler implementation that pulls security-related information from the Spring Security context and makes it available to WSS4J for SAML statement creation. I don't think we need to include my callback handler instance in the main codebase (all we should need there is the SAML callback itself, not the environment specific handler), but you might want to include it as a sample in the examples section to demonstrate how to build a SAML callback handler. In addition, my callback handler currently only supports collecting data for the SAML authentication and attribute statements. I would like to make it a little more generic, and add support for collecting data for SAML authorization decision statements as well.

          2.) I have added two SAML component building classes that are used by the assertion wrapper to generate both SAML v1.1 and SAML v2.0 artifacts. These builders currently support SAML authentication statements, and SAML attribute statements. I would like to add support for creating SAML authorization decision statements as well.

          These two additional pieces should provide a reasonable base to support SAML v1.1 and SAML v2.0 going forward as at that point, all of the SAML statement types will be supported at both SAML version levels. Let me know how you would like to proceed. I could also just wait to upload the patch until I have had a chance to add these last two features. That way, you would only have to attempt the merge once. I should have a chance to complete these items over the few days, so they would be available early to mid next week.

          Show
          Todd Dunst added a comment - Hi! I could upload the patch today if you would like, but I would still like to add a couple of pieces. Perhaps you could take a look at what I currently have, evaluate it, and begin the merge process while I am finishing up the following items: 1.) I have added a configurable SAMLCallbackHandler (an instance of javax.security.auth.callback.CallbackHandler) and a SAMLCallback that users can leverage to extract data from their local applications and provide it to WSS4J for use in creating the various SAML statement types. In my case, I am using Spring Security, so I have provided a callback handler implementation that pulls security-related information from the Spring Security context and makes it available to WSS4J for SAML statement creation. I don't think we need to include my callback handler instance in the main codebase (all we should need there is the SAML callback itself, not the environment specific handler), but you might want to include it as a sample in the examples section to demonstrate how to build a SAML callback handler. In addition, my callback handler currently only supports collecting data for the SAML authentication and attribute statements. I would like to make it a little more generic, and add support for collecting data for SAML authorization decision statements as well. 2.) I have added two SAML component building classes that are used by the assertion wrapper to generate both SAML v1.1 and SAML v2.0 artifacts. These builders currently support SAML authentication statements, and SAML attribute statements. I would like to add support for creating SAML authorization decision statements as well. These two additional pieces should provide a reasonable base to support SAML v1.1 and SAML v2.0 going forward as at that point, all of the SAML statement types will be supported at both SAML version levels. Let me know how you would like to proceed. I could also just wait to upload the patch until I have had a chance to add these last two features. That way, you would only have to attempt the merge once. I should have a chance to complete these items over the few days, so they would be available early to mid next week.
          Hide
          Colm O hEigeartaigh added a comment -


          Cool, there's no rush with the patch, better to wait until you're ready to submit something that can be committed to trunk I guess.

          Show
          Colm O hEigeartaigh added a comment - Cool, there's no rush with the patch, better to wait until you're ready to submit something that can be committed to trunk I guess.
          Hide
          Colm O hEigeartaigh added a comment -

          Any update on this patch Todd?

          Colm.

          Show
          Colm O hEigeartaigh added a comment - Any update on this patch Todd? Colm.
          Hide
          Todd Dunst added a comment -

          II have the SAML callback handler factored properly now, but I am still working on adding support for the Authorization Decision Statement type. To be honest, I haven't had any time to work on it at all over the past couple of weeks due to a pending software release in my day job. Things have calmed down a little this week, so I'm hoping to have it completed by the end of the week. I'm sorry for the delay.

          Show
          Todd Dunst added a comment - II have the SAML callback handler factored properly now, but I am still working on adding support for the Authorization Decision Statement type. To be honest, I haven't had any time to work on it at all over the past couple of weeks due to a pending software release in my day job. Things have calmed down a little this week, so I'm hoping to have it completed by the end of the week. I'm sorry for the delay.
          Hide
          Todd Dunst added a comment -

          I have finally had a chance to work on this (sorry for the delay). I have added support for SAML v1.1 and v2.0 Authorization decision statements, and re-factored the SAML callback to provide a single point within the library to perform all application-specific, SAML-related raw data setup. The SAML callback implementation must be provided by each implementing application and is essentially identical (in concept) to the password callback that was already being used by WSS4J. SAML callback implementation allow the host application to set the subject name qualifier, and all raw data associated with the creation of SAML v1.1 and v2.0 attribute and authorization decision statements. I will provide an example of this class along with the patch.

          I have also removed all compile and run time dependencies on the OpenSaml v1.x library (I am currently using OpenSaml 2.2.3). I see that WSS4J is up to v1.5.7, so I will post a patch tomorrow that includes all of this functionality that is based on WSS4J 1.5.7 (I'm still finishing up the documentation on the new features). I hope that you will still have time to take a look at this.

          Show
          Todd Dunst added a comment - I have finally had a chance to work on this (sorry for the delay). I have added support for SAML v1.1 and v2.0 Authorization decision statements, and re-factored the SAML callback to provide a single point within the library to perform all application-specific, SAML-related raw data setup. The SAML callback implementation must be provided by each implementing application and is essentially identical (in concept) to the password callback that was already being used by WSS4J. SAML callback implementation allow the host application to set the subject name qualifier, and all raw data associated with the creation of SAML v1.1 and v2.0 attribute and authorization decision statements. I will provide an example of this class along with the patch. I have also removed all compile and run time dependencies on the OpenSaml v1.x library (I am currently using OpenSaml 2.2.3). I see that WSS4J is up to v1.5.7, so I will post a patch tomorrow that includes all of this functionality that is based on WSS4J 1.5.7 (I'm still finishing up the documentation on the new features). I hope that you will still have time to take a look at this.
          Hide
          Colm O hEigeartaigh added a comment -


          Great thanks, I'll certainly look at any patch you submit.

          Show
          Colm O hEigeartaigh added a comment - Great thanks, I'll certainly look at any patch you submit.
          Hide
          Todd Dunst added a comment -

          This patch removes all dependancies on the OpenSaml v1.x library and updates support to OpenSaml v2.2.3. It is now possible to create and consume both SAML v1 and SAML v2 style statements via simple configuration in the WSS4J properties file. A callback handler has been provided to support populating the SAML statements with data on outbound requests. The SAML statements may be digitally signed according to either the SAML specification, or the WS-S core specification (i.e. the signatures may appear either inside, or outside of the SAML statement block). Multiple forms of public key identification are supported depending on which flavor of signature you are working with and these can also be configured within the the WSS4J properties file.

          Show
          Todd Dunst added a comment - This patch removes all dependancies on the OpenSaml v1.x library and updates support to OpenSaml v2.2.3. It is now possible to create and consume both SAML v1 and SAML v2 style statements via simple configuration in the WSS4J properties file. A callback handler has been provided to support populating the SAML statements with data on outbound requests. The SAML statements may be digitally signed according to either the SAML specification, or the WS-S core specification (i.e. the signatures may appear either inside, or outside of the SAML statement block). Multiple forms of public key identification are supported depending on which flavor of signature you are working with and these can also be configured within the the WSS4J properties file.
          Hide
          Colm O hEigeartaigh added a comment -


          Here's the first (non-compiling) draft of porting trunk to use Opensaml2 via Todd's patch.

          Show
          Colm O hEigeartaigh added a comment - Here's the first (non-compiling) draft of porting trunk to use Opensaml2 via Todd's patch.
          Hide
          Todd Dunst added a comment -

          Colm,

          I am happy to see that this issue was closed! I contributed the SAML patch some time ago. Did everything work out ok with the patch? Has it been integrated into WSS4J, or did you need any additional assistance from me? I would be happy to help if I could.

          • Todd
          Show
          Todd Dunst added a comment - Colm, I am happy to see that this issue was closed! I contributed the SAML patch some time ago. Did everything work out ok with the patch? Has it been integrated into WSS4J, or did you need any additional assistance from me? I would be happy to help if I could. Todd
          Hide
          Colm O hEigeartaigh added a comment -

          Hi Todd,

          Yes, and thanks for the patch If you take a look at the svn commits under the "All" tab of this issue, you'll see I did rather a lot of work on this issue, using your patch as a base. The SAML2 port is more of less complete, once I get the Opensaml2 artifacts released to Maven central.

          I wrote a blog post on this issue:

          http://coheigea.blogspot.com/2011/02/support-for-saml2-assertions-in-wss4j.html

          Thanks,

          Colm.

          Show
          Colm O hEigeartaigh added a comment - Hi Todd, Yes, and thanks for the patch If you take a look at the svn commits under the "All" tab of this issue, you'll see I did rather a lot of work on this issue, using your patch as a base. The SAML2 port is more of less complete, once I get the Opensaml2 artifacts released to Maven central. I wrote a blog post on this issue: http://coheigea.blogspot.com/2011/02/support-for-saml2-assertions-in-wss4j.html Thanks, Colm.
          Hide
          Todd Dunst added a comment -

          Thank you for acknowledging me in your blog post

          Do you have a sense of when v 1.6 will be released? In the meantime, does the latest patch on the JIRA contain all of the refactoring that you had completed? I would really like to try it out.

          Also, I had my name specified incorrectly in my JIRA profile. It was listing my first name and my middle name (Michael). My full name is Todd Michael Dunst. Would there be any way that you could correct that in the blog post? No big deal, but if you could, I would really appreciate it.

          Thanks!

          Show
          Todd Dunst added a comment - Thank you for acknowledging me in your blog post Do you have a sense of when v 1.6 will be released? In the meantime, does the latest patch on the JIRA contain all of the refactoring that you had completed? I would really like to try it out. Also, I had my name specified incorrectly in my JIRA profile. It was listing my first name and my middle name (Michael). My full name is Todd Michael Dunst. Would there be any way that you could correct that in the blog post? No big deal, but if you could, I would really appreciate it. Thanks!
          Hide
          Colm O hEigeartaigh added a comment -

          > Do you have a sense of when v 1.6 will be released?

          I'm aiming for mid-March.

          > In the meantime, does the latest patch on the JIRA contain all of the refactoring that you had
          > completed? I would really like to try it out.

          No, but the svn trunk does:

          svn co https://svn.apache.org/repos/asf/webservices/wss4j/trunk/

          > Would there be any way that you could correct that in the blog post?

          Done!

          Colm.

          Show
          Colm O hEigeartaigh added a comment - > Do you have a sense of when v 1.6 will be released? I'm aiming for mid-March. > In the meantime, does the latest patch on the JIRA contain all of the refactoring that you had > completed? I would really like to try it out. No, but the svn trunk does: svn co https://svn.apache.org/repos/asf/webservices/wss4j/trunk/ > Would there be any way that you could correct that in the blog post? Done! Colm.

            People

            • Assignee:
              Colm O hEigeartaigh
              Reporter:
              Bob Jacoby
            • Votes:
              8 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development