Shibboleth Developers

["Tom Scavo" <>]

On 7/31/06, Scott Cantor 
<>
 wrote:
> > The basic idea is to have a set of profiles for "X.509 Subjects", that
> > is, SAML assertions and profiles built around the X509SubjectName
> > identifier.
>
> Yeah, I'm just not convinced of the need for some of your constraints on the
> relationship between SAML and certificates. Maybe for some deployments, but
> that's a policy not a profile.

So you'd feel better if some of those requirements were MAY rather than MUST?

> > I think I know what you're going to say :-)  "You have to invent a
> > whole set of new profiles just for X509SubjectName!"
>
> If by that you mean I'm going to say I think X.509 subject naming is
> orthogonal to all of these profiles, then you're right. I see no reason why
> it's relevant to anything. Names are just names, and attaching meaning to
> names inside of deployments is not a SAML thing, it's a deployment thing.
> That's why I think all the old formats are useless and interchangeable.

At one level, yes.  That's why I was able to write the
PrincipalNameIdentifierMapping plugin that handles all the old formats
simultaneously.  It shows that the distinction between formats is
virtually nonexistent, yes.

GridShib doesn't use PrincipalNameIdentifierMapping, however.  It
doesn't work for us.  The name mapping plugin that GridShib uses
searches a series of persistent data stores (files and/or tables) for
the mapping.  Thus existing Grid users have to register their cert
with the IdP.  An online CA that issues short-term certs to new Grid
users also registers the cert with the IdP.  Then when the Grid SP
comes along with a query, it can extract the DN from the certificate
used to authenticate the principal, and use the DN to construct a
query.  Since the cert was previously registered with the IdP, mapping
it to a principal name is possible.

> These were the two principal design options...

That helps, thanks.

> > Does an extension profile qualify?  (Not sure when a profile warrants
> > to be called an "extension")
>
> The issue is compatibility. When you can send messages of both a basic
> nature and an extended nature to a single endpoint and it's possible for the
> receiver to process both and unambiguously, there's no need for a different
> element because all you're doing is adding to what's already indicated. You
> can add optional attributes to signal support for things without affecting
> existing client code.

That also helps, thanks.

> In this case, it's just a matter of whether you expect a single endpoint to
> respond to both 2.0 queries and whatever you think this other thing is. It's
> not clear to me yet why this other thing is even needed if it is within the
> bounds of a deployment of 2.0 query behavior.

The Shib IdP has enough extension points that so far we've been able
to avoid a new protocol endpoint.  The push use case is a different
matter, however.  That requires a new protocol endpoint at the IdP
(similar to LionShare).

> Making certain security features required is a deployment choice, not
> necessarily a profile. When BAH originally proposed it, I said "why do we
> need a profile if the conformance spec already makes all those knobs MTI?"

I totally agree with that.  Again, that's why I've been keen on
rewriting that spec.  Hopefully, we'll get it right eventually. :-)

Tom