<div dir="auto"><div>In my case I don't mind hard coding the protocol binding to POST for the site when I've already hard coded the idp to use for the same site but I don't understand where to start. How do I force it do do this when the default in protocols is artifact. </div><div dir="auto"><p style="font-size:12.8px"><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"<u></u><u></u></p><p style="font-size:12.8px"> AssertionConsumerServiceURL=<a href="https://site.example.com/Shibboleth.sso/SAML2/POST" style="text-decoration-line:none;color:rgb(66,133,244)">https://site.example.com/Shibboleth.sso/SAML2/POST</a><u></u><u></u></p><p style="font-size:12.8px"> Destination=<a href="https://login.microsoftonline.com/%5btenantid%5d/saml2" style="text-decoration-line:none;color:rgb(66,133,244)">https://login.microsoftonline.com/[tenantid]/saml2</a><u></u><u></u></p><p style="font-size:12.8px"> ID="blah"<u></u><u></u></p><p style="font-size:12.8px"> IssueInstant="2025-05-06T15:19:02Z"<u></u><u></u></p><p style="font-size:12.8px"> ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"<u></u><u></u></p><p style="font-size:12.8px"> Version="2.0"<u></u><u></u></p><p style="font-size:12.8px"> ><u></u><u></u></p><p style="font-size:12.8px"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"><a href="https://site.example.com/shibboleth%3c/saml:Issuer" style="text-decoration-line:none;color:rgb(66,133,244)">https://site.example.com/shibboleth</saml:Issuer</a>><u></u><u></u></p><p style="font-size:12.8px"> <samlp:NameIDPolicy AllowCreate="1" /><u></u><u></u></p><p style="font-size:12.8px"></samlp:AuthnRequest></p></div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, May 8, 2025, 7:45 AM Cantor, Scott via users <<a href="mailto:users@shibboleth.net" target="_blank" rel="noreferrer">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's basically not practical.<br>
<br>
The only means of controlling it is really ugly and requires specifying an acsIndex setting that happens to match the index it generates for the Artifact ACS (or requires the old syntax of laying out the AssertionConsumerService handlers by hand and putting local index attributes on them).<br>
<br>
Assuming the documentation isn't wrong, the problem is the only way to specify acsIndex at all is to also brute force the SessionInitiator elements the old way and stick it in the SAML2 one.<br>
<br>
i.e. it's not part of the modern feature set to do it, it was a feature of the original handler syntax prior to the creation of the <SSO> shorthand and the protocols.xml file to automate all of it. Artifact was essentially a dead idea by then so it wasn't accomodated.<br>
<br>
I don't know why it doesn't supoort using the acsIndex setting via the RelyingParty element, oversight I guess, or because that ACS selection code is already so bad that it wasn't a good idea to mess with it.<br>
<br>
I worked on some of the comparative logic for this for V4 not that long ago, and indeed this whole area is very hard to deal with, it's why I took pains to make sure the new design could stick all the bindings at one endpoint and rectify that original choice.<br>
<br>
-- Scott<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer noreferrer noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" rel="noreferrer noreferrer" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div></div></div>