Dealing with Compounded Attributes

Peter Schober peter.schober at univie.ac.at
Tue Jun 24 12:38:31 EDT 2014


* Christopher Peters <cjpeters at uci.edu> [2014-06-24 18:20]:
> 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 [...]

It is (wrong) and they are (protocol specific): The use of legacy
names is specifically ruled our for use within SAML2, cf. 3.2. of
http://macedir.org/docs/internet2-mace-dir-saml-attributes-latest.pdf

> 2) Is there an easy way--either on the IDP side or SP side--to filter down
> to a single encoding?

Use the software's default configuration? That will release the SAML1
naming convention for SAML1 protocol messages, and the SAML2 naming
convention for SAML2 protocol messages.

> 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.

"Do nothing" seems to work just fine for every other IDP deployment on
the planet?
-peter


More information about the users mailing list