Shibboleth Developers

["Scott Cantor" <>]

> No, not in any version I'm familiar with (and I think I've 
> read them all).

Ok, I'll review again, I could have sworn there was a client->SP step in the
sequence diagram.

> GridShib relies on separate metadata files, so the problem didn't
> occur to me until recently.  Once I added metadata requirements to the
> Attribute Sharing Profile (to distinguish the two subcases in that
> profile), I realized there was a problem.

Ok, I didn't realize that, but that would definitely be an issue. Of course,
I don't 100% know what the GridShib IdP extension does. If it's just
NameMapping, that's not a separate endpoint consideration and wouldn't be in
metadata (supported Name formats are not discriminated by endpoint).

If it's actually a different query profile from Shibboleth's, then yeah,
we're both overloading the <AttributeService> element for SAML 1.x. Both
wrongly, arguably.

> GridShib relies on the emerging Attribute Sharing Profile for X.509
> Authentication-based Systems, not plain vanilla 2.0 queries.

It's not clear to me that it's justified defining endpoint extensions to
document security policy settings. We never have before. SAML doesn't say
anything about how the SOAP binding gets used re: authentication, for
example.

What else is really in the current Booz-Allen profile beyond "MUST sign,
MUST encrypt, etc."? Why is that really a different profile?

> I understand that, I'm just pointing out limitations in the use of
> metadata.

But so far the ones I know about are mostly deployment of security settings,
thus my comment.

> If every AttributeService endpoint were identified by a URI
> in metadata, there wouldn't be a problem.

The "profile" is implicitly captured by the element name. This is how the
schema works. if you need a different profile, you need a new element name,
generally. Or possibly just extension attributes to indicate extension
behavior, depends on the degree of change.

So <md:AttributeService> means the SAML 2.0 profile (or more recently it can
also mean the SAML 1.x query).

Anything else shouldn't really use that element unless it's substantially
the same and backward compatible with it.

> At least two metadata files are needed, one for the
> SAML profiles (which are not identified by a URI in metadata) and
> another one for all the rest (assuming everything from here on out is
> identified by a URI in metadata).

No, I think what you want is extensions.

-- Scott