Shibboleth Developers

["Scott Cantor" <>]

> 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.

In other words, a gateway from SAML to a proprietary system, you mean? Sure,
I guess. I'm not certain the most likely outcome of that would be running
both in one spot, but it's possible.

Not sure how well a throttling of semantics from federated to local (and
often from attributes to "username") would fly in many cases. Usually the
apps are saying "don't federate us, we can't handle it", so masking the
difference like that seems potentially dangerous.

> 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.

Some argue the HS and AA should never even be on the same box. ;-)

-- Scott