[OGSA-AUTHZ] VO SAML Attribute Profile

[Chad La Joie]

Krzysztof Benedyczak wrote:
>> - 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?

Yeah, the only way you can really do this type of encoding is over 
string data types.  Depending on what you mean by "requires the schema 
of the attribute value to be 'xsd:string'" that may or may not be 
correct.  The type certainly has to be an instance of xsd:string, but it 
could done like the schema fragment I had.  The "groupQualifiedString" 
type is still an "xsd:string".

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

My concerns here are not with the clients that can't support it, but the 
ones who crash because of it.  I would also not include something in the 
spec unless you're actually going to use it in the spec.

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

Okay, that's fine.  Probably just want to say that in the spec.

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

Yes, that seems reasonable.

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