attribute resolver, filter, and value munging
cantor.2 at osu.edu
Fri Apr 29 20:30:48 UTC 2022
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
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.
More information about the users