Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Mon, 3 Oct 2005, caleb racey wrote:

> Also is it possible/easy to adjust shibboleth so that in addition to 
> picking up the REMOTE_USER variable from pubcookie it is also able to 
> pick up Kerberos tickets provided by pubcookie.  It can then feed them 
> into the attribute aggregation process, that way it would be possible to 
> treat Kerberos service tickets as attributes.

Some of the other university-developed webiso systems also provide 
Kerberos ticket acquisition by intermediates (CoSign and Stanford Webauth 
at least, maybe A-Select?).  As far as I know the application protocols 
these are used with, between intermediate and backend, are ones that have 
well-defined Kerberos authentication schemes (eg IMAP, AFS) already.

Yale CAS of course has a "proxy" authentication feature that is widely 
used, with CAS-specific tokens.  I think this is always used with HTTP as 
the protocol between intermediate and backend, where proxy CAS is applied 
in more or less the same way plain old CAS is.  You could imagine that it 
might be useful to provide access to proxy CAS tokens to an intermediate 
even in the case where user authentication to the intermediate happened 
via a SAML SSO profile, to deal with a backend already using proxy CAS.

There might be scenarios also, eg in grid systems, where providing the 
intermediate with X.509 certs and keys would be useful.  And of course 
there is a world of other possible tokens, authentication methods, and 
intermediate-backend application protocols that people might be interested 
in.

The introduction to Scott's proposal says that it's limiting scope so as 
to avoid some complexity and questions of generality.  I think this is 
fine.  I suppose those of us interested in Kerberos in particular can 
think about how to build on this proposal for that purpose.  In particular 
the delivery of security tokens as SAML attributes makes me a little 
nervous, since it seems like they might need special attention.

 - RL "Bob"