Announcement Announcement Module
Collapse
No announcement yet.
Signing Response vs Assertion and wantsAssertionsSigned Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Signing Response vs Assertion and wantsAssertionsSigned

    Hello,

    I have integrated Spring SAML into my application and while testing different configuration sets, I was validating whether an Assertion inherits the signature from a signed, enclosing Response. Basically, I want to know if only signing the Response object and not the Assertion satisfies the SP "wantsAssertionsSigned" declaration.

    According to the spec (well my best reading of the spec), the Assertion should inherit the signature from Response if it is not signed (from http://docs.oasis-open.org/security/...ore-2.0-os.pdf):

    A SAML assertion may be embedded within another SAML element, such as an enclosing <Assertion>
    or a request or response, which may be signed. When a SAML assertion does not contain a <ds:Signature> element, but is contained in an enclosing SAML element that contains a <ds:Signature> element, and the signature applies to the <Assertion> element and all its children, then the assertion can be considered to inherit the signature from the enclosing element. The resulting interpretation should be equivalent to the case where the assertion itself was signed with the same key and signature options.
    So from my understanding, a Response object that contains a valid Signature and an unsigned Assertion should satisfy the wantsAssertionsSigned property and allow successful validation of the message. The Spring extension seems to only validate Response signatures if they exist (and sets context.setInboundSAMLMessageAuthenticated(true)), but when checking the Assertion signature, never refers back to the context to see if the message has been authenticated already, thereby not inheriting.

    Basically, I want to confirm my understanding and ask if there is any ideas for configuring the extension (or modifying it) such that my users can enforce message integrity at the Response level or the Assertion level or both.

    I have sample messages from one customer who is currently only signing Responses and the only option for supporting this style right now is disabling wantsAssertionsSigned. This is obviously a huge whole since there is currently no option for requiring a Response signature and therefore the SP will just accept unsigned messages.

    The two thoughts I had were to implement the signature inheritance or adding another configuration option or enforcing a Response signature, but I want to make sure I am not missing something.

    Thanks,

    Matt

  • #2
    Hi Matt,

    You are right, the Response signature itself should be able to satisfy the wantAssertionSigned requirement. I've opened https://jira.springsource.org/browse/SES-120 and fixed the issue in trunk, you can just update.

    Vladimír Schäfer

    Comment


    • #3
      Assertion invalidated by missing Audience Restriction

      I am getting following Exception when I set wantAssertionSigned to false in MetadataGeneratorFilter

      What is Audience Restriction?

      Code:
      <property name="wantAssertionSigned" value="false" />
      Code:
      2013-02-25 10:51:07,415 DEBUG: org.springframework.security.saml.websso.WebSSOProfileConsumerImpl - Verifying issuer of the message
      2013-02-25 10:51:07,415 DEBUG: org.springframework.security.saml.websso.WebSSOProfileConsumerImpl - Processing Bearer subject confirmation
      2013-02-25 10:51:07,415 DEBUG: org.springframework.security.saml.websso.WebSSOProfileConsumerImpl - Assertion invalidated by missing Audience Restriction
      2013-02-25 10:51:07,415 DEBUG: org.springframework.security.saml.websso.WebSSOProfileConsumerImpl - Validation of received assertion failed, assertion will be skipped
      org.opensaml.common.SAMLException: Assertion invalidated by missing Audience Restriction
      Last edited by roboto; Feb 25th, 2013, 03:59 AM.

      Comment


      • #4
        Hi,

        The wantAssertionSigned flag shouldn't really have any effect on validation of the assertions. Are you really sure the audience validation fails only when the flag is false? Does the SSO still pass (is user able to log-in) or does it fail completely after the error? What IDP are you connecting to?

        Vladi

        Comment


        • #5
          Hello Vlad,

          I am not sure that audience validation fails only when wantAssertionSigned is set to false. I am learning saml, and trying to integrate it with sample IDP from Jim Cox http://sourceforge.net/projects/spring-saml/develop.

          That IDP by default doesnt supports Assertion Signing, so I am trying to make this work with wantAssertionSigned=false.

          I cannot find information about Audience Validation and how it is set either.

          Comment


          • #6
            Hi,

            AudienceRestriction defines who is allowed to use the SAML Assertion and in this use-case it has to (saml-profiles, line 566 and saml-core, line 2257) contain entity identifier of your service provider instance. The IDP doesn't seem to include this information in the Assertion it sends back. You could raise this issue with your IDP as it's possibly a bug. Or you can override method verifyAssertionConditions in the WebSSOProfileConsumerImpl of SAML Extension and customize the verification logic, but this will violate the correct processing of WebSSO profile.

            Vladi

            Comment


            • #7
              Hi Vladi,

              Thanks you for detailed response. I have issue on the IDP side.

              Comment

              Working...
              X