Enabling single sign-on for Tivoli Access Manager
Configure IBM® Connections to use single sign-on with IBM Tivoli® Access Manager.
Before you begin
Install the supported version of IBM Tivoli Access Manager for e-business.
Ensure that you can access the installed IBM Connections applications from a web browser.
Set the IBM WebSphere® Application Server single sign-on domain to the same value as that of the Tivoli Access Manager server.
- If you are enabling SSO between IBM Connections and a product that is deployed with a stand-alone LDAP configuration on WebSphere Application Server, or if the product is using IBM Lotus® Domino®, you must first complete the steps described in the Enabling SSO with stand-alone LDAP topic.
- The connectionsAdmin J2C alias that you specified during installation must correspond to a valid account that can authenticate with Tivoli Access Manager. It may map to a back-end administrative user account but is not intended to be used as a user account for IBM Connections. This account must be capable of authenticating for single sign-on against Tivoli Access Manager. If you need to update the userid or credentials for this alias, see the Changing references to administrative credentials topic
- IBM Connections supports the WebSphere cookie-based lightweight third-party authentication (LTPA) mechanism as an SSO solution for Tivoli Access Manager. IBM Connections does not support other SSO solutions that WebSEAL supports such as WebSphere Trust Association Interceptor (TAI), Forms SSO, Cross-domain SSO, or E-community SSO.
- IBM Connections supports the use of encrypted connection Transparent Path junctions with Tivoli Access Manager. IBM Connections does not support TCP type junctions or Tivoli Access Manager Standard junctions.
- For more information about IBM Tivoli Access Manager, go to the Tivoli Access Manager knowledge center.
About this task
Single sign-on (SSO) enables users to log in to one application of IBM Connections and switch to other applications and resources without having to authenticate again.
There are several different ways to configure SSO. This procedure describes one approach. It uses a WebSphere Application Server LTPA key and WebSEAL Transparent Junctions.
To set up SSO using Tivoli Access Manager, complete the following steps:
Procedure
- To support SSO with
the Lightweight Third-Party Authentication (LTPA) key, the same keys
and passwords must be shared by the Tivoli Access
Manager and WebSphere Application
Server. To export the keys from WebSphere Application
Server, complete the following steps:
- Log into the WebSphere Application Server Integrated Solutions Console as an administrator, expand Security, and then click Global security. In the Authentication mechanisms and expiration area, click LTPA.
- In the Cross-cell single sign-on section, provide values
for the following fields:
- Password Enter a secure password and then confirm the password. You need to provide this password later
- Fully qualified key file name Specify a valid path and a file name for the file that will hold the exported keys
For example:
p*ssw*rd
C:\WAS_ltpa.keys
- Click Export keys.
Note: If you have modified your federated repository properties, such as the realm name of the federated repository, re-export your LTPA keys and copy them to the Tivoli Access Manager server, to the same location that you used to create the Tivoli Access Manager junctions. See Step 4 for more details.Recreating the LTPA token might introduce errors. Refer to Clearing all scheduled tasks if this occurs. - Use available authentication data when an unprotected URI is accessed: On the Global security page, expand Web and SIP security, and then click General settings. Click Authenticate only when the URI is protected and select Use available authentication data when an unprotected URI is accessed, if it is not already selected. Click Apply and then click OK.
- Import your IBM HTTP
Server certificate into the Tivoli Access
Manager keystore. To import the certificate, complete the following
steps:
- Copy the WebSEAL certificate key file to the system
where IBM HTTP Server is installed.
You can discover the location of the WebSEAL certificate key file by examining the WebSEAL configuration file (Tivoli_install_root/PDWeb/etc/webseald-default.conf). To discover the location of the key file, search the file for the webseal-cert-keyfile keyword.
For example:copy "C:\Program Files\Tivoli\PDWeb/www-default\certs\pdsrv.kdb on the Tivoli Access Manager server to C:\pdsrv.kdb on the system where IBM HTTP Server is installed.
- On the system where IBM HTTP
Server is installed, run the following command to start the IBM Key Management utility: ibm_http_server_root/bin/ikeyman.sh|bat
For example: C:\IBM\HTTPServer\bin\ikeyman.bat
- Open the IBM HTTP
Server key file: Click Key Database File - Open,
using the following values:
- Key database type
- CMS
- File Name
- plugin-key.kdb
- File Location
- ibm_http_server_root/Plugins/config/webserver_name/
For example: C:\IBM\HTTPServer\Plugins\config\webserver1\
Click OK and enter the password for your IBM HTTP Server key file. The default password is WebAS.
- Under Key database content, select Personal Certificates.
- Click Extract Certificate and
specify a file name and location for storing the certificates. Leave
the Field Data type unchanged. For example:
- Certificate file name: cert.arm
- Location: C:\
- Using the iKeyman utility, open the WebSEAL certificate key file. When you are prompted for the password, enter the password of your WebSEAL key file. The default password is pdsrv.
- Under Key database content, select Signer Certificates.
- Click Add and then locate the
extracted IBM HTTP Server certificate
file. Enter a label for this certificate; for example: LC3_IHS_cerficate. Note: If you have already imported other IBM HTTP Server certificates into the WebSEAL certificate file, you must delete them before you can add a new certificate.
- Click Key Database File - Close to save your changes to the WebSEAL pdsrv.kdb certificate file and close the file.
- Copy the modified pdsrv.kdb WebSEAL
certificate file to the same location on the WebSEAL server.
For example: C:/Program Files/Tivoli/PDWeb/www-default/certs/pdsrv.kdb
Note: For more information about importing certificates, see the Adding certificates to the WebSphere trust store topic. - Copy the WebSEAL certificate key file to the system
where IBM HTTP Server is installed.
- Use the exported
LTPA key to configure the transparent path junctions in Tivoli Access Manager. To do so, complete
the following steps:
- Copy the LTPA keys that you exported in Step 1 to the Tivoli Access Manager server.
For example: C:\WAS7_ltpa.keys
- Open the pdadmin command line utility, which is installed as part of the Tivoli Access Manager runtime package.
- Configure a transparent path junction for each installed
application. Enter the following command once for each junction: Note: Do not include the carriage returns in the command. They are added here for display purposes.
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
where:- WebSEAL-instance-name is the name of the WebSEAL
server. Use the following syntax:
WebSEAL_instance-webseald-tam_server
For example: default-webseald-server.name.example.com
- backend-server-name is the domain name of the IBM Connections server for which Tivoli Access Manager is managing authentication. For example, IBM HTTP Server configured for IBM Connections.
- backend-server-port is the port used by the backend server.
- ltpa-token is the name of the file that you created to store the keys that you exported from WebSphere Application Server.
- ltpa-password is the password that you defined to encrypt the key file.
- transparent-path-jct is the transparent path
junction for the application. This value must match the URL pattern
and must be created once for each URL pattern:
- /acce
- /activities
- /blogs
- /cognos
- /communities
- /connections
- /dm
- /dogear
- /files
- /forums
- /help
- /homepage
- /metrics
- /mobile
- /mobileAdmin
- /moderation
- /news
- /oauth2
- /profiles
- /search
- /wikis
- /wsi
For example:
server task default-webseald-server.name.example.com create -t ssl -h another.server.name.example.com -x -p 443 -i -b ignore -f -A -2 -F -k C:\WAS7_ltpa.keys -Z password /profiles
Notes:- The -2 parameter is needed only if you are using LTPA type 2. WebSphere Application Server allows both LTPA 1 and LTPA 2.
- If an invalid certificate error occurs, import your backend-server-name certificate into the WebSEAL certificate store before you create the junctions.
- The transparent path junctions include /help even though it is not an independent IBM Connections application. It is an integral part of the News application but must be configured as a separate junction.
- WebSEAL-instance-name is the name of the WebSEAL
server. Use the following syntax:
For more information about using the pdadmin command line utility, go to the Using pdadmin to create junctions web page in the Tivoli Access Manager information center.
- Copy the LTPA keys that you exported in Step 1 to the Tivoli Access Manager server.
- 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 default ACLs to resources that are protected by
form-authentication.
- 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 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
- /wikis
- lc3-default-acl is the access control list (ACL) that you defined in Step 5
For example: acl attach /WebSEAL/tam.example.com-default/activities example-default-acl
- Attach the default ACL to other resources that are protected
by form-authentication. Run the following commands:
acl attach /WebSEAL/tam_server-WebSEAL_instance/object-path 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 that is configured to manage IBM Connections; for example: default
- object-path is the path to the resource on that domain
- lc3-default-acl is the access control list that you defined in Step 5. Replace this variable with the name of your default ACL.
For example: acl attach /WebSEAL/tam.example.com-default/activities/service/getnonce/forms example-default-acl
See the Resources that require form-authentication table for a list of URLs that are protected by form-authentication.
Table 1. Resources that require forms authentication Application Protected URL Activities /activities/seedlist/myserver /activities/service/atom2/communityEvent /activities/service/atom2/forms /activities/service/download/forms /activities/service/getnonce/forms Blogs /blogs/seedlist/myserver Bookmarks /dogear/seedlist/myserver Common resources /connections/opensocial/rest /connections/config Communities /communities/calendar/seedlist/myserver /communities/forum/service/atom/forms /communities/recomm/ajax /communities/recomm/atom_form /communities/service/atom/forms Forums /forums/atom/forms /forums/seedlist/myserver Metrics /metrics /cognos /cognos/servlet/ping Profiles /profiles/atom/forms /profiles/atom2/forms URL Preview /connections/opengraph/form/api/oembed /connections/thumbnail/form/api/imageProxy
- Attach the default ACL to application root URLs:
- Define the unprotected access control list and then attach
unprotected resources and resources that require basic-authentication
to it using the pdadmin command line utility, so that Tivoli Access Manager passes HTTP requests
for these resources through to WebSphere Application
Server for authentication.
- To define the
unprotected access control list, enter the following commands:
acl create ic-bypass-acl
acl modify ic-bypass-acl set user sec_master TcmdbsvaBRlrx
acl modify ic-bypass-acl set any-other Tmdrx
acl modify ic-bypass-acl set unauthenticated Tmdrx
acl modify ic-bypass-acl set group iv-admin TcmdbsvaBRrxl
acl modify ic-bypass-acl set group webseal-servers Tgmdbsrxl
where ic-bypass-acl is the name of the unprotected access control list; for example, connections-acl-bypass.Note: The any-other parameter refers to authenticated users who are not defined by other parameters such as sec_master or iv-admin. - To attach the access control list to resources that
do not require authentication, run the following command:
acl attach /WebSEAL/tam_server-WebSEAL_instance/object-path ic-bypass-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 that is configured to manage IBM Connections; for example: default
- object-path is the path to the resource on that domain
- ic-bypass-acl is the access control list that you defined in Step 7 a
See the Resources that do not require authentication table for a list of unprotected URLs .
Table 2. Resources that do not require authentication Application Unprotected URL Activities /activities/auth /activities/authverify /activities/images /activities/service/html/mainpage /activities/oauth /activities/service/html/images /activities/service/html/servermetrics /activities/service/html/serverstats /activities/static /activities/service/html/styles /activities/service/html/themes /activities/serviceconfigs Blogs /blogs/static /blogs/oauth /blogs/serviceconfigs Bookmarks /dogear/bookmarklet/tagslike/proxy /dogear/oauth /dogear/peoplelike /dogear/serviceconfigs /dogear/static /dogear/tagslike /dogear/tagrecs Common resources /connections/bookmarklet/tools/blet.js /connections/bookmarklet/tools/discussThis.js /connections/bookmarklet/tools/rlet.js /connections/core/oauth /connections/oauth /connections/opensocial/oauth /connections/resources/socmail-client /connections/resources/ic /connections/resources/web /connections/resources/socpim /connections/serviceconfigs /nav/common Content Manager /wsi /acce /dm Communities /communities/calendar/calendar.xml /communities/calendar/oauth /communities/images /communities/recomm/oauth /communities/recomm/recomm.xml /communities/service/atom/oauth /communities/service/html/communityview /communities/service/json/oauth/ /communities/service/opensocial/oauth /communities/serviceconfigs /communities/service/html/community/autoCompleteMembers.do /communities/service/html/singleas /communities/static /communities/stylesheet /communities/tools/embedAS.html Files /files/app /files/basic/anonymous/api /files/basic/anonymous/cmis /files/basic/anonymous/opensocial /files/form/anonymous/api /files/form/anonymous/cmis /files/form/anonymous/opensocial /files/oauth /files/static /files/serviceconfigs Forums /forums/oauth /forums/serviceconfigs /forums/static Home page /homepage/oauth /homepage/search /homepage/serviceconfigs /homepage/static Metrics /metrics/service/eventTracker /metrics/service/oauth /metrics/serviceconfigs /cognos/servlet Moderation /moderation/oauth News /help /news/common/sand/static/ /news/follow/oauth /news/microblogging/isPermitted.action /news/oauth /news/serviceconfigs /news/sharebox/config.action /news/static OAuth Provider /oauth2 Profiles /profiles/images /profiles/oauth /profiles/serviceconfigs /profiles/static /profiles/widget-catalog Search /search/atom/search/* /search/oauth /search/static /search/serviceconfigs URL Preview /connections/opengraph/form/anonymous/api/oembed /connections/opengraph/basic/anonymous/api/oembed /connections/opengraph/oauth/anonymous/api/oembed /connections/thumbnail/api/imageProxy Widget container /connections/opensocial/anonymous/rest /connections/opensocial/common /connections/opensocial/gadgets /connections/opensocial/ic /connections/opensocial/rpc /connections/opensocial/social /connections/opensocial/xrds /connections/opensocial/xpc Wikis /wikis/basic/anonymous/api /wikis/form/anonymous/api /wikis/oauth /wikis/serviceconfigs /wikis/static - The Atom feeds on IBM Connections
servers use basic authentication because most feed readers are unable
to authenticate with form-authentication. WebSphere Application Server and IBM Connections applications authenticate
these Atom HTTP requests through basic authentication as required.
To attach the unprotected ACL to resources that IBM Connections protects with basic authentication,
run the following command:
acl attach /WebSEAL/tam_server-WebSEAL_instance/object-path ic-bypass-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 that is configured to manage IBM Connections; for example: default
- object-path is the path to the resource on that domain
- ic-bypass-acl is the access control list that you defined in Step 7 a
For example: acl attach /WebSEAL/example.com-default/activities/service/atom example-bypass-acl
See the Resources that require basic authentication table for a list of protected URLs .
Table 3. Resources that require basic authentication Application Protected URL Activities /activities/follow/atom /activities/service/atom /activities/service/atom2 /activities/service/download /activities/service/getnonce /activities/service/html/autocompleteactivityname /activities/service/html/autocompleteentryname /activities/service/html/autocompletemembers Blogs /blogs/api /blogs/atom /blogs/follow/atom /blogs/issuecategories /blogs/roller-ui/blog /blogs/roller-ui/feed /blogs/roller-ui/BlogsWidgetEventHandler.do /blogs/roller-ui/rendering/api /blogs/roller-ui/rendering/feed /blogs/services/atom Bookmarks /dogear/api/app /dogear/api/deleted /dogear/api/notify /dogear/atom /dogear/people.do Common resources /connections/opensocial/basic/rest Communities /communities/calendar/atom /communities/calendar/handleevent /communities/calendar/ical /communities/follow/atom /communities/forum/service/atom /communities/recomm/atom /communities/recomm/handleevent /communities/service/atom /communities/service/atom/communities/my /communities/service/json /communities/service/opensocial Files /files/basic/api /files/basic/api/myuserlibrary/feed /files/basic/cmis /files/basic/opensocial /files/follow/atom Forums /forums/atom /forums/follow/atom Home page /homepage/atom/mysearch /homepage/atom/search /homepage/web/updates/ News /news/atom/service /news/atom/stories/community /news/atom/stories/newsfeed /news/atom/stories/public /news/atom/stories/save /news/atom/stories/saved /news/atom/stories/statusupdates /news/atom/stories/top /news/atom/watchlist /news/atomfba/stories/public Profiles /profiles/atom /profiles/atom2 /profiles/atom/forms/tagCloud.do Note: If you use case-insensitive junctions in your Tivoli Access Manager configuration, specify tagcloud.do instead of tagCloud.do./profiles/follow/atom /profiles/json /profiles/vcard /profiles/photo.do /profiles/audio.do URL Preview /connections/opengraph/basic/api/oembed /connections/thumbnail/basic/api/imageProxy Wikis /wikis/basic/api /wikis/follow/atom
- To define the
unprotected access control list, enter the following commands:
- Specify a dynamic URL pattern to support the Blogs application
and mail notification:
- Create a dynamic URL configuration file named dynurl.conf.
The dynurl.conf file is a plain text file that
contains mappings from objects to patterns. Using a text editor, add
the following content to the file:
/blogs/blogsfeed /blogs/*/feed/*
/blogs/blogsapi /blogs/*/api/*
Save the file in the webseal-instance-docroot/lib directory. For example:- AIX: /usr/Tivoli/PDweb/www-default/lib
- Linux: /opt/Tivoli/PDweb/www-default/lib
- Windows: C:\Program Files\Tivoli\PDweb\www-default\lib
- To attach the bypass ACL that you defined in Step 7 a to the dynurl ACL, open
the pdadmin command line utility and enter the following commands:
acl attach /WebSEAL/tam_server-WebSEAL_instance/blogs/blogsfeed ic-bypass-acl
acl attach /WebSEAL/tam_server-WebSEAL_instance/blogs/blogsapi ic-bypass-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 that is configured to manage IBM Connections; for example: default.
- ic-bypass-acl is the name of the access control list that you defined earlier.
For example:
acl attach /WebSEAL/server.name.example.com -default/blogs/blogsfeed open
- To allow large Blogs posts, open the webseald.conf file
and add the following parameter:
dynurl-allow-large-posts = yes
- To enable the uploading of PDF files, add the following
parameter to the webseald.conf file:
suppress-dynurl-parsing-of-posts = yes
- Create a dynamic URL configuration file named dynurl.conf.
The dynurl.conf file is a plain text file that
contains mappings from objects to patterns. Using a text editor, add
the following content to the file:
- To get the activity stream on the Homepage to display, you must import an encrypted connection
(SSL) certificate from the TAM server to the nodes.
- Navigate to SSL certificate and key management > Key stores and certificates > NodeDefaultTrustStore> \ signer certs.
- Restart the Homepage application.
Note: To get the ECM events to appear, the TAM certs have to be imported to the NodeDefaultTrustStore.If the TAM server and the Web Seal server are different, you need to import the cert from the Web seal server. - For Connections Content Manager configure an additional
set of steps for the FileNet Collaboration Services:
- To add properties, the administrator needs to edit the fncs-sitePrefs.properties file,
located in the FNCS installation directory, before running the configuration
wizard.Note: For FNCS 2.0.0.1, the fncs-sitePrefs.properties file is located in <FNCS_HOME>/configmanager/profiles/. For FNCS 2.0.3, the fncs-sitePrefs.properties file is located in <FNCS_HOME>/configure/explodedformat/fncs/WEB-INF/classes/. <FNCS_HOME> is the FNCS installation directory.
- Add the following properties to the fncs-sitePrefs.properties file
at the end of the file after the comments and save it:
urlBaseService <your http url for the TAM and WebSeal proxy>/dm fncsServerURL <your http url for the TAM and WebSeal proxy>/dm fncsServerURLSecure <your https url for the TAM and WebSeal proxy>
- After setting the properties, you must complete the steps in Configuring FileNet Collaboration Services for the Connections Content Manager.
- To add properties, the administrator needs to edit the fncs-sitePrefs.properties file,
located in the FNCS installation directory, before running the configuration
wizard.
- Configure Tivoli Access
Manager to use form-authentication over HTTPS by updating the webseald-server-name.conf file.
Add the following line to the [forms] stanza:
forms-auth = https
Note: You cannot specify HTTP-only authentication. To specify both HTTP and HTTPS, add the following line: forms-auth = both. - (Do not complete this step for Tivoli Access Manager with
SPNEGO) Add a Tivoli Allow
access to the Embedded Experience gadget by adding the following
line to the [ba] stanza in the webseald-server-name.conf file:
ba-auth = none
- Configure content filtering by adding the following lines
to the webseald-server-name.conf file:
[filter-content-types]
type = text/xml
type = application/atom+xml
[script-filtering]
script-filter = yes
rewrite-absolute-with-absolute = yes
- Configure recognition of double-byte character sets. Update
the webseald-server-name.conf file:
Add the following lines:
decode-query = yes
utf8-qstring-support-enabled = yes
- Configure Tivoli Access
Manager as the reverse proxy for IBM Connections.
Update the webseald-server-name.conf file:
Add the following line to the [server] stanza:
web-host-name = fully-qualified-host-name
Add the following line to the [session] stanza:
use-same-session = yes
Stop and restart your WebSEAL instance.
- Update the values for the dynamicHosts and interService
URL attributes in the LotusConnections-config.xml configuration
file:
- Use the following command to check out the LotusConnections-config.xml file: execfile("app_server_root/profiles/DMGR/bin/connectionsConfig.py")LCConfigService.checkOutConfig("working_directory","cell_name")Note: If you are prompted to specify which server to connect to, type 1.where:
- working_directory is the temporary working directory to which configuration files are stored while you edit them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.
- cell_name is the name of the WebSphere Application Server cell hosting
the IBM Connections application.
This argument is case sensitive. If you do not know the cell name,
enter the following command in the wsadmin client to determine it:
print AdminControl.getCell()
- Update the dynamicHosts values by running the following
commands:
Enable dynamicHosts:
LCConfigService.updateConfig("dynamicHosts.enabled","true")
Enter the WebSEAL host name in the values for the dynamicHosts.href and dynamicHosts.ssl_href attributes:
LCConfigService.updateConfig("dynamicHosts.href","http://WebSEAL_host")
LCConfigService.updateConfig("dynamicHosts.ssl_href","https://WebSEAL_host")
where WebSEAL_host is the fully qualified host name of the WebSEAL server.
Notes:Each href attribute in the LotusConnections-config.xml file is case-sensitive and must specify a fully-qualified domain name.
- The fully-qualified host name for the WebSEAL server and the dynamicHosts configuration must be identical.
- (Do not complete this step for Tivoli Access Manager with SPNEGO)
Update the interService URL values by running the following command:
LCConfigService.updateConfig("application_interService_key","https://WebSEAL_host")
where:- WebSEAL_host is the fully qualified host name of the WebSEAL server
- application_interService_key is the href attribute
for the application and includes the following applications:
- activities.interService.href
- blogs.interService.href
- communities.interService.href
- dogear.interService.href
- files.interService.href
- forums.interService.href
- help.interService.href
- homepage.interService.href
- mobile.interService.href
- moderation.interService.href
- news.interService.href
- personTag.interService.href
- profiles.interService.href
- quickr.interService.href
- sametimeLinks.interService.href
- sametimeProxy.interService.href
- search.interService.href
- wikis.interService.href
- Check the LotusConnections-config.xml file
in by running the following command:
LCConfigService.checkInConfig()
Note: You can also complete this step by running the connectionsConfig.py script in the wsadmin client. - Use the following command to check out the LotusConnections-config.xml file:
- Determine how you want the system to behave when users
log out of IBM Connections.
By default, when users click Log out in the
SSO environment, they are not fully logged out of IBM Connections. Edit the IBM HTTP Server httpd.conf configuration
file to implement the post-log out behavior. By default, the file
is located in the following directory:
- AIX: /usr/IBM/HTTPServer/conf
- Linux: /opt/IBM/HTTPServer/conf
- Windows: C:\IBM\HTTPServer\conf
To capture requests to /ibm_security_logout and redirect them to /pkmslogout, add the following rewrite rules to the httpd.conf file:
RewriteEngine On
RewriteCond %{REQUEST_URI} /(.*)/ibm_security_logout(.*)
RewriteRule ^/(.*) /pkmslogout [noescape,L,R]
Note: You must add these rules to both the HTTP and HTTPS entries.Ensure that the line that enables mod_rewrite is not commented out by removing the preceding # symbol. For example:
LoadModule rewrite_module modules/mod_rewrite.so
The following example illustrates a typical portion of the httpd.conf file after you have implemented the steps described in this step:
RewriteEngine On
RewriteCond %{REQUEST_URI} /(.*)/ibm_security_logout(.*)
RewriteRule ^/(.*) /pkmslogout [noescape,L,R]
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
<IfModule mod_ibm_ssl.c>
Listen 0.0.0.0:443
<VirtualHost *:443>
ServerName connections.example.com
SSLEnable
RewriteEngine On
RewriteCond %{REQUEST_URI} /(.*)/ibm_security_logout(.*)
RewriteRule ^/(.*) /pkmslogout [noescape,L,R]
</VirtualHost>
</IfModule>
SSLDisable
- Add an ErrorDocument 500 statement to the httpd.conf file. This statement appears in the user's browser if an IBM Connections application becomes unavailable.
- Save and close the httpd.conf file.
- Restart IBM HTTP Server.
- (Do not
complete this step for Tivoli Access Manager with SPNEGO) Add a Tivoli Access Manager authenticator
property by editing the LotusConnections-config.xml file.
- Use
the following command to check out the configuration file:
execfile("app_server_root/profiles/DMGR/bin/connectionsConfig.py")
Note: If you are prompted to specify which server to connect to, enter 1.LCConfigService.checkOutConfig("working_directory","cell_name")
where:- app_server_root is the WebSphere Application Server installation directory
- DMGR is the name of the Deployment Manager profile. For example: Dmgr01
- working_directory is the temporary working directory to which the configuration XML and XSD files are copied while you edit them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.
- cell_name is the name of the WebSphere Application Server cell hosting
the IBM Connections application.
This argument is case sensitive. If you do not know the cell name,
execute the following command in the wsadmin client to determine it:
print AdminControl.getCell()
For example:
LCConfigService.checkOutConfig("c:/temp","foo01Cell01")
- Configure the custom authenticator to support server-to-server
authentication for Tivoli Access
Manager:
LCConfigService.updateConfig("customAuthenticator.name",
"TAMAuthenticator")
- Keep the file open until you have completed the next step.
- Use
the following command to check out the configuration file:
- (Do
not complete this step for Tivoli Access
Manager with SPNEGO) Configure the cookie timeout value for IBM Connections:
- Locate the CookieTimeout attribute in the LotusConnections-config.xml file. If the attribute is not present, add it to the <customAuthenticator name="TAMAuthenticator"> element.
- Set the value, in minutes, of the CookieTimeout attribute
to be equal to or less than the maximum timeout and idle timeout values that you configured in Tivoli Access Manager. Note: When your production environment is ready, set the AllowSelfSignedCerts parameter to false.Note: If the parameter does not already exist in the LotusConnections-config.xml file, create it. Open the file in a text editor and add the parameter to the customAuthenticator element.
- Save your changes.
- Check the LotusConnections-config.xml file
back in by running the following command:
LCConfigService.checkInConfig()
- The value of the
cookie timeout attribute in the LotusConnections-config.xml file
must be smaller than the values of the timeout and inactive-timeout
attributes in the webseald-server-name.conf file.
Check these values in the [session] stanza of the webseald-server-name.conf file
and edit them if necessary. Note: The values of the timeout parameters in the Tivoli Access Manager configuration file are given in seconds but the CookieTimeout value in the LotusConnections-config.xml file is given in minutes.
Use the following example as a guide:
# Maximum lifetime (in seconds) for an entry in the credential cache
# Setting this to zero allows entries in the cache to fill without expiry until the
# cache contains the number of entries specified by max-entries. After that
# point, entries are expired according to a least recently used algorithm.
timeout = 3600
# Lifetime (in seconds) of inactive entries in the credential cache.
# To disable, set to 0.
inactive-timeout = 600
- Import the Tivoli Access Manager certificate into the WebSphere Application Server trust store. For more information, see the Adding certificates to the WebSphere trust store topic.
- Restart your cluster: Stop all application servers and all nodes, and then restart the deployment manager, all the nodes, and all the application servers.