eduPersonTargetedID and transcoder rules
kwessel at illinois.edu
Tue Apr 5 20:04:04 UTC 2022
I tried that last week and, iirc, it also didn't encode the attribute. Seemed like including either of those broke it. I'll try again later this afternoon and let you know. I can certainly leave both out for now, though, as a temporary workaround. I'll try and report back soon, though.
From: Cantor, Scott <cantor.2 at osu.edu>
Sent: Tuesday, April 5, 2022 3:02 PM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: eduPersonTargetedID and transcoder rules
On 4/1/22, 6:08 PM, "users on behalf of Wessel, Keith via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:
> If I remove decoder = false from eptid.properties, though, it
> works. Not the end of the world to have it available for processing
> for decoding in the unlikely event that an upstream IdP should even
> send it or I work some similar magic with it elsewhere. But why does adding decoder = false cause it to stop being processed when encoding the response to the SP?
I don't know, that isn't a heavily used setting but unless I just got the behavior backwards, it shouldn't behave that way.
If you switch that to encoder = false, it would be interesting to see if that encodes, which would strongly suggest it's backwards.
I have only the barest time left to see if there's a simple bug at this point before 4.2 ships.
More information about the users