Impersonation and resolutionPhases="intercept/impersonate"

[Michael Grady]

> On Feb 17, 2025, at 2:21 PM, Michael Grady <mgrady at unicon.net> wrote:
> 
> 
> 
>> On Feb 17, 2025, at 2:01 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>> 
>>> Is there some very basic thing I've done wrong? (This is with
>>> v5.1.3, and its a RDB type DC.)
>> 
>> I suspect in fact neither is working, for reasons too complex to explain [1], but in general the feature didn't work right in a lot of cases, and I would guess that's one such case.
>> 
>> But it's not going to be specific to part of the resolver, it's a problem in getting to the label when executing the condition and so the label is being ignored in many cases.
>> 
>> Fixed in 5.2.0.
>> 
>> -- Scott
>> 
>> [1] https://shibboleth.atlassian.net/browse/JSATTR-36
>> 
> 
> 
> Thanks! I'll use a metadata tag-based activation condition for now, until we get this one to 5.2.
> 
> --
> Michael A. Grady

One more somewhat related question on the value of resolutionPhases (when 5.2 comes out). I know the value for that is set to  "intercept/impersonate" when resolving attributes to be relied on in the impersonate flow, but will it also be set to that same value if the user chooses someone to impersonate, and attributes need to be "re-resolved" for that new userid?

I ask because I was wondering if one would want to potentially "not resolve" the main DC (complex DB query) if the resolutionPhase was "intercept/impersonate", and only run the impersonate-specific DC. But clearly if the re-resolve as a different user still was labelled as the "intercept/impersonate" phase, one would not want to do that -- the main DV would most definitely still need to run during that phase.

--
Michael A. Grady
IAM Architect, Unicon, Inc.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250219/5f158633/attachment.htm>