[OGSA-AUTHZ] VO SAML Attribute Profile

[Chad La Joie]

Krzysztof Benedyczak wrote:
> Tom Scavo wrote:
>> So, your example 8.2 can be expressed as follows:
>>
>> <saml:Attribute
>>   xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML"
>>   xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP"
>>   xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string"
>>   ldapprof:Encoding="LDAP"
>>   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
>>   Name="urn:oid:1.3.6.1.4.1.5923.1.5.1.1"
>>   FriendlyName="isMemberOf">
>>   <saml:AttributeValue
>>     xsi:type="xs:string">voName:group</saml:AttributeValue>
>>   <saml:AttributeValue
>>     xsi:type="xs:string">voName:group:subgroup</saml:AttributeValue>
>> </saml:Attribute>
>>
>> Here, the group hierarchy is denoted with colons (not slashes), which
>> agrees with Grouper (the follow-on project to MACE-Dir-Groups):
>>
>> http://grouper.internet2.edu/
>>
>> Using this notation, a group name is simply an URN.
> 
> I don't think it is an URN - no 'urn:' prefix, no NSS part (which should 
>   determine syntactic rules for the tail). Also it clearly offends the 
> RFC in the point:
> "Global uniqueness: The same URN will never be assigned to two
> different resources".
> 
> Of course I agree that interoperability with the software like Grouper 
> is desirable. But except of it, do we have any other reasons for making 
> it an URN?

Yeah, those group identifiers are not, and never were, URNs, they're 
just : delimited group identifiers.

That said, using URN *might* be a good for one of the reasons you point 
out, namely, it's likely that you do want these things to be unique.  My 
group "foo:bar" shouldn't collide with your group "foo:bar".  Now, the 
problem with the use of the URN in this case would be that any VO would 
need to acquire a NSS.

>> One last comment and I'll stop and let you respond.  I would try to
>> avoid defining a scope attribute for the <AttributeValue> element.  As
>> you'll see in the MACE-Dir Attribute Profile, Shibboleth defined a
>> Scope attribute early on, an unfortunate incident that the project
>> regrets to this day.  Indeed, much of their profile exists solely to
>> work around this legacy Scope attribute.  Even though your proposed
>> scope attribute is namespace qualified, it strikes me as a step
>> backward.
> Can you elaborate on this a little bit more? I think it is the most 
> important and difficult topic in case of the discussed profile.
> Do you suggest to drop scope information at all or to encode it in 
> different way or in different place?
> Can you also give more details why it was so "unfortunate" for MACE-Dir? 
>   We obviously don't want to repeat the same mistake.

The biggest thing was the havoc it caused with other SAML software.  A 
mistake that we've made numerous time in Shibboleth is assuming that 
other implementors aren't taking shortcuts.  In this case, we assumed 
that because an AttributeValue could, in theory, contain any type of 
complex data implementations would either provide a way of handling such 
data or provide a good way for applications to get at the unaltered 
data.  Neither proved to be true.  Most SAML implementations can only 
really support strings and will totally ignore any type indicator, some 
(ADFS) will even error out in some cases if you send it more complex data.

-- 
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad.lajoie at switch.ch, http://www.switch.ch