Shibboleth Developers

["RL 'Bob' Morgan" <>]

> I'd like to add a feature.  In our environment, some backend servers 
> (such as the Sun Directory Server) do not support GSSAPI and cannot do 
> anything useful with a Kerberos ticket.  So for Service Providers that 
> use these backend servers, we pass them a proxy token that's created 
> from the Kerberos ticket. The proxy token is the part of the ticket 
> that's encrypted in the backend server's key and contains the meaningful 
> ticket data with the lifetime information, ip addresses, flags, etc. 
> So we would like the IdP to also allow passing this part of the ticket 
> that we use as a proxy token.

So ... I think we all know that there are lots of ways that middle tiers 
might need to authenticate to backends as users.  I'm aware of other 
implementations of methods that are designed to put something in the 
password slot of a classic username/password signon to the backend. 
Clearly this is not Kerberos, but it is useful at some sites.  As I 
understand it the CAS proxy token is used this way at some sites, for 
example.

I'd like to keep the scope of this project on the small side if possible. 
Designing a new token, even if Kerberos-derived, for this case is bound to 
involve lots of contentious design discussion.  It's probably the case 
that whatever method is used to do the Kerb ticket handling would be 
applicable to other tokens too.  So "scheme should be applicable to other 
tokens" could be another desirable feature.  And if Duke folks or others 
want to go off and design and implement something for the 
go-in-the-password-slot case, I'd say go for it.  I'd be inclined to keep 
that separate from the Kerberos case, though, both in design and in 
coding.

 - RL "Bob"