Attribute value added multiple times to retained value set if multiple policies permit the same values
Description
Environment
Tomcat6 on RHEL6, OpenJDK 1.6.0
Attachments
Activity

ChadC October 8, 2011 at 5:04 PM
Fixed in rev 1006
Scott Cantor October 6, 2011 at 9:33 PM
The behavior in the IDP is described in this bug entry, it's when multiple policies release the same attribute.
The point is that the SP cannot tell that, and cannot assume anything about the meaning of multiple identical values because that is not supported by SAML. They could be duplicates or they could be meaningful, and unless you get guarantees outside of the standard, neither is presumed.

Vlad Mencl October 6, 2011 at 9:19 PM(edited)
Hi Scott, Chad,
Just a final question: are we talking about duplicate values WHEN the underlying IdMS (LDAP) already returns multiple values - or is it that the IdP could be duplicating a single value returned by the underlying LDAP? Even in a case when the IdP is configured to simply return the value resolved from LDAP? Or would the duplication occur only in complex IdP setups?
I'm asking from the point of view whether the duplication potentially affects our use of the IdP - and what kinds of situation could be causing it.
Thanks for bearing with me.
Cheers,
Vlad
Scott Cantor October 6, 2011 at 1:06 PM
Yes, per previous comment, that is exactly what Scott means. That has always been true, irrespective of this bug. SAML simply doesn't guarantee what you're asking it to, so there is in fact no way to handle such a case explicitly vs. accidentally.

ChadC October 6, 2011 at 10:35 AM
Halm, that is correct.
Vlad, applications must be prepared to deal with duplicate values, period. There are countless ways in which duplicate values might occur. Any given individual may think a particular subset of those ways is incorrect and a different subset is okay. Other individuals will have a different view. But at the end of the day, the SP has to deal with it.
After updating (luckily only a DEV box) from 2.3.2 to 2.3.3, we could test successfully against one SP, but ran into issues with another SP that was requesting "all" attributes:
On the uApprove screen, all attributes had their value listed twice
After confirming in uApprove (or bypassing uApprove on subsequent tries), we got the following error:
https://idp-dev.cqu.edu.au/idp/profile/SAML2/Redirect/SSO
and the following stack-trace in
idp-process.log
:We have worked-around this by down-grading to 2.3.2 - but this appears to be a critical blocker to me.
Cheers,
Vlad
–
Vladimir Mencl, Ph.D.
E-Research Services and Systems Consultant
BlueFern Computing Services
University of Canterbury
Private Bag 4800
Christchurch 8140
New Zealand
http://www.bluefern.canterbury.ac.nz
vladimir.mencl@canterbury.ac.nz
Phone: +64 3 364 3012
Mobile: +64 21 997 352
Fax: +64 3 364 3002