On Feb 12, 2008 10:03 AM, Krzysztof Benedyczak <golbi@mat.uni.torun.pl> wrote:
Tom Scavo wrote:
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.
I mean the software which was mentioned in other emails e.g. the last 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).
Yes, that's what I thought you meant, and hence my remark. When there was only SAML V1.1, people used (implicitly) what is now called the Basic Attribute Profile in SAML V2.0 (section 8.1 in [SAMLProf]). In fact, you might call it the "Very Basic Attribute Profile of SAML V1.1" (I just made that up :) since almost everyone implicitly assumed that both the name and the value were simple strings (whereas the SAML V2.0 Basic Attribute Profile actually gives you a bit more). Consequently, if your implementation assumed more than string, or relied on any extension whatsoever, you quickly realized that your implementation was not interoperable with the majority (almost all) of the implementations out there. In the case of legacy Shibboleth, they not only introduced an XML attribute to the AttributeValue element, but the XML attribute was not namespace-qualified. What ensued (to this day) can only be called chaos. On the other hand, in SAML V2.0 we have some actual attribute profiles to work with, so if we stick to those profiles, we're okay (in principle). There's no reason to worry about the old implementations since SAML V2.0 is not meant to be backwards compatible with SAML V.1.1 anyway. Now in the end we may choose to stick with string as opposed to URI because it makes our lives easier (I'm not convinced either way yet) but we don't have to consider broken SAML V1.1 implementations when making this decision.
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.
No, that's not what I meant, sorry.
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?
Yes, these scopes have been used by the eduPerson spec and the Shibboleth software for quite some time. They're everywhere. I know some people in Internet2 who could give a one-hour lecture on the subject of "scope." :-)
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.
Well, an IdP may indeed be associated with multiple scopes. For one thing, DNS names are case insensitive while XML is otherwise, which leads to multiple scopes (uiuc.edu, UIUC.EDU, etc.). So it's not reasonable for an IdP to have just one. On the other hand, you as a relying party may want to recognize just one scope (subject to policy) and you're free to do that, but I don't think that's a reasonable restriction given the fact that IdPs (in general) possess multiple scopes. You can't tell the IdP how many scopes it should have. You CAN tell the IdP that you, as a relying party, recognize only one scope, however. I wouldn't do it, but you could.
- do we suggest some best practice or whatever for establishing those SCOPEs per IdP?
The only thing I've seen used is the DNS name, which most people seem to be comfortable with.
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</..> </...>
I would reduce that to "example.com" since my eduPersonPrincipleName would be trscavo@example.com, not trscavo@idp.example.com, in that security domain. At the IdP, a single scope is used for many purposes. If I were an architect at example.com, I'd choose scope "example.com" over "idp.example.com" since the former would find broader applicability within the enterprise.
So one SCOPE per IdP + profile has statement which says the it SHOULD be based on Issuer's ID. Does it makes sense?
Well, we can discuss this further, especially within MACE-Dir, but I don't think you're going to get IdPs to agree to a single scope, even if it's just a single scope for this attribute profile only. We can bring it up for discussion, I suppose. 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."
-) 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.
Okay, I'll have to study this issue some more and get back to you. I'm just coming to grips with some of this stuff myself, and until I actually implement it ("the devil is in the details"), I'm afraid I'd just be shooting in the dark. Tom