Hi Tom, On Sun, 2008-01-13 at 20:31 -0500, Tom Scavo wrote:

Hi Valerio,

Thanks for writing up this profile. I would call it a "VOMS Attribute Profile for SAML V2.0," but regardless of the title, I think it's Well, the point is that the main driver for this profile is Krzysztof Benedyczak, which is working for the chemomentum project on an attribute service for VOs. So using a brand like VOMS didn't seem appropiate.

ultimately a very important document for VOMS-SAML interoperability.

Your profile diverges from existing SAML profiles and conventions in a number of important ways. I'll highlight just a few of these distinctions in the comments below:

Basically, what you do below is suggesting that we use already existing attribute profiles. Just for a clarification, diverging from existing attributes profiles isn't in itelf a treath to interoperability, though it obviously requires every services to implement the agreed profile. Anyway, reusing efforts is always a good thing.

- I could be wrong, but I believe what you call a "VO" corresponds to an instance of VOMS, in which case membership in a VO (example 8.1) is akin to a Shibboleth AA asserting an attribute called eduPersonScopedAffiliation:

We need an attribute able to express that a user is part of a virtual organization. VOMS wasn't the only stakeholder for this draft document, so with VO we meant exactly a VO, but you're right in the case of VOMS this corresponds to a VOMS instance.

<saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string" ldapprof:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" FriendlyName="eduPersonScopedAffiliation"> <saml:AttributeValue xsi:type="xs:string">member@voName</saml:AttributeValue> </saml:Attribute>

The above attribute satisfies three existing profiles:

1. X.500/LDAP Attribute Profile for SAML V2.0 2. XACML Attribute Profile for SAML V2.0 3. MACE-Dir Attribute Profile for SAML 2.0

The first two are specified in [SAML2Prof] while the latter is found here:

http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-saml-attri...

Conformance to the MACE-Dir Attribute Profile is important for interoperability, I think.

It's definitely going to help interoperability with services already using the MACE-Dir profile, so you're right, it's important. I'm wondering whether using eduPersonScopedAffiliation is going to confuse things. I mean, if a service receive the attribute above, the only way to understand whether a vo membership or 'affiliation within a particular security domain in broad categories such as student, faculty, staff, alum' is meant is to know that the authority is a VO service or a campus IdP. A a policy to allow member of a VO accessing a resource, or member of a 'particular security domain' woudl look the same. I don't know whether that is a real treath, until you have the id of the particular security domain is the same of that of the VO. I'm just wondering whther we don't want something that's easy to recognize as vo membership.

