Impersonation AccessControlPolicy question

[Cantor, Scott]

On 3/4/21, 9:47 AM, "users on behalf of Robert Führicht" <users-bounces at shibboleth.net on behalf of robert.fuehricht at jku.at> wrote:

>    It just extracts the target username to impersonate against from the
>    ProfileRequestContext - a value the intercept form submits and that is
>    extracted the same way all the time.

That's all it needs to be, the point is just to expose the input to the AccessControl interface to the relevant code, and the "resource" in this case is the impersonated ID, the "thing" you want to apply access control rules to. It's the target of the operation, which is the "resource" in authz "parlance".

>    I'd rather have the actual matching against allowed values be delegated
>    to a function being supplied by whoever manages the access control policy.

A version of DynamicAttributePredicate that delegates the matching rule instead of using "equality" is not an unreasonable thing, it just isn't what the code does now.

>    That example is ill fitted to explain the reasoning behind the
>    DynamicAttributePredicate class in my opinion.

The Dynamic predicate is simply a way to indirect the "allowed" values instead of using a static list, which fits a directory-driven model where the set of values to allow is table-driven. It changes one operand of the SimpleAttributePredicate (the "values" to compare against an input value) from static to dynamic, that's all it does.

A regex-based approach is a different sort of solution to the problem and I would not expect that such a solution would bear any resemblance to that class necessarily, unless you have to get the regexes to match against to come from the resolver I guess. That's a somewhat analagous case and that's just plugging in a different comparison other than equality to the current code. That's probably a subclass we could add.

But this isn't a use case that seems to naturally fit any sort of regex unless the impersonated accounts are artificial.

-- Scott