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