Shibboleth Developers

[Tom Barton <>]

Scott Cantor wrote:
> Jim Fox wrote:
> > I would think the most common case would be that the handler
> > is protected by the local sso system, pubcookie, cas, ..., and
> > that the handler just records the necessary information.
>
>
> I would probably dispute that, but nobody knows. I think the more important
> point is how the software is positioned and explained, and I don't think our
> intent is to emphasize the fact that you can always put one SSO system in
> front of another. It makes dealing with logout drastically harder to
> explain, if nothing else.
>
> The burden of integration from a protocol standpoint will definitely be with
> the proprietary SSO system, though. A handler can presumably be written that
> will examine the SAML request and translate it into something else and that
> handler code could be shared amongst all the sites using that something
> else.

I second Jim's thought. In transitioning away from application-based 
authentication and consequent identity-based access control habits, 
we've all learned over the last few years that it's important to keep 
proprietary authentication mechanisms out of applications. I understand 
that session management and SP-originated obligations on authentication 
are part of SAML2, and that arguably the easiest design to implement 
them is founded on incorporation of authentication into the IdP - a 
proprietary SSO system, if I understand your terms above. But I think 
it's terribly important to at least seriously examine alternative 
designs that are premised on use of authentication services external to 
the IdP, ie, in which IdP and (nearly) arbitrary site authN are composable.

Tom