Remote_user variable on backend server

Document ID : KB000051802
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

Applications require the "uid" from the user to operate, and this variable along to the applications by using Remote_user.

As this is used by all applications, a Global Response was created:

  WebAgent-HTTP-Header-Variable REMOTE_UID=<%userattr="uid"%>   

In the ACO, it is defined as follow:

   RemoteUserVar = REMOTE_UID          
  SetRemoteUser = yes

The web agent is on Apache Reverse Proxy.

Issue: It is not possible to retrieve this value when using a global response (with a global policy).

When using a local response into a local policy, then it is possible to retrieve the header's value.

Architecture:

Backend servers are located in a DMZ that will only be accessible by the RP (no SiteMinder protection, which should make easier to change/upgrade WA). This is the reason why there only is a frontend RP.

Therefore even if the solution is to place a WA on the backend server, this is not a good solution as it is not applicable to this environment.

Solution:

No agent on the backend needs to be present.

Suggested path to troubleshoot this issue would be to validate the agent by setting the private header (Not a SiteMinder header by the way). It may be required to turn debugging levels on at the proxy level to see why the plug-in is not setting/sending header to backend.

SiteMinder as the authentication module can be configured to set the private HTTP header that contains the remote user. The Proxy plug-in sets the private HTTP header value whenever a Web server authentication module populates the remote user in the Web server data structure. If the private HTTP header value is not set, the application's call to getRemoteUser() returns a null value.

  • In the case of an Apache Web server or the IBM HTTP Server, the plug-in builds the private header from the information contained in the associated request record.

  • In the case of a Sun One Web server, the plug-in builds the private header from the information contained in the auth_user property associated with the request. The private header is usually set to the name of the local HTTP user of the Web browser, if HTTP access authorization is activated for the URL.

  • In the case of a Domino Web server, the plug-in builds the private header from the information contained in the REMOTE_USER environment variable. The plug-in sets this variable to anonymous for users who have not logged in and to the username for users who are logged into the application.

  • In the case of an Internet Information Services (IIS) Web server, the plug-in builds the private header from the information contained in the REMOTE_USER environment variable. The plug-in sets this variable to the name of the user as it is derived from the authorization header sent by the client.

From all the tests performed, we can see that the Web Agent does set the remote_user on the RP. But unfortunately Apache will not propagate it to the backend webserver. This is due to an Apache limitation.

A few solutions to bypass this apache limitation:
* Install a Web Agent on the backend which will enforce adding remote_user on the backend
* Use proxy rewrite module to add the user to the URL when sending the request to the backend

You can send the value of REMOTE_USER on the query string sent to the backend servers:

     RewriteCond %{LA-U:REMOTE_USER} (.*)          
    RewriteRule /test.asp(.*) test.asp?userid=%{LA-U:REMOTE_USER} [QSA,P,L]

The LA-U means lookahead. From the mod_rewrite manual:
%{LA-U:variable} can be used for look-aheads which perform an internal (URL-based) sub-request to determine the final value of variable. This can be used to access variable for rewriting which is not available at the current stage, but will be set in a later phase.

For instance, to rewrite according to the REMOTE_USER variable from within the per-server context (httpd.conf file) you must use %{LA-U:REMOTE_USER} - this variable is set by the authorization phases, which come after the URL translation phase (during which mod_rewrite operates).