[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] comments re draft-sstc-metadata-iop-03
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]