duplicate attribute value issue in idp 2.3.3

[Tomas Hautala]

Chad La Joie <lajoie at itumi.biz> wrote:


It's only a blocker if you choose not to spend 30 seconds working
around the issue.

I'm not denying it's an issue.  It is, it's a bug and I'll fix it.
But given that it's a bug that is very limited in scope and has an
easy work around, I'm not going to rush out a new release.  I'm going
to wait and see if anything else turns up and then, if it does, fix
those things along with this one for the next release.

On Wed, Aug 3, 2011 at 03:06, Kristof Bajnok <bajnokk at niif.hu> wrote:
> On 2011. August 2. 17:35:05 Chad La Joie wrote:
>> 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.
>>
>> Given the limited scope and ease of mitigating the problem I am not
>> going to do an immediate IdP release for this unless additional errors
>> show up that I haven't yet spotted in the code.
>
> I don't know, how other federations cope with the "Please Give Me Some Opaque
> Persistent User Id" problem, but currently we achieve this via the SP
> requesting ePTID as an attribute. (There are some idps not being able to
> supply persistent name identifiers.)
>
> Plus, our centrally generated attribute filter policies are grouped for each
> relying party, therefore there are certainly many attribute duplications.
>
> I just wanted to add that this bug is indeed a blocker for us.
>
> Kristof
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>



--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net