Skip to Content.
Sympa Menu

shibboleth-dev - RE: SAML 1 Default Attribute namespace

Subject: Shibboleth Developers

List archive

RE: SAML 1 Default Attribute namespace


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: SAML 1 Default Attribute namespace
  • Date: Wed, 21 Mar 2007 14:02:28 -0400

> This is where I'm not following you. Are attribute names URIs in
> general, or not?

Well, no. This is SAML, not the MACE profiles. SAML has never required URI
naming. SAML 2.0 has a NameFormat designating URI naming, but it doesn't
require it.

> If not, can you give an example? Maybe you could
> give a complete <saml:Attribute> example that illustrates your point?

The IdP doesn't deal in SAML attributes, it deals in a neutral internal
class called Attribute. Internally, you give them IDs that are like short
names. We plan for all the ARP and resolve logic to be ID-based, not big,
long, ugly URI-based.

To turn that into a SAML attribute, we use "encoders" that are configured by
the deployer to turn that class object into a piece of XML. That includes
identifying the SAML 1 AttributeName/AttributeNamespace and the SAML 2
Name/NameFormat.

If you think about it, this is great because it means you only define your
attribute once, but all its potential "names" get expressed as encoder
config, for SAML 1, SAML 2, ADFS hard-coded nonsense, etc.

The question being asked is what we do when no encoders are configured. Our
hope was to have default behavior that was "sensible". But it turns out that
"sensible" behavior is not very well-defined for SAML 1. With SAML 2, the
obvious thing is to use the ID as a Name and the unspecified NameFormat.

> I'm looking at the MACE-Dir SAML Attribute Profiles spec and there
> doesn't seem to be any flexibility with respect to AttributeNamespace.
> Will Shib 2.0 implement this spec?

Yes. And you'll have to configure the encoders to do so in order for them to
produce the right XML. Of course, our samples will include this for
eduPerson and the like, just as we do now, but that's not what we're talking
about here.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page