Dealing with Compounded Attributes

[Christopher Peters]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140624/03e980a3/attachment.html