Shibboleth Developers

[Scott Cantor <>]

> I think you're correct - I was referring to the entire 
> bundle-o-bits flowing from the HS to the SHIRE by way of the 
> user's browser.  The "handle" per se is inside that BoB.  I 
> thought there were additional things like TTL, etc., that 
> mitigated against replay.  (Been a long time since I looked 
> at the Shib doc ;-)

Ok, I just wanted to make sure. There is indeed a TTL (it's more or less
like a session key value in most WebISO systems, though we're not yet using
it precisely that way). Mainly it lacks enforcement of the authorized user
of the handle for queries, because we kind of got muddled up by all the
stuff about SHARs and resources and got lost in the trees without a clear
way of talking about "the thing we're giving the handle to". That's
hopefully improving.

> I assumed that Von was suggesting inserting that entire BoB 
> into an x.509 object that the Grid target would accept.  In 
> the finest Grid tradition, I believe the user manufactures 
> (signs) their own x.509 object.  So, if the Grid target is 
> happy with that object, and the BoB inside is also 
> sufficiently trustworthy, then the rest is easy (I think).

Yes, but my point earlier was that if you use X.509, the BoB serves little
purpose. The cert itself is or contains enough information to make a
reasonable query to an AA without embedding another signed object in it.

> Of course, this scenario is a "replay" of sorts but seems 
> like it ought to work iff (it's within the TTL) && (the 
> IPaddr of the signer's platform is the IPaddr to which the HS 
> forwarded the BoB).

We ought to try and separate issues like how the requester satisfies the
AA's policy for making requests from the issue of authentication. It may be
that you don't want to permit a requester from just making a query about a
DN (or an EPPN or whatever). In that case, some proof of user presence might
be important, and that could be done in many ways.

One way would indeed be to embed a short term handle in the certificate that
could be presented to the AA, much as we do now. Another way is just to use
the certificate itself, since it would seem to be a short-lived beast issued
on demand anyway. That's a signed token, and the AA can be configured to
trust the appropriate certs.

Point being when you start inventing uses for SAML in the context of X.509
authentication, you're usually reinventing stuff you've already got working.

It's when we don't have X.509 working (Kerberos, users without certs, etc.)
that we start shipping SAML authentication assertions around. Not because we
couldn't use proxy certs and basically emulate the grid model, but usually
because of rejecting having certs in the client for some reason, or because
the app isn't X.509 savvy.

-- Scott