Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Mon, 19 Jun 2006, Tom Barton wrote:

> If I understand things correctly, with shib 2's implementation of SAML 2 
> authN context, the container will no longer be directly involved in 
> authentication. But one can imagine that the authN context declarations 
> provided to an IdP by an SP might in turn be referred by that IdP, 
> acting as another SP, to some other IdP. This could effectively enable 
> the same style of application.

https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/ShibTwoAuthN

has the material on this for Shib 2.0.  I guess it's still accurate, 
though perhaps things have progressed since it was written.

The SAML Authentication Proxying support (in section 3.4.1.5 of 
saml-core-2.0) includes protocol-level support for things like an IdP 
specifying which other IdPs it will accept proxying from.

Note that the passthrough to the Authentication Handler in Shib 2.0 could 
invoke some other web signon scheme (pubcookie, CAS, etc); the difference 
being that these schemes would not receive or do any processing of the 
SAML AuthnRequest info (like a SAML signon system that is being proxied-to 
would).

> Is something like this permissible, feasible, or planned? This seems 
> different from delegation - is it?

Yes.  I assume by delegation you mean a multi-tier system where one or 
more SPs acts as an intermediate, ie a delegate, between the client and 
some other SP.  I guess the difference between chaining of IdPs and 
chaining of SPs is just an extension of the basic difference between IdPs 
and SPs.  SPs are relying parties so depend on assertions from SAML 
authorities, but are not SAML authorities themselves.  A delegated-to 
intermediate SP turns around and acts as a client, not as an IdP.

In the early days of the SAML TC some folks were in fact promoting 
architectures (realized in their products at the time) where 
"applications" would act as identity providers, ie the fact that a user 
had authenticated to AppA would be asserted to AppB.  It took a great many 
whiteboards to establish IdP and SP as separate and separable roles.

  - RL "Bob"