So let me try to summarize in one line: group://scope/vo_name/group_name/subgroup_name#role Does that make sense? Tom On Feb 11, 2008 10:51 PM, Tom Scavo <trscavo@gmail.com> wrote:
On Feb 11, 2008 7:03 AM, Krzysztof Benedyczak <golbi@mat.uni.torun.pl> wrote:
let's consider a XACML policy which grants access for all entities who possess a 'role' attribute with a value 'Admin' in a scope of vo/group: 'SomeVO/Staff'.
Seems straightforward.
1) I assume that an attribute 'X' with value 'V' in scope of 'S1/S2/S3' should be expressed like this: <saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#anyURI" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="X" FriendlyName="friendly X"> <saml:AttributeValue xsi:type="xsd:anyURI" >group://voservice/S1/S2/S3#V</saml:AttributeValue> </saml:Attribute>
I wrote it because it isn't exactly as in Tom's proposal (so is it ok?).
Yes, I had posted an attribute that satisfies both the XACML Attribute Profile and the X.500/LDAP Attribute Profile simultaneously, but this is not required. Your example looks fine to me.
And also another issue: XACML DataType. As I understand the topic about the legacy/trivial/dummy software the problem is with values not being a simple string. Will it be OK for this software when it will see xsd:anyURI?
By "legacy software," I think you mean some SAML V1.1 implementations? Well, the XACML Attribute Profile is new in SAML V2.0, so I don't think backwards compatibility is an issue.
That said, I wonder if it would be better to specify string rather than anyURI. (Thinking out loud here.)
2) URI equivalence test in XACML is simple codepoint-by-codepoint (or UnicodeChar-by-UnicodeChar). Provided that, we come into a nightmare of infinite number of representations of the *same* scope+value pair: -) The VO service URI as part of SAML attribute value will complicate things a lot. Examples: *) group://serivice.org/services/foo - is it VO 'foo' of VOservice service.org/services OR group 'foo' of VO 'services' of VOservice 'service.org'?
The latter. I don't see the problem. For
group://voservice/S1/S2/S3
S1 is the VO name, S2 is a group, and S3 is a subgroup. The slashes are delimiters, as they are in URIs. A URI component can not contain a literal slash. (Sorry if I've stated the obvious, maybe I don't understand your question.)
*) when XACML policy requires 'group:///vo/group#Admin' and PDP receives 'group://VOservice.org/vo/group#Admin' then comparison will fail.
The VO service has to match too, right? You don't want just anybody to be able to assert the group membership.
-) shall we enforce an URI normalization for the 'group:' URIs? For possible examples of it see http://tools.ietf.org/html/rfc3986#section-6.2
Various SAML attribute profiles rely on this spec:
http://www.ietf.org/rfc/rfc4122.txt
I've been told this is easier to implement, but I can't say for sure.
I think that we can take two approaches. Either resign from putting voservice's URI as part of 'group:' URI at all - then it won't be globally unique but most of the problems will disappear.
Yes and no. Remember every assertion has an entityID, that is, the unique identifier of the issuer, so when qualified by the entityID, the attribute value is unique.
I was thinking that the voservice was a "scope" for the issuer. This is "scope" as used by eduPerson. For example:
eduPersonPrincipalName: trscavo@uiuc.edu eduPersonScopedAffiliation: staff@uiuc.edu
Now "uiuc.edu" is a "scope" associated with entityID https://shibboleth.uiuc.edu/idp. An entity may have mutiple scopes, each of which is known to the relying party. Thus the RP can look at a scoped attribute and say "yes, entity https://shibboleth.uiuc.edu/idp may assert attribute trscavo@uiuc.edu but it may not assert attribute trscavo@protectnetwork.org".
The voservice in the group attribute is a scope. As eduPerson defines eduPersonScopedAffiliation and unscoped eduPersonAffiliation, a group attribute may be scoped or unscoped, as required.
Or enforce voservice's URI to be put in 'group:' URI and define a canonical form. It will add uniques but at cost of complicated profile and implementation.
A scope is a globally unique string. I've seen DNS names (such as uiuc.edu) used frequently. I don't think it has to be much more complicated than that.
In favor of the first solution there is one more point - global uniqueness wasn't considered in our previous proposal (so at least we can live without it).
It's not global uniqueness we're worried about, but the RP's ability to recognize valid attribute values. Otherwise an IdP could assert anything it wants and we don't want that.
3) Having 'group:' URIs what about earlier 'VO' and 'group' SAML attributes (defined in the initial version of draft)? I think we should merge them into one attribute proposed by Tom: 'isMemberOf', with group URI syntax as a value. It will be enough to express both VO and group. 'isMemberOf' attribute's namespace would be VO profile-specific.
If you're suggesting "isMemberOf" along with the "group:" attribute value syntax can do it all, I agree with you.
Tom