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