(By the way, if I'm right, and VOMS is analogous to a Shibboleth AA, then every VOMS instance needs a unique identifier called an entityID. This entityID must be a URI (not a DN), otherwise the Grid SP can not use SAML metadata.)

- In 2005, MACE-Dir-Groups (http://middleware.internet2.edu/dir/groups/) specified a LDAP representation of the isMemberOf attribute:

http://middleware.internet2.edu/dir/docs/internet2-mace-dir-ldap-group-membe...

So, your example 8.2 can be expressed as follows:

<saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string" ldapprof:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.5.1.1" FriendlyName="isMemberOf"> <saml:AttributeValue xsi:type="xs:string">voName:group</saml:AttributeValue> <saml:AttributeValue xsi:type="xs:string">voName:group:subgroup</saml:AttributeValue> </saml:Attribute>

Here, the group hierarchy is denoted with colons (not slashes), which agrees with Grouper (the follow-on project to MACE-Dir-Groups):

http://grouper.internet2.edu/

Using this notation, a group name is simply an URN.

Good. VOMS users are going to be a bit puzzled by the colons instead of the slashed, but that could be a good tradeoff.

One last comment and I'll stop and let you respond. I would try to avoid defining a scope attribute for the <AttributeValue> element. As you'll see in the MACE-Dir Attribute Profile, Shibboleth defined a Scope attribute early on, an unfortunate incident that the project regrets to this day. Indeed, much of their profile exists solely to work around this legacy Scope attribute. Even though your proposed scope attribute is namespace qualified, it strikes me as a step backward.

Yes, I knew that MACE-Dir has decided for using an @ delimiter as in eduPersonScopedAffiliation above, and I was in favour of that too. Do you know of existing profiles that let express what we need for the role. If we had to define an attribute for expressing scoped role, I'm wondering whether this wouldn't waste the effort for sticking to existing profile for vo and groups. I mean, services implementing MACE-Dir won't be using roels this way, unless they implement what we are going to define, and in tha case they may be willing to implement also what we may come up with for vo and group. Valerio

Krzysztof Benedyczak wrote:

Tom Scavo wrote:

...

So, your example 8.2 can be expressed as follows:

<saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string" ldapprof:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.5.1.1" FriendlyName="isMemberOf"> <saml:AttributeValue xsi:type="xs:string">voName:group</saml:AttributeValue> <saml:AttributeValue xsi:type="xs:string">voName:group:subgroup</saml:AttributeValue> </saml:Attribute>

Here, the group hierarchy is denoted with colons (not slashes), which agrees with Grouper (the follow-on project to MACE-Dir-Groups):

http://grouper.internet2.edu/

Using this notation, a group name is simply an URN.

I don't think it is an URN - no 'urn:' prefix, no NSS part (which should determine syntactic rules for the tail). Also it clearly offends the RFC in the point: "Global uniqueness: The same URN will never be assigned to two different resources".

Of course I agree that interoperability with the software like Grouper is desirable. But except of it, do we have any other reasons for making it an URN?

Yeah, those group identifiers are not, and never were, URNs, they're just : delimited group identifiers. That said, using URN *might* be a good for one of the reasons you point out, namely, it's likely that you do want these things to be unique. My group "foo:bar" shouldn't collide with your group "foo:bar". Now, the problem with the use of the URN in this case would be that any VO would need to acquire a NSS.

...

One last comment and I'll stop and let you respond. I would try to avoid defining a scope attribute for the <AttributeValue> element. As you'll see in the MACE-Dir Attribute Profile, Shibboleth defined a Scope attribute early on, an unfortunate incident that the project regrets to this day. Indeed, much of their profile exists solely to work around this legacy Scope attribute. Even though your proposed scope attribute is namespace qualified, it strikes me as a step backward. Can you elaborate on this a little bit more? I think it is the most important and difficult topic in case of the discussed profile. Do you suggest to drop scope information at all or to encode it in different way or in different place? Can you also give more details why it was so "unfortunate" for MACE-Dir? We obviously don't want to repeat the same mistake.

The biggest thing was the havoc it caused with other SAML software. A mistake that we've made numerous time in Shibboleth is assuming that other implementors aren't taking shortcuts. In this case, we assumed that because an AttributeValue could, in theory, contain any type of complex data implementations would either provide a way of handling such data or provide a good way for applications to get at the unaltered data. Neither proved to be true. Most SAML implementations can only really support strings and will totally ignore any type indicator, some (ADFS) will even error out in some cases if you send it more complex data. -- 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@switch.ch, http://www.switch.ch

On Jan 17, 2008 3:33 AM, Krzysztof Benedyczak <golbi@mat.uni.torun.pl> wrote:

Tom Scavo wrote:

...

<saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string" ldapprof:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.5.1.1" FriendlyName="isMemberOf"> <saml:AttributeValue xsi:type="xs:string">voName:group</saml:AttributeValue> <saml:AttributeValue xsi:type="xs:string">voName:group:subgroup</saml:AttributeValue> </saml:Attribute>

Using this notation, a group name is simply an URN.

I don't think it is an URN - no 'urn:' prefix, no NSS part (which should determine syntactic rules for the tail). Also it clearly offends the RFC in the point: "Global uniqueness: The same URN will never be assigned to two different resources".

Of course I agree that interoperability with the software like Grouper is desirable. But except of it, do we have any other reasons for making it an URN?

Of course you're right, Krzysztof. I didn't quite take the example far enough. Since I wrote the above example, however, I've had a change of heart. Maybe a URL is easier to deal with than an URN. Consider the following deployment scenario involving a (real) VO, groups, and roles. Suppose, for example, UIUC and UIowa jointly offer a graduate-level geography course (GEOG 602) to advanced undergraduate and graduate students at both institutions. The first semester this joint course is offered, it is agreed that the GISolve gateway (VO name: http://gisolve.org) deployed at UIUC will support all students taking the course. Consequently, each student is obliged to obtain a GISolve gateway account at http://www.gisolve.org/. Now it turns out that the GISolve gateway proxies grid requests to a resource provider (RP) on the back end. To distinguish grid requests originating from the two groups of users (uiuc.edu and uiowa.edu), the RP (hosted by NCSA at UIUC) requires isMemberOf attributes with one of the following values: http://gisolve.org/uiuc.edu/geog602 http://gisolve.org/uiowa.edu/geog602 To further distinguish requests, the gateway and RP together define roles (faculty, student, admin, etc.) that are appended to the relevant isMemberOf attribute values using familiar URL notation. For example, to distinguish between students at each of the two institutions, the following attribute values are defined: http://gisolve.org/uiuc.edu/geog602#student http://gisolve.org/uiowa.edu/geog602#student Attributes values such as these have a number of desirable properties. First of all, the VO already owns the namespace, so globally unique attribute values are immediately available. Moreover, URLs are easily parsed by most languages, so processing is a snap. Does anyone see a downside to such a naming scheme? Tom

On Feb 5, 2008 9:03 AM, Krzysztof Benedyczak <golbi@mat.uni.torun.pl> wrote:

Tom Scavo wrote:

...

Does anyone see a downside to such a naming scheme?

Well, I can't really see the reason for putting http:// there, and making it a URL. It'll confuse everybody, actually the above text confuses even my MUA - thuderbird - which allows me to click at those example attributes' values.

Yes, that's a minor annoyance with URL syntax, I suppose.

My and I think general view on URL is that it identifies a resource via a representation of its access mechanism - and it is not true in this case.

In another words, without very serious reason I wouldn't use http:// URLs for things that aren't by any mean resources accessible via HTTP protocol.

A URL need not be resolvable. SAML, for example, recommends URLs for entityIDs (which are formally required to be URIs).

Looking at the other end of your proposition - scoped attribute value encoded with '#':

<whatever>/gisolve.org/uiuc.edu/geog602#student

is nearly the same as my original proposition. My was:

/gisolve.org/uiuc.edu/geog602:student

I should have paid more attention, sorry. I believe we've independently come to more-or-less the same conclusion.

Valerio convinced me that it will be better to use the same notation that MACE profile defines (with '@').

That was my initial inclination as well, but I'm having second thoughts.

Parsing is trivial in any case. The only one tiny issue is to define which are reserved chars and how to escape them. Of course URI encoding rules with percent encoding of special characters is fine.

That's another reason for choosing URIs, the encoding is well defined.

Eventually one minor note: all those examples above should contain vo service id as the "host" component (see the rest of discussion - one service can manage many VOs). E.g.:

http://voservice.uiuc.edu/gissolve/uiuc.edu/geog602#student

Good point.

To summarize: I don't think that a URL is a good choice, a URI is fine with me,

Okay, let me propose the following compromise: group://voservice.uiuc.edu/gisolve.org/uiuc.edu/geog602#student In the case where the voservice is irrelevant or unnecessary, this reduces to group:///gisolve.org/uiuc.edu/geog602#student In fact, the syntax is exactly the same as the well-known file: URIs. What do you think? Is this better?

however at least partial compatibility with MACE-dir is tempting too - that's why we proposed @ notation.

I think we should give this profile our best shot, and then I'd be happy to carry it forward to MACE-Dir for further discussion. Tom

On Feb 5, 2008 6:04 PM, Krzysztof Benedyczak <golbi@mat.uni.torun.pl> wrote:

...

Okay, let me propose the following compromise:

group://voservice.uiuc.edu/gisolve.org/uiuc.edu/geog602#student

In the case where the voservice is irrelevant or unnecessary, this reduces to

group:///gisolve.org/uiuc.edu/geog602#student

In fact, the syntax is exactly the same as the well-known file: URIs.

What do you think? Is this better?

Definitively.

Okay, great! Somebody should write this up before we change our minds! :-)

...

...

however at least partial compatibility with MACE-dir is tempting too - that's why we proposed @ notation.

I think we should give this profile our best shot, and then I'd be happy to carry it forward to MACE-Dir for further discussion.

Sounds good.

Okay, well, rather than wait until we have a document, unless somebody has any objections, I'll go ahead and float some ideas in the MACE-Dir mailing list and see what kind of push back we get. Tom

On Feb 5, 2008 6:04 PM, Krzysztof Benedyczak <golbi@mat.uni.torun.pl> wrote:

Tom Scavo wrote:

...

A URL need not be resolvable. SAML, for example, recommends URLs for entityIDs (which are formally required to be URIs).

I'm not really sure what SAML authors thought when writing the recommendation you mention: "It is RECOMMENDED that a system entity use a URL containing its own domain name to identify itself."

It is anticipated that SAML entities will eventually publish SAML metadata at the location given by their entityID. Tom

Tom Scavo wrote:

On Feb 5, 2008 6:04 PM, Krzysztof Benedyczak <golbi@mat.uni.torun.pl> wrote:

...

Tom Scavo wrote:

...

A URL need not be resolvable. SAML, for example, recommends URLs for entityIDs (which are formally required to be URIs). I'm not really sure what SAML authors thought when writing the recommendation you mention: "It is RECOMMENDED that a system entity use a URL containing its own domain name to identify itself."

It is anticipated that SAML entities will eventually publish SAML metadata at the location given by their entityID. Right, so it means it is or is going to be resolvable. But once again - it isn't an important issue anymore.

Before putting changes into working draft, I'd like to hear Valerio's opinion about the format change. What do you think? Best regards, Krzysztof

On Feb 7, 2008 1:32 PM, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:

On Wed, 2008-02-06 at 10:17 +0100, Krzysztof Benedyczak wrote:

...

Before putting changes into working draft, I'd like to hear Valerio's opinion about the format change. What do you think?

No problem with that. You can go ahead with the doc.

Okay, great :-) While Krzysztof is working on the document revision, I'll float some ideas by the MACE-Dir working group. Tom

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

