By: Daniel Weinand user 18 Nov 2020 at 10:24 a.m. CST

3 Responses
Daniel Weinand gravatar
Currently not using gluu, but interested in changing this. Given the following scenario * Web app (SPA) uses OIDC for authentication * Access token passed to downstream APIs What we need now is an impersonation functionality whereas administrative user can impersonate as a regular user to see the app as the regular user would see it. Currently we are using IdentityServer4 as and OIDC IdP and I have implemented a POC based on the "act" (Actor) Claim for this purpose. https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14#section-4.1 Not to mention that this feature needs close monitoring, visibility of currently impersonated sessions and the possibility to end impersonated session immediately. For the latter, the POC is build to use reference tokens for the impersonated sessions. By this the impersonated session can be immediately revoked. So, basically I'm not sure about these things in gluu, related to IdentityServer4 * Is it possible to extend gluu with custom implementations like this impersonation? * Is "Reference Tokens" something available in gluu? Not sure if this part of the protocol or an IdSrv thing https://identityserver4.readthedocs.io/en/latest/topics/reference_tokens.html * Is this maybe something already supported by gluu? Did not find anythign related

By Michael Schwartz staff 18 Nov 2020 at 11:01 a.m. CST

Michael Schwartz gravatar
You could implement impersonation in Gluu. Personally, I would implement it as a multi-step authentication that requires a FIDO security key. In step one, I'd ask for the admin username / password. In step 2, I'd check to make sure that user is an admin, and then I'd ask for the FIDO key. In step 3, I'd enable the admin to select the user to be impersonated. In step 3 of the Gluu Server person authentication interception script, you would then load the user profile for the target person instead of the person authenticated. If you wanted to use the `act` claim you could add this to the OAuth access_token in the token introspection interception script. We don't support it out-of-the-box, but if you need it, you can add it as a custom claim at runtime based on the context. Net-net, you can accomplish all this, but it will require some decent knowledge of the custom interception script programming works in the Gluu Server. If you might be interested to procure a VIP support contract, you can [schedule a call to discuss](https://gluu.org/booking).

By Daniel Weinand user 18 Nov 2020 at 11:32 a.m. CST

Daniel Weinand gravatar
Thanks for your quick reply. Currently the POC is implemented as a multi-step authentication already. But without FIDO. But thanks for that hint. Surely something to consider. > Net-net, you can accomplish all this, but it will require some decent knowledge of the custom interception script programming works in the Gluu Server. Great to know its possible in general. Will check that topic out. >If you might be interested to procure a VIP support contract, you can schedule a call to discuss. If we will go the Gluu route for sure. Currently gathering information, as internal developments might require us to move away from the current solution. And no, it's not because of IdentityServer going commercial, just in case you know about it and follow it's developments. Just let me come back to the "Reference Token" question. Is this something supported by Gluu? So instead of issuing a JWT token (the default), these impersonated sessions will rely on a reference token, for immediate revocation if needed.

By Michael Schwartz staff 18 Nov 2020 at 12:25 p.m. CST

Michael Schwartz gravatar
Gluu uses reference tokens by default.