Where to specify which ACS to use for logging in?

[Scott Koranda]

> On 12/16/16, 10:39 AM, "users on behalf of Br LRd" <users-bounces at shibboleth.net on behalf of blasterradius at gmail.com> wrote:
> 
> >    That's for the  <>/Shibboleth.sso part; I know for example it also uses the servername value from (apache) etc, but how
> > do I change Shibboleth to use a different binding?
> 
> You shouldn't (most IdPs do not support artifacts) and in
> general the SP doesn't really handle that well. It really
> depends on the "scope" of the change.
> 
> If Scott Koranda happens to see this, I know his SPs have
> made use of artifact and he may have a good tip for making
> this work. I do it so rarely that I don't even know what the
> "simplest" way would be, but it definitely depends on why
> you're doing it and under what circumstances.
> 

Yes, a few LIGO SPs have been configured to prefer the
artifact binding. 

The artifact binding flows help with a specific LIGO use case.
In short, the background threads used by a browser to fetch
image URLs embedded in the main HTML page but served from
other SPs will often succeed in the SSO flow when the artifact
binding is used because the flow only involves GET requests
and no POSTs.

Details for how to make the Shibboleth SP prefer to use the
artifact binding are at

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionInitiator#NativeSPSessionInitiator-SAML2SessionInitiator(ProtocolHandler)

See specifically the 'outgoingBindings' and 'acsByIndex'
attributes. Please note the statement in the wiki about the
'acsByIndex' attribute.

Our experience actually is that (like most things) the
Shibboleth SP handles this quite well. If an IdP advertises an
artifact binding in metadata the SP will attempt to use it. If
not it just uses the POST binding.

In the context of large higher education federations you can
run into the issue that a few IdPs might advertise an artifact
binding even when the IdP does not support it. That, however,
is an issue of metadata curation for the federation operators
and not a technical limitation.

Scott K for LIGO