...

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.) I mean the software which was mentioned in other emails e.g. the last

Tom Scavo wrote: paragraph of the first Chad's post in this thread. This software was the reason for not using (generally much cleaner, I think) an additional SAML attribute value's XML attribute to encode a scope (point 4.2 of initial proposal).

...

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: After reading your answer I think we have some little misunderstanding here. So one general comment here and one more detailed later inline.

I'm perfectly aware that SAML assertion has Issuer id, and - as a whole assertion - will be globally unique. I initially thought that you wish to put literally the Issuer id once again in group: URI. Now as you see the first part of URI as: group://SCOPE/vo_name/group_name/subgroup_name#role and SCOPE is defined for exclusively for the Issuer - every Issuer can have many of them, and those must be unique in the way that never two issuers use the same SCOPE. Do I understand it correctly now? If so two questions: - do we really need the possibility to define multiple SCOPEs for one IdP? For me one such SCOPE per Issuer would be perfectly enough - all other differentiation can be at VO level. - do we suggest some best practice or whatever for establishing those SCOPEs per IdP? I'd like to see it that way (simplified): <Assertion> <Issuer>http://idp.example.com/services/samlImpl</Issuer> ... <Attribute> <AttributeValue>group://idp.example.com/VO1/gr1#ACTUAL_VALUE</..> </...> ... So one SCOPE per IdP + profile has statement which says the it SHOULD be based on Issuer's ID. Does it makes sense?

