Shibboleth Developers

["caleb racey" <>]

>Subject: RE: SAML delegation profiles draft-01 uploaded
>
>Moving all discussion of this document to shibboleth-dev...
>
>> This suggests that the delegatable tokens (kerb service tickets) are
>> available at step 3 when the user identifies them self to the IdP.
Would
>> it be possible to "hotwire" the process so that step 3 can feed any
>> delegatable tokens into steps 4 and 7?
>
>Sure, but that's not this use case. I'm not talking about transporting
>tickets in SAML. That doesn't work in a federated scenario either,
which is
>a presumption of this document.

Ok fair enough,  Kerberos tickets aren't suitable in a genuine federated
scenario, however they are useful within an institute and in grey area
semi federated scenarios.

A system like shibboleth that will authenticate a user and also tell you
details about that user (are they staff student etc) is as useful
internally to an institute as it is in a federated scenario.

I see one of the drivers towards shibboleth being that it is very useful
for  authentication of webapps within an institute with all the
federated stuff being a nice additional benefit.

In this context the ability to pass Kerberos service tickets via
shibboleth would be very useful.  I would much rather tell other admins
in my institute to "use shibboleth for internal webapps" than to tell
them "pubcookie for internal apps, shibboleth for federatable webapps".


With this in mind the ability to pass around authentication tokens via
shib would be very handy. See below for use case

>> I appreciate this is a pubcookie Kerberos specific example however I
>> think it is likely that delegatable authentication tokens will be
>> available at the login step rather than at the attribute aggregation
>> step.
>
>I think we're talking about different use cases. There's nothing in
this
>document that uses attributes to carry delegation tokens, the
assertions
>are
>the tokens.

You are right, I have reread the doc and was jumping to the false
conclusion that SAML was being used to pass tokens, rather than SAML
being the token. That said I think there is a use case for baing able to
pass tokens.

The use case I'm thinking of is something like this:

My university decides it wants bleeding adage AJAXified webmail (similar
to gmail) for our students and buys the presentation layer from an
outside party which will be hosted on their servers.  However to prevent
vendor lockin my uni  keeps control of the actual mail boxes which the
presentation layer accesses via IMAP authenticated via Kerberos.

In this scenario I want to make use of shibboleth federated access
control on the presentation layer with the ability for the presentation
layer to pass back a Kerberos ticket so that it can access the users
mail store via IMAP kerberized  authentication.

Does this sound like a sensible use case where the ability to distribute
kerb tickets via shib attribute might be valuable?

>
>We don't use Kerberos like that here so I'm not equipped to be writing
up
>profiles that pass around Kerberos tickets, I wouldn't know what I was
>talking about. If somebody wants to do that, they're welcome to do so.
>
>-- Scott