SP Simplified Protocol Configuration and artifact resolution

[Scott Koranda]

> On 11/22/11 6:24 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
> 
> >But the main point is what I said at the top. Once you pick artifact,
> >you're dead if the IdP doesn't support it. It doesn't fall through.
> 
> Actually, there probably is one way to do that, stack SAML2 initiators in
> a chain with different acsIndex properties. It's probably possible to do
> just about anything, but it's probably less error prone to rip out the 2.4
> syntax and plugin the original so you can spell it all out and not be
> subject to unseen interactions.
> 

Yes, I will plan to not use the 2.4 syntax for this SP and
instead use the original syntax in order to spell out the
configuration explicitly.

I have tested with this configuration:

<SessionInitiator type="Chaining" Location="/Login" isDefault="true"
    entityID="https://my.idp.server/idp/shibboleth">
  <SessionInitiator type="SAML2" acsIndex="3" />
  <SessionInitiator type="SAML2" />
</SessionInitiator>

<md:AssertionConsumerService Location="/SAML2/POST" index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:AssertionConsumerService Location="/SAML2/POST-SimpleSign" index="2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>
<md:AssertionConsumerService Location="/SAML2/Artifact" index="3" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
<md:AssertionConsumerService Location="/SAML2/ECP" index="4" Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"/>

<md:ArtifactResolutionService Location="/Artifact/SOAP" index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>

I found that if the IdP supports artifact then that is what is used to
establish the session. If the IdP does not support artifact
then POST is used.

For the record I tested using SP 2.4.3 and IdP 2.3.0.

Thanks,

Scott K