ShowTable of Contents
General
The official documentation on integrating Connections with WebSeal has 2 issues in the real world :
- only Transparent Path junctions or Virtual host junctions are supported. This may or may not be an issue in your case. See below.
- The interService URL configuration points from the backend WAS servers to WebSeal instead of connecting directly
Caution! This is not updated with the newest addition to Connections 6.0 on-premise (OrientMe), although the approach should be similar.
Update: this technique is valid for Connections 5.0, 5.5 and 6.0 with CCM as well.
Transparent Path Junctions only
Why is this a problem in the real world ?
You want to provide access to all your applications through a single hostname on the WebSeal reverse proxy. The reason for this is to make Single Sign on easier and to make SSL certificate easier/cheaper.
You also only need a single ssl certificate (portal.company.com).
The transparent path junction problem
Now in general, this is not a problem, as long as the transparent path junctions you need to create are guaranteed to be unique. Here is where it becomes tricky ! Because you don't want to have to map /static or /css or (specifically for connections) /mobile or /homepage to a specific backend application. It's likely another application will also require the same path.
When using standard junctions, this is not a problem, because all applications have their own unique URI context root (eg. /JUNCTION1/mobile or /JUNCTION2/mobile) - WebSeal handles directing the requests to the correct backend.
So if you want to use a single hostname as access point, you'd probably want to avoid Transparent Path junctions generally, but some products only support TP junctions (like Connections)...
Interservice Configuration through WebSeal
The documentation assumes you'd want to direct all requests (also the requests for the calls between the different Connections services) to go through WebSeal.
In my opinion, the interservice calls should not go through WebSeal because :
- it's a performance hit (it's slower, because all requests needlessly go through webseal)
- can I even reach WebSeal from my internal server ? WebSeal can reach my servers obviously , but the other way around is not certain.
- the configuration is clunky and requires creating a specific user on WebSeal
So I'm not a fan of this approach.
The only advantage of the approach is that you do not require an internal loadbalancer in front of your IHS webservers (if you use WebSeal for the load balancing).
Alternative setup
So what do we want to do with the Connections setup ?
- make sure we can create a transparent path junction that is guaranteed to be unique
- make all interservice requests go to the WebServer directly
These are the steps to follow :
- decide on a transparent path junction name. In this example, we choose "CONNECTIONS". So for end users, the homepage will be available on this url :
- configure the transparent path junction on webseal (ssl, with LTPA key). Check the documentation for the specific junction options (-b ignore needs to be there, for instance). You need to have exported the LTPA key from your Connections environment and imported that into WebSeal to do this.
This is an example :
server task WebSEAL-instance-name create -t ssl -h backend-server-name -x -p backend-server-port -i -b ignore -f -A -2 -F ltpa-token -Z ltpa-password -k transparent-path-jct
- change the context root of all applications in WAS/Connections
- update the (inter)serviceURL configuration
- update the oauth configuration
- configure http server
- configure the ACL's on WebSeal (see the documentation)
- want to use Mobile ?
- optional steps :
- set session timeout to match WebSeal
- change name of the JSESSIONID cookie
The exact steps to perform on WebSeal are not the scope of this document. Check with your WebSeal administrator.
Note that this setup uses http to connect from WebSeal to the IHS webservers - how to setup ssl between WebSeal and the IHS servers is outside of the scope of this document.
You do not need to create a separate user on WebSeal
You do not need to change the Default Authenticator in LotusConnections-config.xml
Edit the file to match your prefered context root (here , it's connections)
Copy the file to the system you wnat to run it on :
On the deployment manager, go to the bin directory of the Dmgr profile :
Linux/AIX: example :
cd /opt/WebSphere/profiles/Dmgr01/bin/
./wsadmin.sh -lang jython -username -password -f /path/updateContextRoot.py
Windows: example :
cd C:\IBM\WebSphere\profiles\Dmgr01
wsadmin.bat -lang jython -username -password -f C:\path\updateContextRoot.py
After running the scripts, sync the nodes and restart everything.
Note that you may need to change the "checkout" directory in the script, based on your environment and OS (here it's "D:\Temp", which won't work on Linux)
Note that the context root "connections" is used in standard Connections for some Common applications. This script changes that to "common".
This script (http://www.gwbasics.be/blog.nsf/dx/setInterServiceURL-webseal.py/$file/setInterServiceURL-webseal.py) also changes the name of the JSESSIONID cookie in one go - if you don't want to change the name, just leave it to be JSESSIONID.
The interservice URL should be :
- the hostname of your IHS server (if you have only a single server environment)
- the load balancer's hostname (the load balancer that sits between WebSeal and your IHS servers) in a multi-server environment
For instance, for wikis :
Edit the file to your needs and copy to your Dmgr.
On the deployment manager, go to the bin directory of the Dmgr profile :
Linux/AIX: example :
cd /opt/WebSphere/profiles/Dmgr01/bin/
./wsadmin.sh -lang jython -username -password -f /path/setInterServiceURL-webseal.py
Windows: example :
cd C:\IBM\WebSphere\profiles\Dmgr01
wsadmin.bat -lang jython -username -password -f C:\path\setInterServiceURL-webseal.py
After running the scripts, sync the nodes and restart everything. Also regenerate the WebSphere Plugin and propagate to your webserver(s).
There is an additional manual step required if you choose to change the JSESSIONID cookie name. The administration api is missing something apparently ...
In the LotusConnections_config.xml, change this section ( check how to change general configuration settings in the LCwiki if you're unsure how to do this).
NEW Force all interservice URL's to the internal load balancer.
You'll notice that even after modifying all interservice url configuration, there's still requests from your backend going through webseal.
There is a simple solution for this - use the host file on the Connections servers , to direct trafic aimed at your WebSeal's hostname, to the local ip address :
So if webseal.company.com is the hostname for your WebSeal, and your IHS servers are collocated on the Connections server, you can add this in your /etc/hosts file (or equivalent on Windows).
127.0.0.1 webseal.company.com
But that's a clunky solution.
The alternative solution involves using this configuration.
You need to edit opensocial-config.xml , in your Deployment Manager's LotusConnections-config directory.
After this line :
<external-only-access-exceptions>none</external-only-access-exceptions>
Add these lines :
<proxyInterServiceRewrite name="opensocial" />
<proxyInterServiceRewrite name="webresources" />
<proxyInterServiceRewrite name="activities" />
<proxyInterServiceRewrite name="bookmarklet" />
` <proxyInterServiceRewrite name="blogs" />
<proxyInterServiceRewrite name="communities" />
<proxyInterServiceRewrite name="dogear" />
<proxyInterServiceRewrite name="files" />
<proxyInterServiceRewrite name="forums" />
<proxyInterServiceRewrite name="homepage" />
<proxyInterServiceRewrite name="mediaGallery" />
<proxyInterServiceRewrite name="microblogging" />
<proxyInterServiceRewrite name="search" />
<proxyInterServiceRewrite name="mobile" />
<proxyInterServiceRewrite name="moderation" />
<proxyInterServiceRewrite name="news" />
<proxyInterServiceRewrite name="profiles" />
<proxyInterServiceRewrite name="sand" />
<proxyInterServiceRewrite name="search" />
<proxyInterServiceRewrite name="thumbnail" />
<proxyInterServiceRewrite name="wikis" />
Sync your nodes, and restart everything. All trafic for the standard widgets (eg. on Homepage or in Communities) will now render correctly.
Note that this is not valid for CCM nor for Mobile, these have separate settings in library-config.xml and mobile-config.xml respectively where you can select to "use interservice url" .
For Docs, the configuration is done in the json configuration files . I'm not going into these details here.
More information can be found here (for instance, how to use the same approach for your custom and third party widgets) : https://blogs.gwbasics.be/blog.nsf/dx/security-reverse-proxy-and-connections.htm
In the ISC (WebSphere Administration Console), go to
Global security > Trust association > Interceptors > com.ibm.ws.security.oauth20.tai.OAuthTAI
Update all context roots here .
This is what provider_1.filter originally says :
request-url^=/activities/oauth|/blogs/oauth|/dogear/oauth|/communities/calendar/oauth|/communities/service/atom/oauth|/communities/service/opensocial/oauth/|/communities/recomm/oauth|/connections/opensocial/oauth|/files/oauth|/forums/oauth|/homepage/oauth|/metrics/service/oauth|/moderation/oauth|/news/oauth|/news/follow/oauth|/profiles/oauth|/wikis/oauth|/search/oauth|/connections/core/oauth/|dm/atom/oauth
Change to (for our example) :
request-url^=/connections/activities/oauth|/connections/blogs/oauth|/connections/dogear/oauth|/connections/communities/calendar/oauth|/connections/communities/service/atom/oauth|/connections/communities/service/opensocial/oauth/|/connections/communities/recomm/oauth|/connections/common/opensocial/oauth|/connections/files/oauth|/connections/forums/oauth|/connections/homepage/oauth|/connections/metrics/service/oauth|/connections/moderation/oauth|/connections/news/oauth|/connections/news/follow/oauth|/connections/profiles/oauth|/wikis/oauth|/connections/search/oauth|/connections/common/core/oauth/|/connections/dm/atom/oauth
Regenerate the WebServer plugin, and restart the servers.
This is a sample Virtual host configuration you could use and adapt:
(you need to create a directory "connections" in the htdocs directory (in the IHS directory), and put a file there named index.html. This file can be empty.
RewriteEngine On
RewriteCond %{REQUEST_URI} /(.*)/ibm_security_logout(.*)
RewriteRule ^/(.*) /pkmslogout [noescape,L,R]
ServerName connections.company.com
Listen 443
ServerName connections.company.com
SSLEnable
SSLProtocolDisable SSLv2
RewriteEngine On
RewriteCond %{REQUEST_URI} /(.*)/ibm_security_logout(.*)
RewriteRule ^/(.*) /pkmslogout [noescape,L,R]
KeyFile D:/IBM/WebSphere/HTTPServer/ssl/yourkeyfile.kdb
SSLDisable
The wiki contains an overview of the URI's to protect or to allow unauthentication
Depending on your webseal configuration, you'd need to tweak this. For instance, depending on your configuration, basic authentication may be configured but never actually triggered. So the URI's requiring Basic Authentication need to be configured as unauthenticated, so the WAS server handles the authentication (what the -b ignore option is for in the junction configuration).
Anyway, verify this with your WebSeal administrator (which I am not).
Also configure the dynurls as explained in the wiki, and verify the WebSeal instance configuration.
The mobile application works a bit different than the other applications : it also generates url's that are not based on the (inter)service url configuration. This is very annoying.
Additionally, if you want to use the Mobile Application (Android / Apple) through WebSeal there's some restrictions : you can't enforce strong authentication options like tokens, or eid if they require additional data entry fields (for instance, in addtion to username and password, a field to enter the token generated by your key chain device).
If you want to use Mobile , there's additional configuration steps :
- edit mobile-config.xml, to enable TAM url's for authentication (details to follow)
Renaming the JSESSIONID cookie can avoid potential conflicts . Because all (J2EE) application servers are accessible behind the same hostname, they potentially overwrite each other's JSESSIONID cookie . This may cause strange problems - renaming the cookie avoids this.