[OGSA-AUTHZ] VO SAML Attribute Profile

[Krzysztof Benedyczak]

Hi,

Chad La Joie wrote:
> So, some of these comments are re-iterations of Tom's which I echo just 
> to indicate my agreement.
> 
> - Very minor title comment.  I'd recommend something like "SAML 2.0 
> Attribute Profile for Virtual Organizations"
> 
> - The document defines a number of URNs in the urn:SAML namespace.  IANA 
> does not have such a namespace registered, if the intention had been to 
> put it into the OASIS SAML namespace, note that you can't do that 
> either.  Also, I would suggest you put in some sort of version indicator 
> into those URNs so that if, for example, the vo attribute definition is 
> changed between one version of a document and the next you can indicate 
> this and the receiver of the attributes can do the appropriate thing.
In both cases I agree - as Valerio said URNs were only random strings 
and we concentrated on more difficult issues.

> - In section 4.1, if you really want that kind of syntax you *may* want 
> to define a special schema type for that encoding, something along the 
> lines of (regexp could be made more precise):
> 
> <xsd:simpleType name="groupQualifiedString">
>     <xsd:restriction type="xsd:string">
>        <xsd:pattern value=".+@(/.+)*" />
>     <xsd:restriction>
> </xsd:simpleType>
> 
Of course - however this pattern depends on the details that weren't 
fully agreed (example: do we use this syntax only for roles or other 
attributes too? If so empty values may be permitted before @ what 
influences the pattern).

I have another remark here. The initial aim of attributes encoded in the 
'@' fashion was to simplify creation of XACML policies, with 
requirements for an attribute in a group scope. Having a simple string 
as a value isn't enough when we use a non-standard XACML DataType (i.e. 
it will require also a non-standard comparison function). So I'd like to 
change the requirement for DataType to be a '...#string' here, what in 
turn requires the schema of the attribute value to be 'xsd:string'.

What do you think?


> I say this knowing that most systems don't schema validate messages and 
> that not all schema validators support pattern restrictions.  However I 
> believe this provides a good, codified, description of what you might 
> say in words as well.
> 
> - Definitely agree that the encoding method described in section 4.2 
> should be dumped for the reasons given in other responses.

So here is the most significant problem for me. I'm not going to reduce 
functionality of the service because there exist poor clients which can 
produce error on SAML response from my service. And I need a way to 
encode arbitrary type of value which is group scoped (e.g. a XML value).

One solution I can see is to limit the VO attributes profile to 
enumerated attributes only (group, VO, role) which are well established, 
have common sense and we can enforce the common encoding for them.

Then the only way for a client to get attributes with the scope encoded 
as in 4.2 would be to ask for all attributes or for all values of some 
attribute.

Is it fine for you? Or maybe other suggestions?

> 
> - In those attributes defined in section 5, I didn't see anything that 
> indicated whether these attributes were meant to be single or 
> multi-valued.  VO attribute is single and group and role are multi, I 
> would guess.
No restriction. Subject can be a member of multiple VOs of which all are 
registered and handled by one service (==SAML assertion issuer).
For me a VO attribute is nothing else then the top level group.

> - Is the VO attribute necessary?  If the assumption is that the VO is 
> asserting this information then its identifier is already going to be in 
> the assertion issuer.  I don't know that it hurts to have it twice, and 
> one reason to do so may be to deal with other SAML implementations that 
> don't provide access to all the information in the assertion.  Also, as 
> Tom noted these VOs will need to be URIs now to server at the attribute 
> authority's entity ID.
Here I agree with the comment made by Tom in another answer (it also 
results from the point above).

> - In section 5.2 you declare a group attribute. In section 5.3 you 
> declare roles, within the scope of a group.  However, you don't have any 
> wording about how you would expect a client to react if a group, given 
> in the scope qualifier of the role, is not included in the list of 
> groups the user is a member of?  i.e. role says I'm "admin" in group 
> "foo", but the group attribute doesn't say I'm in group "foo".
Very good point! I would add a note to the profile that service can 
issue attribute statement for S with a role attribute R@/VO/group only 
if S is a member of /VO/group.


Thanks for the feedback!
Krzysztof