Dealing with Compounded Attributes

[Mizushima, Marcus]

It looks like you've defined both encoders for SAML 2 - I believe the urn:mace:dir:attribute-def names were for SAML 1.1; if that's what you meant than your encoders should be defined as:

        <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"  name="urn:mace:dir:attribute-def:employeeNumber" />
        <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"  name="urn:oid:2.16.840.1.113730.3.1.3" friendlyName="employeeNumber" />

________________________________
From: users-bounces at shibboleth.net [users-bounces at shibboleth.net] On Behalf Of Christopher Peters [cjpeters at uci.edu]
Sent: Tuesday, June 24, 2014 9:19 AM
To: Shib Users
Subject: Dealing with Compounded Attributes

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.

 <resolver:AttributeDefinition id="employeeNumber"
...
        <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"  name="urn:mace:dir:attribute-def:employeeNumber" />
        <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"  name="urn:oid:2.16.840.1.113730.3.1.3" friendlyName="employeeNumber" />

This causes all SAML responses to contain two attribute lines for each attribute encoded like this, and it works fine with SPs that support only a single protocol.  However, almost every SP configured to support both protocols has complained of compounded attributes.   (something like EmployeeNumber:  12345;12345)

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.

To that end, I have two questions:

1)  Is it wrong to have two encoders on an attribute?  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.  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.

2) Is there an easy way--either on the IDP side or SP side--to filter down to a single encoding?  It seems like you can filter out an attribute on the SP side, but only after it's been mapped to an id (not before it gets mapped), so it would already have been compounded at that point.  The same is true on the IDP side.  You can filter out attributes entirely, but only after they've had encodings applied to them.

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.  Maybe there's some way to accomplish this already that I don't know?

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.


--
Chris Peters
Middleware Services Developer
Office of Information Technology - NSP
(949) 824-6845
cjpeters at uci.edu<mailto:cjpeters at uci.edu>