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

[Tom Scavo <trscavo@gmail.com>]

On Fri, Feb 13, 2009 at 4:15 PM, Scott Cantor <cantor.2@osu.edu> wrote:
> Tom Scavo wrote on 2009-02-13:
>>
>> If your deployment is
>> based on any other type of PKI---in particular, an X.509-based
>> PKI---then this profile is probably not for you.
>
> This is overstating it, for the reasons I note above. What I guess I would
> say is that if your use of SAML is already substantially subservient to
> X.509, then the profile is probably redundant. But I tend to believe such
> cases will also result in metadata itself being redundant, so that's why I
> have a problem seeing the middle ground where the metadata has significant
> value but the profile doesn't.
>
>> As much as you'd like to assume that use case away, it's not going to
>> happen.  It is what it is.
>
> I think you misread me. I'm saying I'd drop out the metadata, not the X.509.
> Can you outline for me even briefly what it's used for?

The TeraGrid Science Gateway use case is briefly described in the
following paragraph:

A gateway binds a sender-vouches SAML token to a proxy certificate
signed by a community credential (a type of shared X.509 credential).
The gateway requests a grid service on behalf of a user,
authenticating with the proxy credential. The grid service provider
authenticates the gateway (as itself) and accepts the X.509-bound SAML
content describing the end user if the gateway's SAML identifier is on
a list of trusted gateways.

An existing X.509-based PKI handles the X.509 authentication.  The
X.509-bound SAML token is an authorization token.  At the grid SP, the
SAML layer requires the following metadata:

entityID "DN1" "DN2" ...

This metadata serves two purposes.  First, it defines a mapping from
SAML issuers into X.509 issuers.  This mapping is used to distinguish
a self-issued SAML token (where the SAML issuer and the X.509 issuer
are one and the same) from some other type of SAML token.  Second, the
union of all DNs constitutes an access control list.  Only X.509
issuers on the list are allowed to bind this particular type of SAML
token.  Conversely, an X.509 issuer on the list is required to bind
such a SAML token.

Currently the metadata is stored in a flat file with exactly the above
format.  However, the following metadata is also required:

entityID Scope1 Scope2 ...

since the gateway asserts scoped identifiers.  Also, gateway contact
information is required in the event of a problem at the grid SP.

Taking all of these requirements into consideration, the SAML metadata
consumed by the grid SP will include a custom <md:RoleDescriptor>
element of type ScienceGatewayDescriptorType containing one or more
<md:KeyDescriptor> elements, each containing a <ds:X509SubjectName>
element.  The custom <md:RoleDescriptor> element also contains one or
more extended Scope elements.  Finally, standard <md:Organization> and
<md:ContactPerson> elements give the required contact information for
the gateway.

That's probably more than you wanted to hear, and maybe most of it is
off-topic, but hopefully it satisfies your curiosity about the use of
SAML metadata within an X.509-based PKI.

Tom