Where to specify which ACS to use for logging in?

[Scott Koranda]

On Mon, Dec 19, 2016 at 8:03 AM, Tom Scavo <trscavo at gmail.com> wrote:

> On Fri, Dec 16, 2016 at 11:25 AM, Scott Koranda <skoranda at gmail.com>
> wrote:
> >
> > 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.
>
> Of the 2279 entities with an IdP role in InCommon metadata, zero of
> them have a SAML2 HTTP-Artifact endpoint. I must be missing something.
>
> On the other side of the equation, there are 605 entities with an SP
> role and a SAML2 ArtifactResolutionService endpoint (none of which are
> registered by InCommon), which means that that endpoint has most
> likely never been exercised.
>
>
Here is a concrete LIGO example.

You can browse to

https://www.lsc-group.phys.uwm.edu/ligovirgo/cbcnote/

In the discovery service choose Cornell. You will see that the
<AuthnRequest> sent to the IdP leverages the artifact protocol (look at the
ACS URL). Note that the Cornell IdP consumes the request because it does
support artifact (thank you Cornell).

Do it again but now choose the University of Wisconsin-Milwaukee IdP. You
will see that the request sent to that IdP leverages HTTP-POST, which is
good because the UWM IdP does not support artifact resolution. And they do
not advertise an artifact resolution endpoint in metadata (thank you UWM).

The Shibboleth SP makes this possible. We have never had a problem with it
except when the IdP does advertise an artifact resolution endpoint in
metadata but does not actually support it. In that case the browser dies at
the IdP.

Thanks,

Scott K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161219/796fe9c5/attachment-0001.html>