SAML 2.0 - Multiple AssertionConsumerService in SP

问题:

I implement a SAML 2.0 SP.
I have a login servlet with endpoint https://my.domain.com/mng/samlLogin, so in the SP metadata file I define:

<md:AssertionConsumerService     
    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"  
    Location="https://my.domain.com/mng/samlLogin" index="0" isDefault="true"/>

And send this endpoint in the AuthenRequest under the AssertionConsumerServiceURL.

Now, I have another servlet with a different functionality, and it needs to validate the user against SAML as part of its flow.
So I need to define the new servlet's URL as an additional endpoint, let's say https://my.domain.com/mng/myServletSamlLogin , which will get SAML authentication reponse.

Is this possible? Can I define multiple AssertionConsumerService elements for the same binding (HTTP-POST)?

Thanks!

回答1:

Yes, you can include additional <md:AssertionConsumerService> elements in the SAML 2.0 SP metadata with the same binding, each with its own unique index. Alternatively you can choose to sign the authentication requests as the SP in which case you can freely specify an AssertionConsumerServiceURL without the requirement that it was published and configured earlier as part of the SP metadata exchange.

This is all spec compliant but be aware (as always with "advanced" SAML options) that your mileage may vary wrt. support across different SAML implementations.

回答2:

Have a look at Assertion Consumer Service Glossary which will tell you that

Assertion Consumer Service

A SAML-compliant portion of PingFederate in an SP role that receives and processes assertions from an IdP.

attributes

Distinct characteristics that describe a subject. If the subject is a Web site user, attributes may include a name, group affiliation, email address, etc.

attribute contract

A list of attributes, agreed to by the partners in an identity federation, representing information about a user (SAML subject). The attributes are sent from the IdP to the SP during SSO or STS processing.

So you associate bindings to the Assertion Consumer Service (ACS) endpoint(s) where your SP will receive assertions.