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.
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).