Convert native Shibboleth SP installation to Shibboleth SP using InCommon metadata

[Cantor, Scott]

On 3/16/12 11:55 AM, "Jason Johnson" <jasonaj at gmail.com> wrote:

>Fair enough.  My application allows institutions to have students apply
>for projects/classes online and staff/faculty are able to approve/deny
>and otherwise manage the application process.

Ok.

>So, when I refer to clients, I'm speaking of the multiple institutions
>that can be identified by URL.

Ok, those are simply the IdPs you want to support then. Identifying them
"by URL" is your choice, not a requirement. That's one way people get
around the discovery problem. But it gets very ugly if you insist on
creating dedicated hostnames for every IdP you support. Shibboleth simply
doesn't work well with that approach.

>  All this requires student and staff members to login.  Some
>institutions are now with InCommon - maybe half, 56.

Sure. Are you really finding that the others support SAML (but no via
InCommon) or just some other mechanism you offer?

>I'm not sure how to put that in Shibboleth/InCommon speak where it makes
>sense.

I'm now understanding your "client" terminology and why you were mapping
it to URLs.

The best way you could handle this is to *not* try and avoid the reality
that discovery of the IdP is simply necessary. You have one SP, one
entityID defined, and when a protected page is accessed you simply present
a discovery page to select the IdP. We offer tools for that, as do other
projects.

The next best way is that you could rely on part of the path or query
string to identify the IdP. That would still allow a single entityID and
vhost in the InCommon metadata, and you can tell the SP which IdP to use
based on the path using the entityID content setting in the RequestMap or
Apache command.

The worst way is to go down the road of registering multiple entityIDs
(one per IdP) or multiple ACS endpoints/vhosts (one per IdP). Of those two
choices, using one entityID and simply registering all the vhosts required
is far better than using multiple entityIDs.

In any case, none of this has anything to do with the physical deployment
choices of how many servers to use. That is discussed extensively in the
wiki.

-- Scott