[OGSA-AUTHZ] VO SAML Attribute Profile

[Tom Scavo]

On Feb 12, 2008 10:03 AM, Krzysztof Benedyczak <golbi at 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 at example.com, not trscavo at 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