[OGSA-AUTHZ] VO SAML Attribute Profile

[Tom Scavo]

On Feb 11, 2008 7:03 AM, Krzysztof Benedyczak <golbi at 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 at uiuc.edu
eduPersonScopedAffiliation:  staff at 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 at uiuc.edu
but it may not assert attribute trscavo at 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