Defining custom attribute names for SPs that won't map names internally
Cantor, Scott
cantor.2 at osu.edu
Thu Jun 16 12:21:37 UTC 2022
On 6/16/22, 5:27 AM, "users on behalf of Max Spicer via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:
> We have an SP that cannot map released attribute names to their own internal names.
s/cannot/refuses to
Obligatory: I would absolutely refuse this in the majority of cases, and I do that maybe 2-3 times a year.
> In the past we've solved this by defining an attribute encoder that creates an attribute just for that SP and
> then filtering it so it is only released to them. I'm wondering what the "modern" way to do this would be now
> we have 4.2 and the attribute registry enabled.
The same way is perfectly fine.
> we could probably create a new properties file in conf/attributes/custom/ to reference an existing IdP
> attribute and define a new name.
You can do that also.
> Can we then use the relyingParties or activationCondition properties to restrict this to the appropriate SPs?
Yes.
> We generally use entity groups to group related SPs and then filter by entity group rather than specific SPs. Is
> there an example of how to do this sort of thing?
In the topic on activation conditions. Use entity attribute tags, not groups.
-- Scott
More information about the users
mailing list