Shibboleth sp Apache - Artifact profile or POST profile depending on idp

[cneberg]

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.

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

                    AssertionConsumerServiceURL=
https://site.example.com/Shibboleth.sso/SAML2/POST

                    Destination=
https://login.microsoftonline.com/[tenantid]/saml2

                    ID="blah"

                    IssueInstant="2025-05-06T15:19:02Z"


ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

                    Version="2.0"

                    >

    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
https://site.example.com/shibboleth</saml:Issuer>

    <samlp:NameIDPolicy AllowCreate="1" />

</samlp:AuthnRequest>


On Thu, May 8, 2025, 7:45 AM Cantor, Scott via users <users at shibboleth.net>
wrote:

> It's basically not practical.
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250508/8c3ae26d/attachment.htm>