Configuring single sign-on with Tivoli Access ManagerAdded by IBM on May 8, 2014 | Version 1 (Original)
|Configure IBM® Connections portlets to use single sign-on with IBM Tivoli® Access Manager.
Single sign-on (SSO) enables users to log in to an IBM
Connections application and switch to other applications within the product without having to authenticate again.
There are several different ways to configure SSO. This authentication method allows Tivoli
Access Manager and users web browsers to prove their identities to one another in a secure manner.
Configuring IBM Connections and WebSphere Portal to share a single Deployment manager saves on administration time by combining administration tasks for the two applications. Establishing a single-sign on environment benefits the users by creating a more seamless environment between the two applications.
Follow these steps to configure single sign-on.
- Before federating Portal as a managed node of the Deployment manager of IBM Connections, make sure the realms match between Connections Deployment manager and Portal.
If you must change the realm names so they match, follow the steps in Changing the realm name.
- Perform the following steps to collect files from the primary node and copy them to the Deployment manager:
- From the <wp_profile_root>/ConfigEngine directory of the primary node, run this task: ConfigEngine.bat collect-files-for-dmgr -DWasPassword=password .
This creates a compressed file containing all the files which must be copied to the Deployment manager. The compressed file, named filesForDmgr.zip, are placed in the <wp_profile_root>/filesForDmgr directory.
- Stop the Deployment manager.
- Expand each of the files in the filesForDmgr.zip file into the proper location on the Deployment manager based on the directory names within the compressed file. The directory names in the compressed file are based on the typical default directory names. The directory that is called AppServer/profiles/Dmgr01 is used to identify the Deployment manager profile root, and the AppServer directory is used to identify the Deployment manager installation root directory. If the Deployment manager was installed into the default directory (AppServer) and the profile was created in the default directory (AppServer/profiles/Dmgr01), then the compressed file can be expanded directly into the directory above the AppServer directory; for example /IBM/WebSphere.
- Start the Deployment manager.
- To augment a Deployment manager profile, run the following command from the <AppServer_root>/bin directory:
manageprofiles.bat -augment -templatePath c:/IBM/WebSphere/AppServer/profileTemplates/management.portal.augment -profileName Dmgr01
- Restart the Deployment manager.
- Add the same Portal administration group as an administrators group on the IBM Connections Deployment manager.
- Run the following command from the <wp_profile_root>/bin directory to federate the primary node:
addNode.bat dmgr_hostname dmgr_port -includeapps -includebuses
addNode.bat DMhost.cn.ibm.com 8879 -includeapps -includebuses -username adminuser -password adminpwd
- On the Portal server, run syncNode.bat and then restart the Deployment manager and all node agents.
- To configure the IBM HTTP Server with Single Sign-On, delete and re-add the webserver on the WebSphere Application Server Integrated Solutions Console in order to re-map all applications, including Portal, and import the Portal certificate into IBM HTTP Server.
- Configure Tivoli Access Manager on the Portal server, following the directions in the article that corresponds to your Portal server: in the IBM WebSphere® Portal product wiki.
Configure the ACL for WebSEAL to allow HTTP PUT requests by adding an ACL to the Portal Junction.
For the connections integration with the portlets, it is important that WebSEAL session cookies are sent to the junction server. This can be defined by adding the -k
option to the commands that create a junction.
For example, on Portal 7:
server task default-webseald-TAMhost.cn.ibm.com create -t ssl -b filter -A -F C:\WASLTPA.key -Z password
-h DMhost.cn.ibm.com -c all -f -k -j -J trailer /wpsv70
ConfigEngine.bat run-svrssl-config -Dwp.ac.impl.PDAdminPwd=password
ConfigEngine.bat validate-pdadmin-connection -DWasPassword=password -Dwp.ac.impl.PDAdminPwd=password
ConfigEngine.bat enable-tam-all -DWasPassword=password
Parent topic: Configuring authentication for the portlets
- Create a default IBM Connections ACL to override the default WebSEAL ACL by running the following commands:
acl create lc3-default-acl
acl modify lc3-default-acl set user sec_master TcmdbsvaBRlrx
acl modify lc3-default-acl set any-other Tmdrx
acl modify lc3-default-acl set unauthenticated T
acl modify lc3-default-acl set group iv-admin TcmdbsvaBRrxl
acl modify lc3-default-acl set group webseal-servers Tgmdbsrxl
- Attach the default ACL to application root URLs:
acl attach /WebSEAL/tam_server-WebSEAL_instance/app_root lc3-default-acl
tam_server is the host name of the Tivoli Access Manager server
WebSEAL_instance is the name of the instance of the WebSEAL server that is configured to manage IBM Connections. For example: default
app_root is the root path to the IBM Connections applications, including the following: /activities, /blogs, /cognos, /communities, /dogear, /files, /forums, /homepage, /news, /metrics, /mobile, /moderation, /profiles, /search, and /wikis
lc3-default-acl is the access control list (ACL) that you defined. For example: acl attach /WebSEAL/tam.example.com-default/activities example-default-acl. In this case, the command is: acl attach /WebSEAL/tam.example.com-default/PORTAL_VHOST_JCT example-default-acl.