Phil Varner said:

Patch:

Index: saml2-core/src/main/java/org/springframework/security/saml/websso/WebSSOProfileConsumerImpl.java

--- saml2-core/src/main/java/org/springframework/security/saml/websso/WebSSOProfileConsumerImpl.java (revision 74)
+++ saml2-core/src/main/java/org/springframework/security/saml/websso/WebSSOProfileConsumerImpl.java (working copy)
@@ -337,27 +337,24 @@
throw new SAMLException("SAML response is not valid");
}

•    audience:
  

  • for (AudienceRestriction rest : conditions.getAudienceRestrictions()) {

  •    if (rest.getAudiences().size() == 0) {
           log.debug("No audit audience specified for the assertion");
           throw new SAMLException("SAML response is invalid");
       }
    

  •    for (Audience aud : rest.getAudiences()) {
           if (context.getLocalEntityId().equals(aud.getAudienceURI())) {
    

•                continue audience;
  

•                return;  // found!
           }
       }
  

•        log.debug("Our entity is not the intended audience of the assertion");
  

•        throw new SAMLException("SAML response is not intended for this entity");
   }
  

•    /** ? BUG
  

•     if (conditions.getConditions().size() > 0) {
  

•     log.debug("Assertion contain not understood conditions");
  

•     throw new SAMLException("SAML response is not valid");
  

•     }
  

•     */
  

•    log.debug("Our entity " + context.getLocalEntityId() + " is not the intended audience of the assertion");
  

•    throw new SAMLException("SAML response is not intended for this entity");
  

  }

  /**

from spring-security-saml.

Vladimir Schäfer said:

Hi, I'm just checking this bug and the original implementation seems to be correct. In SAML2-core, 922:

"Note that multiple elements MAY be included in a single assertion, and each
MUST be evaluated independently. The effect of this requirement and the preceding definition is that
within a given condition, the audiences form a disjunction (an "OR") while multiple conditions form a
conjunction (an "AND")."

The original code failed when any of the AudienceRestrictions didn't contain the current SP, as defined.

Is it possible that your assertions is not formatted in accordance with the specification? If this is the case I'd recommend to override the WebSSOProfileConsumerImpl#verifyAssertionConditions method in your custom implementation to solve the problem.

from spring-security-saml.

Phil Varner said:

Thanks Vladimir. When you say "the original code failed", you mean that it correctly returned an error?

from spring-security-saml.

Vladimir Schäfer said:

Yes, that's what I meant.

from spring-security-saml.

Phil Varner said:

It looks like Siteminder might not implement the spec correctly. I'm working with a client using Siteminder, and the Assertions contain two separate ARs with one correctly containing the entityID and the other with the Siteminder name for the IdP-SP configuration.

This document on WebEx / Siteminder integration has an example AuthnRequest in the appendix:
http://developer.webex.com/c/document_library/get_file?folderId=22041&name=DLFE-902.pdf
which contains two identical ARs, which I assume is because one was generated based on the SP entityID and the other was the Siteminder config name. In the case that these aren't the same, it seems to me it's always a spec violation, since the Siteminder name is never going to have any meaning to the SP.

This zip has a doc:http://developer.webex.com/c/document_library/get_file?folderId=22041&name=DLFE-1803.zip
describing the config of Siteminder. It looks like the on page 18 in the "SSO" tab, the "Audience" field is always included as an AR, even if it's the same as the entityID in the SP metadata.

The IDPM I'm working with told me this is how he always configures it, and that Google Apps and SFDC work with it.

Maybe there should be a "relaxed" mode by which the semantics of matches at least one AR passes?

from spring-security-saml.