Configure single sign-on with Tivoli Access Manager

Configure single sign-on with Tivoli Access Manager

Configure IBM Connections portlets to use single sign-on with IBM Tivoli Access Manager.

Single sign-on (SSO) enables users to log in to a Connections application, and switch to other applications within the product without having to authenticate again.
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 Connections dmgr, verify the realms match between Connections dmgr and Portal.
If change the realm names so they match, follow the steps in Change the realm name.

To collect files from the primary node and copy them to the dmgr:

From the primary node
cd wp_profile_root>/ConfigEngine
ConfigEngine.bat collect-files-for-dmgr -DWasPassword=foo

This creates a compressed file containing all the files which must be copied to the dmgr. The compressed file, named filesForDmgr.zip, are placed in...
<wp_profile_root>/filesForDmgr

Stop the dmgr.

Expand each of the files in the filesForDmgr.zip file into the proper location on the dmgr 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...
AppServer/profiles/Dmgr01
...is used to identify the dmgr profile root, and the AppServer directory is used to identify the dmgr installation root directory. If the dmgr 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 dmgr.

To augment a dmgr profile,
cd AppServer_root/bin
manageprofiles.bat -augment -templatePath c:/IBM/WebSphere/AppServer/profileTemplates/management.portal.augment -profileName Dmgr01

Restart the dmgr.

Add the same Portal administration group as an administrators group on the Connections dmgr.
Federate the primary node:
cd wp_profile_root
addNode.bat dmgr_hostname dmgr_port 
            -includeapps 
            -includebuses
            -username was_admin_user 
            -password was_admin_password
For example:
addNode.bat DMhost.cn.ibm.com 8879 \
            -includeapps \
            -includebuses \
            -username adminuser \
            -password adminpwd
On the Portal server, run syncNode.bat and then restart the dmgr and all node agents.

To configure the IBM HTTP Server with Single Sign-On, delete and re-add the webserver on the WAS 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 Configure Tivoli Access Manager article that corresponds to the Portal server: in the WebSphere Portal Knowledge Center.
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=foo 
ConfigEngine.bat validate-pdadmin-connection 
                 -DWasPassword=foo 
                 -Dwp.ac.impl.PDAdminPwd=foo 
ConfigEngine.bat enable-tam-all 
                 -DWasPassword=foo
Configure the ACL for WebSEAL to allow HTTP PUT requests, add an ACL to the Portal Junction.
Create a default IBM Connections ACL to override the default WebSEAL ACL by ...
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

where:

tam_server is the host name of the Tivoli Access Manager server

WebSEAL_instance is the name of the instance of the WebSEAL server configured to manage IBM Connections. For example: default

app_root is the root path to the 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) definedd. For example: acl attach /WebSEAL/tam.myco.com-default/activities example-default-acl. In this case, the command is: acl attach /WebSEAL/tam.myco.com-default/PORTAL_VHOST_JCT example-default-acl.
Parent topic:
Configure authentication for the portlets