Uploaded image for project: 'PicketLink'
  1. PicketLink
  2. PLINK-692

Audience restriction check is too strict

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • PLINK_2.7.1.Final
    • PLINK_2.7.0.Final
    • SAML
    • None

    Description

      The audience restriction check implemented in PLINK-678 is too strict in that it only accepts the service URL as a valid audience. However, the SAML 2.0 specification (section 2.5.1.4) defines the audience restriction otherwise:

      <Audience>
      A URI reference that identifies an intended audience. The URI reference MAY identify a document
      that describes the terms and conditions of audience membership. It MAY also contain the unique
      identifier URI from a SAML name identifier that describes a system entity (see Section 8.3.6).

      Section 8.3.6 refers to the use of entity IDs (e.g. as defined in the SP metadata).

      Shibboleth IdP 3.0 uses the SP's entity ID as the value for the audience restriction, which causes PicketLink to fail the authentication process. Here are the relevant XML fragments:

      sp-metadata.xml
      <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="urn:samltest:picketlink-wildfly8">
      <!-- Contents here -->
      </md:EntityDescriptor>
      
      SAML Response
              <saml2:Conditions NotBefore="2015-03-05T16:16:05.277Z" NotOnOrAfter="2015-03-05T16:21:05.277Z">
                  <saml2:AudienceRestriction>
                      <saml2:Audience>urn:samltest:picketlink-wildfly8</saml2:Audience>
                  </saml2:AudienceRestriction>
              </saml2:Conditions>
      

      Section 2.5.1.4 of the SAML 2.0 specification also states:

      Although a SAML relying party that is outside the
      audiences specified is capable of drawing conclusions from an assertion, the SAML asserting party
      explicitly makes no representation as to accuracy or trustworthiness to such a party.

      This seems to suggest that the audience restriction check should be optional (i.e. subject to configuration) rather than being enforced unconditionally.

      Attachments

        Issue Links

          Activity

            People

              psilva@redhat.com Pedro Igor Craveiro
              atomicknight_jira Abraham Lin (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: