Enabling single sign-on for Tivoli Access Manager

Enable single sign-on for Tivoli Access Manager

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

Before starting

You must have IBM Tivoli Access Manager for e-business, version 6.1, Fix Pack 4, installed before you can perform this procedure. Ensure that you can access the installed IBM Connections applications from a web browser.
Set the IBM WAS single sign-on domain to the same value as that of the Tivoli Access Manager server.

Note:

If you are enabling SSO between IBM Connections and a product that is deployed with a stand-alone LDAP configuration on WAS, or if the product is using IBM Lotus® Domino®, first complete the steps described in the Enable 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 Change 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 SSL 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 information 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 WAS LTPA key and WebSEAL Transparent Junctions.

To set up SSO using Tivoli Access Manager...

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 WAS. To export the keys from WAS...

Log into the WAS admin 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.

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...

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, 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 IBM HTTP Server topic.

Use the exported LTPA key to configure the transparent path junctions in Tivoli Access Manager. To do so...

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 one 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 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> <transparent-path-jct>

where:

<WebSEAL-instance-name> is the name of the WebSEAL server. Use the following syntax:
<WebSEAL_instance>-webseald-<tam_server>

where <WebSEAL_instance> is the name of the instance of the WebSEAL server set up to manage IBM Connections, such as default, and <tam_server> is the host name of the Tivoli Access Manager 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 WAS
<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:

/activities
/blogs
/communities
/dogear
/files
/forums
/help
/homepage
/mobile
/moderation
/news
/profiles
/search
/wikis

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 C:\WAS7_ltpa.keys -Z <password> /profiles

Notes:

The -2 parameter is needed only if you are using LTPA type 2. WAS allows both LTPA 1 and LTPA 2.
If your deployment of IBM Connections is integrated with Quickr® J2EE, add the -k parameter to the command for the Activities and Communities junctions. For example, adapt the following command for the Activities junction:
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 C:\WAS7_ltpa.keys -Z <password> -k /activities

If you installed the mobile application, add the -k parameter to the command for the mobile junction. For example, adapt the command as follows:
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 C:\WAS7_ltpa.keys -Z <password> -k /mobile

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.

For more information about using the pdadmin command line utility, go to the Use pdadmin to create junctions web page in the Tivoli Access Manager information center.

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
/communities
/dogear
/files
/forums
/homepage
/news
/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:

Application Protected URL
Activities /activities/service/atom2/communityEvent
/activities/service/atom2/forms
/activities/service/download/forms
/activities/service/getnonce/forms
Communities /communities/forum/service/atom/forms
/communities/service/atom/forms
Forums /forums/atom/forms
Profiles /profiles/atom/forms
/profiles/atom2/forms

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 forms-based authentication.

Table 1. Resources that require forms-based authentication

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 WAS for authentication.

To define the unprotected access control list, enter the following commands:

acl create <lc3-bypass-acl>

acl modify <lc3-bypass-acl> set user sec_master TcmdbsvaBRlrx

acl modify <lc3-bypass-acl> set any-other Tmdrx

acl modify <lc3-bypass-acl> set unauthenticated Tmdrx

acl modify <lc3-bypass-acl> set group iv-admin TcmdbsvaBRrxl

acl modify <lc3-bypass-acl> set group webseal-servers Tgmdbsrxl

where <lc3-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:

