Shibboleth Developers

[Alistair Young <>]

Thanks for being patient again Scott,

This is strictly SAML1.1 - I have no issue with the SAML2 profile.

The profile seems to be "best practice" for attribute handling, said 
best practice having come from Shibboleth in the field. It's a snapshot 
of part of the Shibboleth profile? (duck!)

> strictly speaking, you could argue that MACE-Dir (as the caretakers of
> eduPerson) had no business assigning names to attributes in 
> inetOrgPerson
...
> is the real problem here that MACE-Dir assigned
> names to attributes from object classes that aren't defined by us?
well, it's not really a problem per se. When I first came across it, I 
was slightly surprised but you're correct in thinking along those 
lines. I did think whether this was actually allowed. There are a load 
of LDAP attributes not contained in the eduPerson spec but the move to 
OID is a welcome one, IMHO.

The profile is specific to eduPerson but eduPerson is just a subset of 
many different LDAP schemas. Would it be possible to make the profile a 
more wide ranging LDAP specific? Then it would provide a way for 
federations to transmit any LDAP attribute, rather than just eduPerson.

The logical way would be to separate eduPerson into it's own schema and 
rely on the OID in SAML2 - is that the future? All the other non 
eduPerson attributes that are contained in the eduPerson spec have 
their own OIDs anyway. As well as those other LDAP attributes that 
aren't in the eduPerson spec.

Of course, there are cases where IdPs are spitting out non LDAP 
attributes - we have some here but another profile could be developed 
for that. In fact, we'd be more than happy to do one.

CDM (Course Description Metadata) is gaining ground here and if the 
SAML1.1/2 profiles were modified to cover anything with an OID, it 
could inform interoperability with such things as CDM and VLE specific 
attributes.

thanks again for your comments,

Alistair


On 19 Apr 2005, at 22:05, Scott Cantor wrote:

> > > > > There is no such requirement
> > it says in the document:
> > "...AttributeNamespace XML attribute in <saml:Attribute> elements
> > MUST be set to urn:mace:shibboleth:1.0:attributeNamespace:uri..."
> >
> > sorry, I completely misread that - I thought it said MUST!
>
> Alistair, it says MUST only for these attributes. Not for all 
> attributes
> that could ever be defined in some other profile. This is a binding of
> eduPerson (and some other attributes, I suppose) specifically. That's a
> binding that is ultimately dictated by the group responsible for 
> maintaining
> that spec.
>
> Now, the reaon why the URN is what it is is because the group 
> responsible
> for defining the profile originally was the group working on 
> Shibboleth. At
> the time, the URN was not conceived as an eduPerson-specific thing, but
> rather as a way to encourage the practice of URI-based naming and 
> emphasize
> the problems with AttributeNamespace. So if you're asking me, should 
> all
> URI-named attributes use that AttributeNamespace, my answer would be 
> "why
> not?" You have to pick something.
>
> But that doesn't make it a requirement.
>
> > The proposal is for SAML profiles, not shibboleth ones when in fact 
> > the
> > proposed standard urn value is to stop shibboleth breaking.
>
> Sorry, that's simply not true. Shibboleth couldn't care less what the 
> value
> is for any given attribute. It defaults that value in a few spots for
> brevity, but it can be overridden.
>
> However, the interoperable use of eduPerson and some related 
> attributes was
> defined by this community in a specific way. You can disagree with it, 
> but
> that doesn't make this profile Shibboleth-specific. It is what it is, 
> as I
> keep saying. We did it. There's no going back except to needlessly 
> break
> existing applications exchanging these attributes.
>
> Shibboleth itself doesn't care. You just have to go into every 
> configuration
> file that references these specific attributes and specify a new name 
> for
> things we already named. I don't see how that's justified.
>
> > You say it's not shibboleth but changing the urn would break 
> > shibboleth.
>
> That is false. It would break *deployments* of Shibboleth. There is a 
> big
> difference.
>
> I'll be honest. There are some messy things the Shibboleth software is 
> doing
> right now. Things we'd much rather stop doing. And the really nasty 
> ones
> we're not making part of this profile and we want 1.3 to be able to 
> strictly
> support this profile.
>
> But this is NOT one of them. It's just a URI. It doesn't mean anything.
>
> > Why can't the URN be owner specific? e.g. for eDirectory attributes, 
> > why
> > wouldn't you use urn:novell:edir or something, rather than shibboleth?
>
> That leads to complete chaos. The AttributeNamespace has no meaning in 
> SAML,
> it is quite simply part of the name. The same attribute has a 
> different name
> based on what directory you get it from? How does that interoperate for
> anybody? The name just needs to be unique, period.
>
> > The namespace uri is Shibboleth, there's no getting away from that. 
> > If a
> > non shibboleth implementation wants to transmit givenName, why would 
> > it
> > even consider using a shibboleth uri?
>
> Well, strictly speaking, you could argue that MACE-Dir (as the 
> caretakers of
> eduPerson) had no business assigning names to attributes in 
> inetOrgPerson,
> etc. But what were we supposed to do? We had to give them names, 
> because we
> wanted to use them. It only made sense to be consistent.
>
> Again, the point of that URI is *not* to tie the attribute name to
> Shibboleth, it's to try and convince people not to use 
> AttributeNamespace.
>
> Now, I wanted to get rid of it in SAML 2.0, but I wasn't fully 
> successful.
> But we did manage to get it turned into something else, NameFormat. 
> And the
> built-in NameFormat for URI-based names looks an awful lot like the
> Shibboleth URN that you're concerned about. That's not an accident.
>
> > Why even impose uris on attributes? SAML provides the buckets, the
> > profiles provide the way you push the buckets about. What's in the 
> > buckets
> > has nothing to do with shibboleth or even SAML for that matter.
>
> THIS IS NOT A SHIBBOLETH SPEC.
>
> I don't know how to convince you, but it's not. It is a set of rules 
> for
> mapping eduPerson and related LDAP attributes into SAML. It is based 
> on the
> way we did that in our deployments. It is not tied to our 
> implementation of
> SAML. It is compliant with SAML. It is legal. It may not be optimal, 
> but
> last I checked, not everything is.
>
> We have to define the names and syntax for these attributes or 
> deployments
> that use them will not interoperate.
>
> > If you want interop, I'll believe decomposition and oids but it 
> > smacks of
> > too much control when you want to impose deprecated profile 
> > signatures on
> > actual attributes.
>
> So you'd break all of our deployments just to change a meaningless URI 
> to
> some other meaningless value?
>
> Let me ask a question...is the real problem here that MACE-Dir assigned
> names to attributes from object classes that aren't defined by us? 
> Because
> that's at least an argument I could understand.
>
> -- Scott