Shibboleth Developers

[Christopher A Bongaarts <>]

In the immortal words of Scott Cantor:

> It's unusual to install both on the same machine for anything other than
> some kind of one-off test or during our development. An origin tends to
> always end up in something like /shibboleth-origin-1.2.1 or some such
> anyway. Not sure there's any point in even using /opt.

Here's a case where it might make sense to have both on the same box
in production:

A campus SSO system could act as an SP, allowing remote users to log
in to the local SSO using their "home" SSO system to authenticate.

Then the SSO system could also have an IdP, possibly running on the
same box, that would be used for authz to remote resources.

Thus, if our libraries had a contract with some vendor that allowed us 
to give access to visiting faculty for their products, the flow would
look like this:

* User hits resources, which sends user (via WAYF or hardcoded) to
UMN's IdP, which is protected by UMN SSO
* User logs in to UMN SSO using whatever magic is necessary to
activiate the SP functionality, which sends user (via WAYF or other
means) to OSU's IdP
* User finally actually logs in to OSU's SSO
* User is sent back to UMN SSO to complete Shib login
* User is sent back to vendor's SP

While using the full flexibility of the setup like this is not
terribly likely to occur in "real life", it may make sense from a
central authN service point of view to have both IdP and SP functions
running on the same box.

Perhaps my case counts as "unusual", in which case I guess I'm not
disagreeing with Scott ;)

%%  Christopher A. Bongaarts  %%  

       %%
%%  Internet Services         %%  http://umn.edu/~cab  %%
%%  University of Minnesota   %%  +1 (612) 625-1809    %%