...

-) 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. Can you explain in more details what do you mean here, please? I.e. do you want to use the same normalization/comparison rules as are used for UUIDs? I guess no, as it makes no sense for general URI which have non-integer components.

...

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. Yes, exactly. So no problem here.

Best regards Krzysztof

I don't think you can safely infer scope from entityID. In Shibboleth, all IdP scopes are called out in SAML metadata. The SP consumes the metadata and says to itself "okay, I'll recognize any of the scopes you've listed here, it doesn't matter to me which one you use for a particular response." And here is my doubt. You mean that *IdP's* metadata contains the scopes which are valid for it? SP process the metadata and later checks if assertion from this particular IdP has one of the scopes defined there? If so what is the sense of such check, as IdP can put any scope in it's

Hi Tom, Thank you for the comprehensive answer. Tom Scavo wrote: metadata (also conflicting with scopes of other IdP)? Probably after taking the Internet2 lecture on the scopes I wouldn't ask this question ;) Except of this question the rest is now clear for me. Best regards Krzysztof

Chad La Joie wrote:

Metadata is not currently self-asserted. So it's not the IdP the defines its metadata. It's the federation that is ultimately responsible for it. So, you have a third-party there vouching that the scope is appropriate for the IdP. So, if you trust that third-party you're good. OK, now everything is clear.

