Shibboleth Developers

["Scott Cantor" <>]

> What X.509 part?  Are you referring to the use of 
> X509SubjectName identifiers?

No, that part is meaningless but transparent to SAML. I mean the X.509
authentication part.

> I doubt it's that simple.  For one thing, the IdP must be able to map
> an X509SubjectName identifier to a principal name.  That's what
> GridShib does, so think of GridShib as an implementation of the
> Attribute Sharing Profile.

That's an implementation detail of the IdP and is already supported as well
as I think it has to be or can be, modulo whatever API changes are coming.

> In that sense, I suppose I've answered my own question.  So the real
> question is: Will Shib 2.0 support the SAML V2.0 Assertion
> Query/Request Profile at the IdP.

For attribute query, yeah, it's just a dummy profile that was put in for
conformance language. It just means supporting the queries over SOAP with
some minimal authentication mechanisms.

> We need that, I think, since the
> Attribute Sharing Profile is an extension of the Query/Request
> Profile.

I think it's a deployment scenario for it, I'm not sure I'd call it an
extension.

> Well, I could be missing something, but there seems to be a real
> problem here.  So the Shib 2.0 IdP will have AA endpoints that support
> Shib 1.x attribute exchange, SAML V1.1 Attribute Query Profile
> (currently being written), SAML V2.0 Assertion Query/Request Profile,
> and SAML V2.0 Attribute Sharing Profile (standards track).  How does
> an SP find an endpoint that supports a specific profile?

We support Shibboleth attribute queries now and we'll support vanilla 2.0
queries, both of which are distinct SOAP bindings (and protocol URIs). I'm
not sure why the other two things are suddenly in the picture. But if they
have to overload the SOAP binding, then they need their own endpoint
extension attributes, same as the other extensions that have been proposed.

The Shibboleth query wasn't done that way, but it's too late now. Nothing
much I can do about that.

I think it's a mistake to imagine that metadata is the answer to
interoperability. It will never capture everything. Separate endpoints and
per-partner metadata will always be an option to get around limitations.

-- Scott