The DS sent this back to SP with the acsIndex intact.
I had hoped that the SP would then respond by sending a Shibboleth Login to the IdP with a Shire pointing to the artifact ACS. Instead I got a SAML 2 login at the IdP
The IdP flips out slightly at this and just picks a SAML2 assertion back (I haven't checked to see whether its by POST or artifact, but I suspect POST.
It all hangs together so theres no big deal but it would makwe the life easer for the poor sods who have to work out why random third party relying party software configured to use odd edge cases are misbehaving...
Long time sore spot in the code is that it doesn't understand which handlers handle particular protocols. I want to fix the API in 2.3, but for now I'm implementing a brute force check against the ACS binding in the request handlers to block incorrect dispatching.
I'll add a compatibleBindings property to allow overriding the set to allow in case some unforeseen issue or extension arises, but in most cases it should function automatically and prevent protocol binding mismatches and pass control to the next handler.
Fixed
Pinned fields
Click on the next to a field label to start pinning.
Again, potentially PEBKAC in the setup (or even my comprehension of whats up)
Using an Shib2 Sp with the usual ACS I wanted to force use of Shiboleth Login and Browser/Artifact via the DS initiator
I specfied https://Shibhost/Shibboleth.sso/DS?acsIndex=6 (where id "6" is the urn:oasis:names:tc:SAML:1.0:profiles:artifact-01 ACS).
The DS sent this back to SP with the acsIndex intact.
I had hoped that the SP would then respond by sending a Shibboleth Login to the IdP with a Shire pointing to the artifact ACS. Instead I got a SAML 2 login at the IdP
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://sh2testsp1.iay.org.uk/Shibboleth.sso/SAML/Artifact"
Destination="https://dlib-adidp.ucs.ed.ac.uk/shibboleth-idp/profile/SAML2/Redirect/SSO"
ID="_e4a83ad52c71e8150ee03676d845dbdb"
IssueInstant="2009-07-30T12:46:54Z"
ProtocolBinding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sh2testsp1.iay.org.uk/shibboleth</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="1"/>
</samlp:AuthnRequest>
The IdP flips out slightly at this and just picks a SAML2 assertion back (I haven't checked to see whether its by POST or artifact, but I suspect POST.
It all hangs together so theres no big deal but it would makwe the life easer for the poor sods who have to work out why random third party relying party software configured to use odd edge cases are misbehaving...