Thanks for the explanations! Best regards Krzysztof

We are also implementing tools that allow to scope the federation metadata (amongst other things) to define who one trusts and with what security attributes etc. The first of these tools is now done and being tested with various collaborators. The tools will ultimately be integrated into the OMII software stack. If people want to see this, I am around at OGF22 and happy to run a demo or two - this in addition to the other demos we have planned showing how we are using the various implementations of the recent authZ specs. Cheers, R. -----Original Message----- From: ogsa-authz-wg-bounces@ogf.org [mailto:ogsa-authz-wg-bounces@ogf.org] On Behalf Of David Chadwick Sent: 15 February 2008 17:24 To: Krzysztof Benedyczak Cc: ogsa-authz-wg@ogf.org Subject: Re: [OGSA-AUTHZ] VO SAML Attribute Profile Of course ultimately this is not scalable nor manageable. I believe Internet 2 are working on a distributed metadata model where everyone can assert their own metadata, self sign it, and manage it. Recipients then will need to configure their own trust rules for who they trust to assert what (which is what PERMIS does today :-) regards David Krzysztof Benedyczak wrote:

Chad La Joie wrote:

...

Metadata is not currently self-asserted. So it's not the IdP the defines its metadata. It's the federation that is ultimately responsible for it. So, you have a third-party there vouching that the scope is appropriate for the IdP. So, if you trust that third-party you're good. OK, now everything is clear.

Thanks for the explanations!

Best regards Krzysztof -- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg

-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** -- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg

Hi Chad, On Thu, 2008-01-17 at 13:57 +0100, 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.

I thought those identifiers were placeholders while an agreement were reached. If an OGF bless will be given to this profile, we may use OGF URIs.

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

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.

Good suggestion.

- Definitely agree that the encoding method described in section 4.2 should be dumped for the reasons given in other responses.

Looks like there's a general agreements on that.

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

You're right.

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

I don't mind that. This way, a consumer would know the subject is in a VO based on the fact that the assertion was issued by an entity representing a VO. Then the consumer is supposed to have knowledge that a certain entityID represents a VO. This would leave us with just having to agree on a common format for entityIDs for VOs. The only problem I would see with that if that if the assertion consumer is supposed to compose an authz request decision, XACML for example, she would have to create an attribute and fill it with the entityID name. One may argue that's not our business to define XACML attributes for VOs, but it is to promote interoperabilities with other specs form the WG.

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

Is that in the scope of an attribute profile? An implementer may well choose to use only the role attriute and not the group. Valerio

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

Chad La Joie wrote:

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

My concern was about SAML XACML profile. Exactly p. 8.5.4: "The syntax of the <AttributeValue> element's content MUST correspond to the data type expressed in the profile-specific DataType XML attribute appearing in the parent <Attribute> element. For data types corresponding to the types defined in Section 3.3 of [Schema2], the xsi:type XML attribute SHOULD also be used on the <AttributeValue> element(s)." I was not sure if it will be all right with this profile to put "DataType=...#string" and xsi:type="restrictedString". But probably it was my misinterpretation and then the proposed schema is fine.

...

...

- 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. Frankly I don't understand the last sentence. Can you explain it, please?

Best regards, Krzysztof