[OGSA-AUTHZ] VO SAML Attribute Profile

[Tom Scavo]

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 at gmail.com> wrote:
> 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
>