Skip to main content link. Accesskey S
  • HCL Logo
  • HCL Connections On-Premise Wiki
  • THIS WIKI IS READ-ONLY.
  • HCL Forums and Blogs
  • Home
  • API Documentation
Search
Community Articles > Deployment Scenarios > IBM Connections v4.5/5.0/5.5/6.0 and WebSeal integration : alternative approach
  • Share Show Menu▼

Recent articles by this author

IBM Connections v4.5/5.0/5.5/6.0 and WebSeal integration : alternative approach

How to configure Connections v4.5 up to v6.0 in the real world with WebSeal .
Community articleIBM Connections v4.5/5.0/5.5/6.0 and WebSeal integration : alternative approach
Added by ~Emile Xanaoden | Edited by ~Emile Xanaoden on September 4, 2017 | Version 20
  • Actions Show Menu▼
expanded Abstract
collapsed Abstract
How to configure Connections v4.5 up to v6.0 in the real world with WebSeal .
Tags: webseal, tam, isam, integration, Connections 4.5, connections 5.0, connections 5.5, connections 6.0
ShowTable of Contents
HideTable of Contents
  • 1 General
  • 2 Transparent Path Junctions only
    • 2.1 Why is this a problem in the real world ?
    • 2.2 The transparent path junction problem
  • 3 Interservice Configuration through WebSeal
  • 4 Alternative setup
    • 4.1 Change context root
    • 4.2 Update interservice URLs
      • 4.2.1 NEW Force all interservice URL's to the internal load balancer.
    • 4.3 OAuth configuration
    • 4.4 WebServer configuration
    • 4.5 Configure the ACLs
    • 4.6 Mobile
    • 4.7 Optional
      • 4.7.1 The JSESSIONID Cookie

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.
For instance, you may want to provide access to all your applications through a Portal type application (eg. https://portal.company.com) and also access all your applications through that url (eg. https://portal.company.com/mail , https://portal.company.com/intranet ,...).  In this scenario, you'll have single sign on between all these applications without any additional configuration.
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
 
So how do I configure my system, to get Connections available behind the WebSeal url https://portal.company.com
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 :
https://portal.company.com/connections/homepage
- 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

Change context root

 
The updateContextRoot.py script (http://www.gwbasics.be/blog.nsf/dx/updateContextRoots.py/$file/updateContextRoots.py) updates all applications in WebSphere Application server, and updates the context roots in the Connections configuration.
 
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".
 

Update interservice URLs

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 :


<sloc:href>


             <sloc:hrefPathPrefix>/wikis</sloc:hrefPathPrefix>

             <sloc:static href="https://webseal.company.com" ssl_href="https://webseal.company.com"/>

             <sloc:interService href="https://ihs.internal.com"/>

     </sloc:href> 

 

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

OAuth configuration

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.
 

WebServer configuration

 
Check this link  Link to IBM_Connections_V4.5col_How_to_configure_IBM_Tivoli_Access_Manager_lprTAMrpr_V6.1.1. 
 
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
Redirect 303 /index.html http://portal.company.com/connections/homepage
Redirect 303 /index.htm http://portal.company.com/connections/homepage
Redirect 303 /connections/index.html http://portal.company.com/connections/homepage
Redirect 303 /connections/index.htm http://portal.company.com/connections/homepage
 
Listen 443
ServerName connections.company.com
Redirect 303 /connections/index.html https://portal.company.com/connections/homepage
Redirect 303 /connections/index.htm https://portal.company.com/connections/homepage
Redirect 303 /index.html https://portal.company.com/connections/homepage
Redirect 303 /index.htm https://portal.company.com/connections/homepage
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
 

Configure the ACLs

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.
 

Mobile

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)

 

 

Optional

 

The JSESSIONID Cookie

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.
 


  • Actions Show Menu▼


expanded Attachments (0)
collapsed Attachments (0)
Edit the article to add or modify attachments.
expanded Versions (1)
collapsed Versions (1)
Version Comparison     
VersionDateChanged by              Summary of changes
This version (20)Sep 4, 2017, 2:17:03 PM~Emile Xanaoden  
expanded Comments (0)
collapsed Comments (0)
Copy and paste this wiki markup to link to this article from another article in this wiki.
Go ElsewhereStay ConnectedAbout
  • HCL Software
  • HCL Digital Solutions community
  • HCL Software support
  • BlogsDigital Solutions blog
  • Community LinkHCL Software forums and blogs
  • About HCL Software
  • Privacy
  • Accessibility