Dealing with Compounded Attributes

[Cantor, Scott]

On 6/24/14, 12:19 PM, "Christopher Peters" <cjpeters at uci.edu> wrote:

>Last year, we made the somewhat unwise decision to add encodings to
>attributes to support both the URN:MACE and OID namespaces.  That is to
>say, for all our core attributes each AttributeDefinition has two
>encoders per protocol.  e.g.

There are no urn:mace names for attributes in SAML 2. Not one that I can
think of offhand.

>So far, we have been working around the issue--sometimes the SP drops
>dual-protocol support.  Sometimes, I release a special attribute with
>only one encoding.  I would like a more permanent solution, either in the
>form of good configuration directives, or just better standardization.

We did standardize it, you're not following the profile, that's all.

>1)  Is it wrong to have two encoders on an attribute?

Not in all cases, but it's a bad thing to attach a non-existent name that
is actually a name for an attribute in another SAML version. Those names
simply don't exist for both SAML versions.

>  It serves the purpose we had of matching the name no matter which
>scheme the SP chose.
>  And it didn't seem to me that URN:MACE or OID formats were specific to
>a particular protocol--they are just two different names for the same
>thing.

That is definitely untrue, so that's a misunderstanding.

>  But it certainly hasn't worked out as cleanly as I was hoping it would.
> I think that's largely because the default examples is to use OID for
>SAML2 and URN for SAML1 and that has become the defacto standard.

Those aren't purely examples, they are defaults derived from the I2MI
attribute profile for eduPerson that Shibboleth adopted. The SAML 2 names
come from the SAML 2 standard, so are de jure, not de facto. The SAML 1
names were assigned by MACE-Dir as part of the original pre-SAML2 profile,
and since several of them were invented by MACE-Dir, it was up to MACE-Dir
to assign the SAML names, so that again is de jure. The de facto cases
were the legacy LDAP attributes that weren't defined by eduPerson. We took
a wrong turn in naming them, and that's purely profile convention. But it
is well-defined.

>What would really make my life simpler is an improvement to the SP code
>that took the attributes and when it saw "12345;12345" just returned
>"12345".  The classic array dupe reduction.  But I'm not looking for an
>improvement to Shibboleth to solve my issue.

Suffice to say this is not so easy due to a variety of things the SP is
doing with aliasing names, and would have to be done so late that it adds
cycles to every HTTP request. I've considered having an option to do so as
a just in time step, but it would be off by default. Or the SP will
eventually just not support aliasing, and that will make it more practical
to do this.

>In the end, if there's not a simple fix my larger scale resolution will
>be to split the encodings into two separate attributes on the IDP side
>and release the right ones at the right time, but that's confusing to
>maintain.  

As Peter said, the defaults already have examples of all the right
encodings. There's nothing to maintain. If you see a MACE name, it's SAML
1, period. If you don't see one, or ar adding something new, use an OID if
it's an LDAP attribute. That's pretty much it. The only use case for
duplicate encodings is to support something that's not a standard, and
usually that's better done with a second attribute definition and a
dedicated encoding, and then just releasing that attribute.

-- Scott