cantor.2 at osu.edu
Mon Nov 24 12:30:09 EST 2014
On 11/24/14, 4:45 PM, "samir el otmani" <elotmani.samir at gmail.com> wrote:
>Organization 1 will enter the link :
>Organization 2 will enter the link : sp.test.org/secure?o=org2
As Peter noted, no they won't. They'll enter anything they like, and
defeat any scheme you come up with, especially if it's parameter driven.
If you really want to do this, using separate virtual hosts tends to be
less error prone for users.
Either way, you can do this either programmatically as described by
others, or if you can statically configure the mappings into
shibboleth2.xml, or Apache commands, you can attach a content setting,
entityID, to resources based on path, a parameter, or vhost, to lock
requests to use that entityID when they redirect away for a login.
Having done this, you have broken your system with regard to federation,
you now have silos, each one locked to an IdP and unable to share access
across IdPs. No matter what you think, that's not good. It's not fully
workable even when the application doesn't involve sharing resources,
because not every customer organization you sign up will have only a
single IdP to use.
More information about the users