Question & Answer
Question
InfoSphere® MDM Collaboration Server is installed on a different server which belongs to a different domain then the HTTP server. This means that the InfoSphere® MDM Collaboration Server user enters a different URL in the browser which points to a different domain then the domain where the InfoSphere® MDM Collaboration Server resides. For example a horizontal (physical) cluster which is even based on multiple domains on it's own. What do I need to consider to get all requests and responses working transparently between the browser and the InfoSphere® MDM Collaboration Server
Cause
In a "Multi-domain" environment the InfoSphere® MDM Collaboration Server user enters a different URL into the browser that refers to a different domain then the domain where the InfoSphere® MDM Collaboration Server server has been deployed. This requires a HTTP- Server with a dedicated configuration and adjustments to the configuration on InfoSphere® MDM Collaboration Server side.
Answer
For the implementation of a multi-domain environment a HTTP server like IBM HTTP Server or Apache HTTP server can be used.
The HTTP server has to be configured as a reverse proxy to allow incoming client connections and redirect them to application server(s) that reside on the same internal network. The internal network is totally transparent to the client user.
To focus on the sole configuration of the needed HTTP server to set up InfoSphere® MDM Collaboration Server with enabled referrer validation and Cross-Site-Request-Forgery (CSRF) guard, this Technote describes only one InfoSphere® MDM Collaboration Server definition in the HTTP server.
HTTP referer check in InfoSphere® MDM Collaboration Server
to enable the referer check, which is a validation of the referer field in the HTTP header, the common.properties parameter "enable_referer_check" has to be set to the value "true".
However, without further configuration in the HTTP server, the referer validation fails in the InfoSphere® MDM Collaboration Server and a HTTP 203 "Non-Authorative Information" error will be shown, which means that the request is blocked.
To avoid this problem the referer in the HTTP header has to be set to the domain name of the HTTP server in the HTTP server configuration. This means in consequence that the referer check for messages from user clients i.e. Web-Browsers has to be done in the HTTP server instead of the Browser itself. The requests which go directly to the InfoSphere® MDM Collaboration Server will verified in the MDM server when "enable_referer_check" is set to "true".
CSRF guard feature of the InfoSphere® MDM Collaboration Server
The CSRF guard feature is turned on when the common.properties parameter "enable_csrf_guard" is set to the value "true".
For the CSRF guard feature a java script is executed on the browser which compares the domain of the browser document with the domain where the InfoSphere® MDM Collaboration Server resides.
If you don't apply any configuration to the HTTP server, you can log in to the InfoSphere® MDM Collaboration Server application but will receive the following error message "OWASP CSRF Guard JavaScript was included from within an unauthorized domain" intermittently and the application functionality is not performed in that case.
Configuration of the HTTP server using Apache HTTP server
pre-requisites:
- the Apache HTTP server is installed on the server URL_HOST_2
- the InfoSphere® MDM Collaboration Server user enters the following URL: ollie.munich.de.ibm.com with port 7170
In the Apache HTTP server configuration file httpd.conf the following lines have to be added:
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule substitute_module modules/mod_substitute.so
<VirtualHost *>
RewriteEngine on
RewriteCond %{HTTP_REFERER} ^$ [OR]
RewriteCond %{HTTP_REFERER} ^http://loriot\.munich\.de\.ibm\.com:80(/.*)*$ [NC]
RewriteRule ^(.*)$ URL_HOST_1$1 [P,NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://loriot\.munich\.de\.ibm\.com:80(/.*)*$ [NC]
RewriteRule / - [F]
RequestHeader set Referer "URL_HOST_1"
AddOutputFilterByType SUBSTITUTE text/javascript
Substitute s/ollie.munich.de.ibm.com/loriot.munich.de.ibm.com/ni
</VirtualHost>
Explanation of above configuration
URL change and HTTP request header referrer check
RewriteEngine on
RewriteCond %{HTTP_REFERER} ^$ [OR]
RewriteCond %{HTTP_REFERER} ^http://loriot\.munich\.de\.ibm\.com:80(/.*)*$ [NC]
RewriteRule ^(.*)$ URL_HOST_1$1[P,NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://loriot\.munich\.de\.ibm\.com:80(/.*)*$ [NC]
RewriteRule / - [F]
The URL is changed from loriot.munich.de.ibm.com:80 to ollie.munich.de.ibm.com:7170
The referer in the HTTP header is validated:
- it can be empty or
- the referer must be "URL_HOST_2"
Set Referer in Request Header
RequestHeader set Referer "URL_HOST_1"
The referer in the HTTP request header is set to "URL_HOST_1", which is the URL of the InfoSphere® MDM Collaboration Server application.
Domain name change for the CSRF guard feature
AddOutputFilterByType SUBSTITUTE text/javascript
Substitute s/ollie.munich.de.ibm.com/loriot.munich.de.ibm.com/ni
The Java script servlet „/org.owasp.csrfguard.servlet/JavaScriptServlet" sets in the java script „Owasp.CsrfGuard.js" the domain name to „ollie.munich.de.ibm.com" and returns the changed java script.
The domain name "ollie.munich.de.ibm.com" is changed to "loriot.munich.de.ibm.com" for any responses of type "text/javascript" arriving at the Apache HTTP server.
Because the browser application runs also in the domain „loriot.munich.de.ibm.com" the check for the domain name in the java script is successful and the CSRF guard feature works correctly.
Using the Apache HTTP server module „mod_substitute“ the domain main in the java script from the InfoSphere® MDM Collaboration Server can be modified.
Please be informed, that this is not possible with the standard IBM IHS.
Using IBM IHS you have to compile the module „mod_substitute“ from the Apache HTTP server package and integrate it in the IBM IHS product.
Workaround for the domain validation with the CSRF guard feature
the Java script "Owasp.CsrfGuard.js" has a method "isValidDomain" which checks if the document domain is valid.
This script can be found at:
<WAS home>/profiles/<application profile>/installedApps/<cell name>/
ccd_<application server name>.ear/ccd.war/js
Example:
/opt/WebSphere/85/AppServer/profiles/AppSrv85/installedApps/ollieNodeWAS85Cell/ccd_ollie17_7170.ear/ccd.war/js
The workaround is applied by adding an if statement to the method "isValidDomain" where the document domain is compared with the domain of the HTTP server. If the comparison result is true the return value "true" has to be returned.
Example:
/** check if valid domain based on domainStrict **/
function isValidDomain(current, target) {
if (current = "loriot-mdm.munich.de.ibm.com) {return true;}
The parameters of this method are:
current: HTTP server domain, which is the domain of the URL the user enters in the client browser.
target: InfoSphere® MDM Collaboration Server domain.
If there are multiple InfoSphere® MDM Collaboration Server(s) installed, all instances of the Java script "Owasp.CsrfGuard.js" have to be updated accordingly.
References:
https://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
https://tomcat.apache.org/tomcat-8.0-doc/proxy-howto.html
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21699557