How To Impersonate Someone Else Using WSO2 Identity Server — Part 1

Well..This is kind of an interesting topic that I could work on. Topic itself gives an idea which is allowing someone to pretend as someone else.

To avoid this article being lengthy, I am discussing the logic/implementation behind this authenticatior. How it can be used has been discussed in part-2.

First let me explain the use case of the impersonation. Suppose you are in the customer support team. You are being complained regarding a certain end user’s web application. Then what you would do is, you try to login to his system. But you would not be able to see what the end user is experiencing. Hence, you would wonder if there is a way that you can impersonate as the end user and log in to the system and actually explore what the end user is experiencing. What are the possible ways.. ?

On top of the head and the most obvious way is the ability to obtain end user’s user name and password. Well.. I don’t want someone to possess my username and password. So to mitigate this problem, the impersonation authenticator comes into play.

Bottom-line…what happens here is.. person A is allowed to impersonate B, if person A has a special role to impersonate others and if person B let others with the special role to impersonate him.

Implementation

With the WSO2 Identity Server, we can achieve this by writing a custom authenticator. You can implement by coupling to a existing authenticator or as a decoupled authenticator.

However I have implemented this as a coupled authenticator with basic authenticator. Reason behind this was the person I want to impersonate is sent in a query parameter.

With the use case I explained at the beginning, this could be a scenario where impersonator/custom support team member would select the impersonatee and click the impersonate button. Then it will redirect to the end user’s web applications. In this redirect URL, impersonatee can be passed as a query parameter. (eg:impersonatee=foo)

Code for this implementation, including build artifacts can be found in the following GitHub location.

dinusha92/identity-impersonation

Since I am coupling impersonation authentication with basic authenticator, I have extended the custom authenticator class by BasicAuthenticator. For this custom authenticator, I have override only public AuthenticatorFlowStatus process(HttpServletRequest request, HttpServletResponse response, AuthenticationContext context) method.

I will explain what is happening here according to the use case that I have mentioned above.

1. The redirect URL guides to the login page of end user’s/impersonatee’s web application.
2. Within this redirection, the property passing as a query parameter, which is impersonatee, should be persist in the authentication context. If not, after you enter username and password and authenticate the user, the impersonatee in the query parameter would be lost.
3. Then enter the impersonator’s credentials and hit login.
4. Within the aforementioned method, it will first call the process method of super class( which is BasicAuthenticator) and check if this is a valid user.
5. If it is a valid user, then it will extract its roles and check if it matched with the impersonator role. (By default impersonator has Internal/impadmin role)
6. If it is there, the it will check if impersonatee has the necessary role which allows others with Internal/impadmin role to impersonate him. (By default impersonatee has Internal/impuser)
7. If these are satisfied, authenticator user is created and set as the subject of this authentication step.
8. Now the logged in user will be shown as the impersonatee.

That is the simple logic behind the aforementioned custom authenticator.

How this can be used is described in part-2. Please refer it, then you will get a clearer idea on how to use it.

Hope you enjoyed..! Cheers.