Re: [security-services] comments re draft-sstc-metadata-iop-03

[Tom Scavo <trscavo@gmail.com>]

On Thu, Feb 12, 2009 at 10:04 AM, Scott Cantor <cantor.2@osu.edu> wrote:
> Tom Scavo wrote on 2009-02-12:
>>
>> So the comment I have to make is
>> that it doesn't work for everybody.  Therefore I believe the title,
>> abstract, and introduction should be very clear about the intended
>> scope of this Metadata Interoperability Profile.
>
> I have yet to run into a deployment context in which this doesn't work for
> technical reasons (leaving aside politics and the use of software that
> doesn't support it obviously).

As a very specific example, the Metadata Interoperability Profile does
not work within TeraGrid, a large grid deployment in the US.
Traditionally, the TeraGrid has been (and continues to be) based on
X.509 PKI.  Over the last couple of years, the TeraGrid has begun to
leverage SAML as an authorization token format that augments X.509.
In fact, TeraGrid binds SAML tokens to trusted X.509 certificates and
uses the resulting X.509-bound SAML tokens to convey identity and
attributes to relying parties (i.e., resource providers) on the grid.

The metadata used within TeraGrid has a distinctly different flavor
than the metadata used within a "traditional" SAML federation based on
Web Browser SSO.  In particular, SAML metadata within the TeraGrid is
dominated by <md:KeyDescriptor> elements containing multiple
<ds:X509SubjectName> elements.  Until recently, all TeraGrid entities
have been identified by X.500 distinguished names (DNs) so the
appearance of <ds:X509SubjectName> in SAML metadata within TeraGrid is
not surprising.

As far as I know, all grids throughout the world are based on X.509
PKI.  As grids start to leverage the SAML tokens issued by VOMS (which
I reported on earlier), the metadata format used by TeraGrid will be
rediscovered in other contexts.

Nor do I think X.509-based grids are an isolated example.  If you look
at the Kerberos white paper that we discussed on the last concall, one
of the stated objectives is to "Leverage SAML metadata to enable
large-scale Kerberos cross-realm communities."  Of course it's too
early to say exactly what that might look like, but coming off my
experience integrating SAML with X.509, I'd be willing to wager that
SAML metadata in a Kerberos environment can not be shoe-horned into
the Metadata Interoperability Profile.

> That said, if someone can identify some kind
> of definition that would attach to "who can use this" that would make sense,
> that's fine. But I can't see any obvious way to scope it. It's certainly not
> scoped to SSO, or to higher education.

But there is no evidence to the contrary.  The SAML metadata
specification, like much of the SAML specification set, is biased
towards Web Browser SSO.  The fact that we have a "Metadata Extension
for SAML V2.0 and V1.x Query Requesters" is testimony to this fact.
Once you move away from Web Browser SSO, you find less of what you
need in the SAML specifications and end up rolling your own.

So I think the onus is on you to show that the scope of the Metadata
Interoperability Profile transcends Web Browser SSO.  I've given one
actual counterexample (in fact, a family of counterexamples) and
suggested another.  I claim that as SAML evolves outside its primary
use case (i.e., Web Browser SSO), we will see further divergence from
the norm.

Tom