Shibboleth Developers

[Scott Cantor <>]

> Shib 1.1 only supports handles in various guises.  Adding 
> specific other subject identifiers would have to be done as 
> part of a profile of the whole scenario, it seems to me; ie, 
> not just "use a DN" but also say where it comes from in the 
> cert, how it relates to cert issuer, etc.

My working model for how this would work has always been that the relying
party should not be looking at the certificate at all. I think it should be
possible to take the entire certificate and send it as the subject of a SAML
query.

The AA can then both validate the certificate and map it to an identity for
attribute lookup.

This doesn't obviate the privacy issues (the target can still see the cert),
but it delegates the validation and mapping process to the origin, where it
belongs, since validation of client certs by web servers is effectively
nightmarish to implement today on a global scale.

The remaining trick is to map the certificate to an origin site identifier,
such that the metadata can then be used to locate an AA to query. This may
actually be something the user could directly indicate somehow, but could
also depend on the certificate, obviously.

It does occur to me that we should profile use of X.509 certificates as SAML
Subjects in 2.0. Not sure it should be a NameIdentifier, though. I'll try
and write up a use case for it.

A related point is that Walter and I have both, somewhat independently, been
looking at different models for handling the NameIdentifier processing in
the AA, and will probably work on that at some point to generalize it more.
It's a bit tricky today to deal with multiple kinds of identifiers because
the format of the properties file is so limited.

I had to hack in support for my AA to deal with both transparent usernames
as well as the Shib style handles at the same time, which I needed
internally.

-- Scott