Impersonation details - New feature request

[Cantor, Scott]

On 10/9/17, 12:03 PM, "dev on behalf of O'Dowd, Josh" <dev-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:

> I wish I had thought of your solution, using an intercept to simply change the assertion, but I couldn't get my head around how to
> do the request-at-a time where an SSO session already exists.

You're mentally focusing on authentication but all the content of the assertion really comes from attributes, so this is really a "resolve different attributes" problem.

There are exceptional cases where people resolve attributes based on internal details of the authentication result, but those are not common, and can be worked around. Most resolvers just base their work on a principal name that's provided in the AttributeResolutionContext, and all I did is flush the existing AttributeContext and re-run the ResolveAttributes/FilterAttributes steps with the principal name set manually to something other than the normal value.

In most real world cases I would imagine people will use directories or Grouper or something like that to drive the set of names somebody is allowed to impersonate. So in effect you resolve as foo to get the list of authorized names for foo and then re-resolve as one of those names.

Manipulating attribute state is very easy and much more transitory and safe than messing around with authentication state.

-- Scott