How to maintain multiple authenticated sessions in the same browser — WSO2 Identity Server
It is a known fact that it is impossible to maintain two authenticated sessions in the same browser for a single DNS. Also it is not possible to generate separate identity/cookies for the same browser session.
However their can be requirements where the same user needs to log into the server using two different identities in the same browser to perform his tasks. For example assume their is a user who is logged into IS as an employee to view stats and at the same time he needs to maintain another session as a customer to handle e-commerce work. In this scenario, in order to achieve this usecase we need to generate two commonauthId cookies for the same browser to maintain two authenticated sessions for the WSO2 IS.
In this post I’m going to share a workaround to maintain two authenticated sessions in the same browser for WSO2 Identity Server using proxy servers.
If we go into the depth of session management in WSO2 IS, the commonauthId cookie which is used to maintain the session is set for the hostname of the WSO2 IS. If we can expose WSO2IS as two hostnames, then two commonauthid cookies can be set for end user’s browser.
This implies that we can maintain two sessions in WSO2 IS for the same end user. Therefore we can keep single IS node and expose it as different hostnames using another proxy server. Here we are maintaing two seperate virtual hosts for the same backend server. You can use any proxy server to configure the virtual host configuration.
For example you can configure a proxy server such as Apache HTTP server with virtual host configuration to expose WSO2 IS instance as two different hostnames that is is1.com and is2.com.
With this approach one identity(customer) can access the Identity Server via is1.com and at the same time maintain another session over is2.com by logging in as the other identity(employee).
If we go into the details of proxies they can be mainly categorized into two types. Forward proxies and reverse proxies.
A forward proxy is a proxy configured to handle requests for a group of clients under the local Administrators control to an unknown or arbitrary group of resources that are outside of their control. Usually the word “forward” is dropped and it is referred to simply as a proxy, this is the case in Microsoft’s topology. A good example is a web proxy appliance which accepts web traffic requests from client machines in the local network and proxies them to servers on the internet. The purpose of a forward proxy is to manage traffic to the client systems
A reverse proxy is a proxy configured to handle requests from a group of remote or arbitrary clients to a group of known resources under the control of the local Administrator. An example of this is a load balancer (a.k.a. application delivery controller) that provides application high availability and optimization to workloads like as Microsoft Skype, Exchange and SharePoint. The purpose of a reverse proxy is to manage the server systems.
Whats important for us in this scenario would be a reverse proxy.
How can a Reverse Proxy facilitate our requirement?
A reverse proxy would make sure that the request initiators would see the responses as if they originated from the backend server. This includes re-directions as well.
The flow would be as follows.
- The reverse proxy is configured to have two virtual hosts which will route the traffic to the same backend server (WSO2 IS) which resides behind the proxy.
- All the requests to the identity server (via either of the host names is1.com or is2.com) will be received by the proxy server on behalf of WSO2 IS.
- It will then forward the request to the back-end server (is.server.com)
- IS server will send the response back to the proxy server and proxy server will re-write the corresponding virtual host names in the response and send the response back to the client who initiated the request.
- Since the cookies sent in the response will contain two different domain names, the client (browser) can maintain separate sessions.
Here the client (browser) will never identify who was the actual server (actual server’s host), it will only know the virtual proxy addresses.
Following diagram demonstrates how this is done using a reverse proxy.
The following sequence diagram demonstrates how the proxy handles browser redirects.
Following would be the proxy with virtual host configuration in apache http server.
<IfModule mod_proxy.c>
<VirtualHost *:443>
ServerAdmin techops@wso2.com
ServerName is1.com
ServerAlias is1.com
ProxyRequests Off
SSLEngine On
SSLProxyEngine On
SSLCertificateFile /etc/apache2/credential/server.crt
SSLCertificateKeyFile /etc/apache2/credential/server.key
SSLCACertificateFile /etc/apache2/credential/ca.crt
ProxyPass / https://{IS_Server_Host_Name}:{IS_Server_Port}/
ProxyPassReverse / https://{IS_Server_Host_Name}:{IS_Server_Port}/
</VirtualHost>
<VirtualHost *:443>
ServerAdmin techops@wso2.com
ServerName is2.com
ServerAlias is2.com
ProxyRequests Off
SSLEngine On
SSLProxyEngine On
SSLCertificateFile /etc/apache2/credential/server.crt
SSLCertificateKeyFile /etc/apache2/credential/server.key
SSLCACertificateFile /etc/apache2/credential/ca.crt
ProxyPass / https://{IS_Server_Host_Name}:{IS_Server_Port}/
ProxyPassReverse / https://{IS_Server_Host_Name}:{IS_Server_Port}/
</VirtualHost>
</ifModule>Here, the ProxyPassReverse configuration will ensure that redirects sent from the backend server are re-written to contain the virtual host configured in the proxy to be set as the location header in the response.
