Addition of SAML2 support for SP

Ian Young ian at
Thu Nov 8 12:02:54 EST 2012

On 8 Nov 2012, at 16:50, Jayashree Ravi <jravi123 at> wrote:

> <SessionInitiator type="Chaining" Location="/Login"
>                         id="Login" relayState="cookie">
>             <SessionInitiator type="Shib1" defaultACSIndex="1" />  
>             <SessionInitiator type="SAML2" template="bindingTemplate.html" outgoingBindings="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
> urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"  />
>                   </SessionInitiator>


> So we are guessing that based on session initiator configuration, it first tries SAML1.1 and if that fails with the IDP it switches to SAML2. […]  Since we could not get the answer for this behavior from the documentation we need help in understanding this.

Some relevant documentation is here:

In particular:
> Chaining SessionInitiator
> Identified by type="Chaining", wraps a sequence of SessionInitiator handlers so that they run in series. The series ends when a handler indicates that a response to the browser was returned.

So, as you are running the SAML 1 protocol handler first, if it succeeds (if the IdP supports SAML 1 and the handler redirects your client to the IdP) then the SAML 2 protocol handler will not run (as you guessed).

> So want to confirm that none of our existing IDP's will fail because of us not registering our SAML2 endpoints with all the existing federations as yet.

Probably correct.  It's hard to be definitive, though, and minimising the time during which your metadata is different in different places will certainly minimise the chance of problems.

	-- Ian

-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
Url : 

More information about the users mailing list