duplicate attribute value issue in idp 2.3.3

[Chad La Joie]

It's really nothing to do with SAML 1 vs 2.

The old, bad, ePTID format is encoded as a string, so that is not a
problem here.  The correct format is based on XMLObjects (and the only
attribute that is based on XMLObjects unless there are IdP extensions
that creates XMLObject values) and so is affected by this.

On Tue, Aug 2, 2011 at 11:39, Cantor, Scott E. <cantor.2 at osu.edu> wrote:
> On 8/2/11 11:35 AM, "Chad La Joie" <lajoie at itumi.biz> wrote:
>
>>Okay, so looking at the code, this bug seems to apply only to those
>>attributes whose values are XMLObjects (that is, whose values are
>>known to be XML) and for which multiple filter policies release the
>>same value(s) within a given request.
>>
>>In practice, the only attribute this is applies to (unless you have
>>some custom attribute encoders) are targeted IDs being encoded as SAML
>>NameIDs (the format everyone should be using at this point).  The
>>quick fix is what Arjuna said: move the release of that attribute out
>>to its own policy.
>
> I get this wrong constantly, but IIRC, using one as a NameID is handled
> via the String-based NameID encoders, and not the XMLObject encoders. So
> it would apply to the SAML 1.1 case, but shouldn't actually break the SAML
> 2.0 case (if it's being passed in the subject as suggested in various
> places).
>
> If I'm not misremembering anyway.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered