[OGSA-AUTHZ] VO SAML Attribute Profile

[Valerio Venturi]

Hi Tom,

On Sun, 2008-01-13 at 20:31 -0500, Tom Scavo wrote: 
> Hi Valerio,
> 
> Thanks for writing up this profile.  I would call it a "VOMS Attribute
> Profile for SAML V2.0," but regardless of the title, I think it's
Well, the point is that the main driver for this profile is Krzysztof
Benedyczak, which is working for the chemomentum project on an attribute
service for VOs. So using a brand like VOMS didn't seem appropiate.

> ultimately a very important document for VOMS-SAML interoperability.

> Your profile diverges from existing SAML profiles and conventions in a
> number of important ways.  I'll highlight just a few of these
> distinctions in the comments below:

Basically, what you do below is suggesting that we use already existing attribute 
profiles. Just for a clarification, diverging from existing attributes profiles 
isn't in itelf a treath to interoperability, though it obviously requires every 
services to implement the agreed profile.
Anyway, reusing efforts is always a good thing.

> - I could be wrong, but I believe what you call a "VO" corresponds to
> an instance of VOMS, in which case membership in a VO (example 8.1) is
> akin to a Shibboleth AA asserting an attribute called
> eduPersonScopedAffiliation:

We need an attribute able to express that a user is part of a virtual organization.
VOMS wasn't the only stakeholder for this draft document, so with VO we meant exactly
a VO, but you're right in the case of VOMS this corresponds to a VOMS instance.

> <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.1.1.9"
>   FriendlyName="eduPersonScopedAffiliation">
>   <saml:AttributeValue
>     xsi:type="xs:string">member at voName</saml:AttributeValue>
> </saml:Attribute>

> The above attribute satisfies three existing profiles:
> 
> 1. X.500/LDAP Attribute Profile for SAML V2.0
> 2. XACML Attribute Profile for SAML V2.0
> 3. MACE-Dir Attribute Profile for SAML 2.0

> The first two are specified in [SAML2Prof] while the latter is found here:
> 
> http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-saml-attributes-latest.pdf
> 
> Conformance to the MACE-Dir Attribute Profile is important for
> interoperability, I think.

It's definitely going to help interoperability with services already using 
the MACE-Dir profile, so you're right, it's important.
I'm wondering whether using eduPersonScopedAffiliation is going to confuse things.
I mean, if a service receive the attribute above, the only way to understand whether
a vo membership or 'affiliation within a particular security domain in broad categories 
such as student, faculty, staff, alum' is meant is to know that the authority is a VO service or
a campus IdP. A a policy to allow member of a VO accessing a resource, or member of a 
'particular security domain' woudl look the same. I don't know whether that is a real treath, until you 
have the id of the particular security domain is the same of that of the VO.
I'm just wondering whther we don't want something that's easy to recognize as vo membership.

> (By the way, if I'm right, and VOMS is analogous to a Shibboleth AA,
> then every VOMS instance needs a unique identifier called an entityID.
>  This entityID must be a URI (not a DN), otherwise the Grid SP can not
> use SAML metadata.)

> - In 2005, MACE-Dir-Groups
> (http://middleware.internet2.edu/dir/groups/) specified a LDAP
> representation of the isMemberOf attribute:
> 
> http://middleware.internet2.edu/dir/docs/internet2-mace-dir-ldap-group-membership-200507.html
> 
> 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.

Good. VOMS users are going to be a bit puzzled by the colons instead of the slashed, 
but that could be a good tradeoff.

> 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.

Yes, I knew that MACE-Dir has decided for using an @ delimiter as in 
eduPersonScopedAffiliation above, and I was in favour of that too.
Do you know of existing profiles that let express what we need for the role.
If we had to define an attribute for expressing scoped role, I'm wondering whether 
this wouldn't waste the effort for sticking to existing profile for vo and groups.
I mean, services implementing MACE-Dir won't be using roels this way, unless they implement
what we are going to define, and in tha case they may be willing to implement also what we 
may come up with for vo and group.

Valerio