Application Unprotected URL
Activities /activities/auth
/activities/authverify
/activities/bookmarklet/tools/blet.js
/activities/email/addMemberMail.jsp
/activities/email/autoCompleteActivityMail.jsp
/activities/email/createMail.jsp
/activities/email/errorMail.jsp
/activities/email/notifyMail.jsp
/activities/images
/activities/service/html/mainpage
/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/bookmarklet/tools/blet.js
/blogs/notifications
/blogs/static
/blogs/serviceconfigs
Bookmarks /dogear/bookmarklet/tagslike/proxy
/dogear/bookmarklet/tools/blet.js
/dogear/peoplelike
/dogear/serviceconfigs
/dogear/static
/dogear/tagslike
/dogear/tagrecs
/dogear/templates
Communities /communities/bookmarklet/tools/blet.js
/communities/images
/communities/mail/broadcast
/communities/mail/invitedToJoin
/communities/mail/memberAdded
/communities/mail/memberRemoved
/communities/mail/requestToJoin
/communities/serviceconfigs
/communities/service/html/community/autoCompleteMembers.do
/communities/static
Files /files/basic/anonymous/api
/files/app
/files/basic/anonymous/cmis
/files/basic/anonymous/opensocial
/files/form/anonymous/api
/files/form/anonymous/cmis
/files/form/anonymous/opensocial
/files/static
Forums /forums/bookmarklet/tools/blet.js
/forums/serviceconfigs
/forums/static
/forums/templates/mail
Home page /homepage/bookmarklet/tools/blet.js
/homepage/search
/homepage/serviceconfigs
/homepage/static
News /help
/news/atom/stories/public
/news/atomfba/stories/public
/news/bookmarklet/tools/blet.js
/news/serviceconfigs
/news/static
Profiles /profiles/bookmarklet/tools/blet.js
/profiles/images
/profiles/mail
/profiles/serviceconfigs
/profiles/static
Search /search/atom/search/*
/search/bookmarklet/tools/blet.js
/search/static
Wikis /wikis/basic/anonymous/api
/wikis/form/anonymous/api
/wikis/static

acl attach /WebSEAL/<tam_server>-<WebSEAL_instance>/<object-path> <lc3-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
<lc3-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

The Atom feeds on IBM Connections servers use basic authentication because most feed readers are unable to authenticate with form-authentication. WAS 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:

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
Communities /communities/follow/atom
/communities/forum/service/atom
/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
News /news/atom/service
/news/atom/stories/community
/news/atom/stories/newsfeed
/news/atom/stories/save
/news/atom/stories/saved
/news/atom/stories/statusupdates
/news/atom/stories/top
/news/atom/watchlist
Profiles /profiles/atom
/profiles/atom/forms/tagCloud.do
/profiles/follow/atom
/profiles/json
/profiles/vcard
/profiles/photo.do
/profiles/audio.do
/profiles/atom2
Wikis /wikis/basic/api
/wikis/follow/atom

acl attach /WebSEAL/<tam_server>-<WebSEAL_instance>/<object-path> <lc3-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
<lc3-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

Specify a dynamic URL pattern to support the Blogs application and mail notification:

Create a dynurl 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 <lc3-bypass-acl>

acl attach /WebSEAL/<tam_server>-<WebSEAL_instance>/blogs/blogsapi <lc3-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
<lc3-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

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 HTTP, add the following line instead: forms-auth = both.

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 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:

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 WAS 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()

For example: LCConfigService.checkOutConfig("c:/temp","foo01Cell01")

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...

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...

LCConfigService.checkInConfig()

Note: You can also complete this step by running the connectionsConfig.py script in the wsadmin client.

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.
Add a Tivoli Access Manager customAuthenticator property to the IBM Connections configuration:

Note: If you are configuring Tivoli Access Manager with SPNEGO, do not complete this step. That configuration uses the Kerberos customAuthenticator.

Check out the LotusConnections-config.xml configuration 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:

app_server_root is the WAS installation directory
<DMGR> is the name of the dmgr profile. For example: Dmgr01
<working_directory> is the temporary working directory to which the XML and XSD 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 WAS 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()

For example: LCConfigService.checkOutConfig("c:/temp","foo01Cell01")

Update the custom authenticator value...

Configure the custom authenticator to support server-to-server authentication for Tivoli Access Manager:

LCConfigService.updateConfig("customAuthenticator.name",

"TAMAuthenticator")

Set the value of the customAuthenticator.CookieTimeout parameter to be equal to or less than the maximum timeout and idle timeout values that you configured in Tivoli Access Manager.

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.

Specify the timeout value in minutes.

LCConfigService.updateConfig

("customAuthenticator.CookieTimeout","<timeout>"

where <timeout> is a value in minutes that is less than or equal to the Tivoli Access Manager timeout values.

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.

Check the LotusConnections-config.xml file back in...

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

Update the reauthenticate property in the files-config.xml file. When this property is set to false, and when an IBM Connections application detects a session timeout, users must log in again through the SSO authentication mechanism. To update the reauthenticate property...

Check out the file:

execfile("<app_server_root>/profiles/<DMGR>/bin/filesAdmin.py")

Note: If you are prompted to specify which server to connect to, enter 1.

FilesConfigService.checkOutConfig("<working_directory>","<cell_name>")

where:

app_server_root is the WAS installation directory
<DMGR> is the name of the dmgr profile. For example: Dmgr01
<working_directory> is the temporary working directory to which the configuration XML and XSD files are copied and 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 WAS 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:

FilesConfigService.checkOutConfig("c:/temp","foo01Cell01")

Update the reauthenticate property...

FilesConfigService.updateConfig("security.reauthenticateAndSaveSupported", "false")

Check the files-config.xml file in...

FilesConfigService.checkInConfig()

Restart your cluster: Stop all application servers and all nodes, and then restart the deployment manager, all the nodes, and all the application servers.

Parent topic
Configure single sign-on

Related concepts
Securing IBM Connections

Related tasks
Enable single sign-on for standalone LDAP
Change references to administrative credentials
Add certificates to the WebSphere trust store
Enable single sign-on for Tivoli Access Manager with SPNEGO

Related information
IBM Tivoli Access Manager information center

+
Search Tips | Advanced Search

Application	Protected URL
Activities	/activities/service/atom2/communityEvent
	/activities/service/atom2/forms
	/activities/service/download/forms
	/activities/service/getnonce/forms
Communities	/communities/forum/service/atom/forms
Communities	/communities/service/atom/forms
Forums	/forums/atom/forms
Profiles	/profiles/atom/forms
Profiles	/profiles/atom2/forms

Application	Unprotected URL
Activities	/activities/auth
	/activities/authverify
	/activities/bookmarklet/tools/blet.js
	/activities/email/addMemberMail.jsp
	/activities/email/autoCompleteActivityMail.jsp
	/activities/email/createMail.jsp
	/activities/email/errorMail.jsp
	/activities/email/notifyMail.jsp
	/activities/images
	/activities/service/html/mainpage
	/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/bookmarklet/tools/blet.js
	/blogs/notifications
	/blogs/static
	/blogs/serviceconfigs
Bookmarks	/dogear/bookmarklet/tagslike/proxy
	/dogear/bookmarklet/tools/blet.js
	/dogear/peoplelike
	/dogear/serviceconfigs
	/dogear/static
	/dogear/tagslike
	/dogear/tagrecs
	/dogear/templates
Communities	/communities/bookmarklet/tools/blet.js
	/communities/images
	/communities/mail/broadcast
	/communities/mail/invitedToJoin
	/communities/mail/memberAdded
	/communities/mail/memberRemoved
	/communities/mail/requestToJoin
	/communities/serviceconfigs
	/communities/service/html/community/autoCompleteMembers.do
	/communities/static
Files	/files/basic/anonymous/api
	/files/app
	/files/basic/anonymous/cmis
	/files/basic/anonymous/opensocial
	/files/form/anonymous/api
	/files/form/anonymous/cmis
	/files/form/anonymous/opensocial
	/files/static
Forums	/forums/bookmarklet/tools/blet.js
	/forums/serviceconfigs
	/forums/static
	/forums/templates/mail
Home page	/homepage/bookmarklet/tools/blet.js
	/homepage/search
	/homepage/serviceconfigs
	/homepage/static
News	/help
	/news/atom/stories/public
	/news/atomfba/stories/public
	/news/bookmarklet/tools/blet.js
	/news/serviceconfigs
	/news/static
Profiles	/profiles/bookmarklet/tools/blet.js
	/profiles/images
	/profiles/mail
	/profiles/serviceconfigs
	/profiles/static
Search	/search/atom/search/*
	/search/bookmarklet/tools/blet.js
	/search/static
Wikis	/wikis/basic/anonymous/api
	/wikis/form/anonymous/api
	/wikis/static