Shibboleth Developers

[Keith Hazelton <>]

Alistair:

I'd suggest pulling this apart into two issues:

1) How attributes are handled in Shibboleth today (and "historically"). 
That is the topic of section 2 of the document.
2) How we propose to handle attributes in SAML 2 environments, including 
Shibboleth 2.x That is covered in section 3.

Looking at section 3 first, what is being proposed is scoped to
 1) Attributes originating in X.520 and in RFC-defined extensions such 
as inetOrgPerson
 2) Attributes defined by the MACE directory working group (which I 
chair). 

In both cases, each defined attribute is always assigned an OID by the 
authoring party.  The proposal in this document is simply that we adopt 
the X.500/LDAP attribute profile of SAML 2 (see section 3.3).  
Specifically, that the attribute's officially assigned OID be used as 
attribute name in the urn:oid syntax.  So for this case, there is no 
Shibboleth-specific aspect at all that I can see.  Moreover, this says 
nothing about attributes that other parties create and use,  urn-based 
or no.

As for the SAML 1.1 situation covered in section 2, this was developed 
before the above SAML profile existed, and we (Shibboleth developers and 
the MACE Directory Working Group) came up with the attribute-def 
approach. It has allowed early implementations to interoperate, and to 
that extent it seems useful.  But it was a first effort to define this 
space, and it will be made obsolete by SAML 2- based versions of Shibboleth.

If I missed the point of any of your concerns, please let me know.

        Regards,  --Keith
_______________________

Alistair Young wrote:

> The decomposition of eduPersonTargetedID into xml elements is an 
> interesting move. I can see it sorting problems, especially of hard 
> coding syntax, also the OID use for new attributes is good for 
> interop, though a bit more effort on the developer side.
>
> The thing that makes me uncomfortable is the requirement for a 
> Shibboleth URN for all attributes. givenName is nothing to do with 
> Shibboleth, so why should I have to use a shibboleth URN?
>
> Shibboleth is a SAML profile, so what you seem to be doing is 
> profile-qualifying attributes. I can't see any other reason as 
> shibboleth don't "own" the attribute and shibboleth isn't a URN 
> provider in any way, so it seems to be a profile qualifier. The 
> attribute now seems to be bound to the implementation of whatever 
> profile you're using.
>
> So, whereas we've got rid of one hard coding scenario for SPs, 
> eduPersonTargetedID, we've introduced another - the requirement for 
> IdPs that talk to shibboleth SPs to use a shibboleth URN. Guanxi 
> IdP/SPs use whatever URN you want and I think this is the way it 
> should be.
>
> Shibboleth (the implementation) is a filter that matches rules against 
> incoming attributes. You can specify whatever URN you like for an 
> attribute. Now it seems that is not allowed and you must use the 
> shibboleth URN.
>
> Are we just seeing another strand in the shibboleth web? i.e.
> Shibboleth - the protocol
> Shibboleth - the implementation
> Shibboleth - the default implementation of attribute URN
>
> I welcome the decomposition and OID but I'd like some reassurance on 
> the URN that perhaps I'm reading this wrong way.
>
> thanks,
>
> Alistair
>
>
> On 18 Apr 2005, at 07:55, Scott Cantor wrote:
>
> > Attached is a first draft of a pair of SAML attribute profiles for 
> > mapping
> > eduPerson and related bits to SAML 1.x and SAML 2.0.
> >
> > The 1.x profile is mostly documenting current practice on the wire, 
> > bad or
> > unpopular decisions notwithstanding.
> >
> > The 2.0 profile is a stab at "the way we want it to be" and should be
> > carefully vetted well before we put anything on the wire and end up
> > committed to it.
> >
> > eduPersonTargetedID is a problem for both profiles, and my proposal 
> > needs
> > debate, particularly whether to start supporting a "new" syntax in 
> > the 1.x
> > profile or just leave it imperfect and wait for 2.0. This depends to 
> > some
> > extent on expected volume of use. But we need to decide quickly if a new
> > syntax is to be supported in Shibboleth 1.3.
> >
> > This proposal formalizes all the stuff on the wire that isn't in the
> > Shibboleth spec at this point, so it's a key piece of the puzzle to get
> > published.
> >
> > -- Scott
> > <draft-internet2-mace-dir-eduPerson-SAML-01.pdf>


--
________________________________________________________
Keith Hazelton                  Senior IT Architect, UW-Madison
(608) 262-0771                  Division of Info. Technology
(608) 877-0977 (home)           1210 W. Dayton St., rm. 2164
http://arch.doit.wisc.edu/keith      Madison, WI  53706