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