eduPersonTargetedID and transcoder rules
cantor.2 at osu.edu
Tue Apr 5 23:21:55 UTC 2022
On 4/5/22, 6:41 PM, "users on behalf of Wessel, Keith via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:
> Attributes are being released by <RequestedAttributes> elements in metadata and an attribute filter policy
> that releases any requested attributes from metadata to any SP in this particular group. With decoder = false, I
> get no attribute released. Without decoder = false, I do.
That's what decoders do, they translate SAML to IdPAttribute. The RequestedAttributes syntax is SAML, it has to be converted into the internal form (at least as far as mapping naming) to identify which attributes to release.
If you set decoder = false, that short-circuits the knowledge it needs.
When you attach an AttributeEncoder the older way, that's implicitly a decoder and an encoder, it's a silly way of building the reverse mapping rules because until all that was replaced, it was the only way to do it.
Transcoding is normally bi-directional. The only real reason I added the ability for directionality was for proxying, in case you want to support a bogus mapping inbound without reflecting it outbound. So encoder = false would be the typical use case, not the other.
More information about the users