attribute resolver, filter, and value munging

[Cantor, Scott]

On 4/29/22, 2:48 PM, "users on behalf of Christopher Bongaarts via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

>    This was the first solution that came to my mind; the question would be whether the script has access to the
> SP entity ID at attribute resolution time (I think it does, but you might have to do a little work to extract it from
> the ProfileRequestContext->RelyingPartyContext).

Standard field in the resolution context, no work required.

One data connector is all it takes, not one per SP.

>    If not scripting a filter seems like a reasonable choice; again using the SP entity ID to identify a base DN to
> release.

Better to just limit the query in the first place.

>    Both of these assume you have some means of deriving the base DN from the SP entity ID, either directly, or
> (less scalably) a mapping table.

That is the rub.

Also consider what happens if you pass non-unique group names to applications and something goes wrong and you pass "admin" from app 1 to app 2. I wouldn't do that, I'd make sure you compute unique group names from the source system to start with and only pass URIs to applications so there are no accidents.

-- Scott