Enabling single sign-on for Tivoli Access Manager 

---

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

Before you begin

Before you begin this task, ensure that the Realm Name field in the Federated repositories section of the WebSphere® Application Server Integrated Solutions console uses the same value as the LDAP name, including the port number. For example, if the primary repository host name is ldapserver.example.com and the port number is 389, then you must enter ldapserver.example.com:389 in the Realm Name field.

You must first install IBM Connections and successfully access the installed applications from a web browser before you can enable single sign-on. You must also have IBM Tivoli Access Manager for e-business, version 6.1 Fix Pack 4, installed before you can perform this procedure.

Set the IBM WebSphere Application Server 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 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 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 WebSphere Application Server LTPA key and WebSEAL Transparent Junctions.

To set up SSO using Tivoli Access Manager, complete the following steps:

Procedure

1. 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:
   1. 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.
   2. 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
      
   3. 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.
   
2. 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.
3. Import your IBM HTTP Server certificate into the Tivoli Access Manager keystore. To import the certificate, complete the following steps:
   1. 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.
      
   2. 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
      
   3. 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.
      
   4. Under Key database content, select Personal Certificates.
   5. 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:\
          
          
   6. 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.
   7. Under Key database content, select Signer Certificates.
   8. 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.
      
   9. Click Key Database File - Close to save your changes to the WebSEAL pdsrv.kdb certificate file and close the file.
   10. 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.
   
4. Use the exported LTPA key to configure the transparent path junctions in Tivoli Access Manager. To do so, complete the following steps:
   1. Copy the LTPA keys that you exported in Step 1 to the Tivoli Access Manager server.
      
      For example: C:\WAS7_ltpa.keys
      
   2. Open the pdadmin command line utility, which is installed as part of the Tivoli Access Manager runtime package.
   3. 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 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:
          • /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. WebSphere Application Server 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 Using pdadmin to create junctions web page in the Tivoli Access Manager information center.
      
5. 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
   
6. Attach default ACLs to resources that are protected by form-authentication.
   1. 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
      
   2. Attach the default ACL to other resources that are protected by form-authentication. Run the following commands:
      

      Application	Protected URL
      Activities	/activities/seedlist/myserver
      	/activities/service/atom2/communityEvent
      	/activities/service/atom2/forms
      	/activities/service/download/forms
      	/activities/service/getnonce/forms
      Bookmarks	/dogear/seedlist/myserver
      Communities	/communities/forum/service/atom/forms
      	/communities/service/atom/forms
      Forums	/forums/atom/forms
      	/forums/seedlist/myserver
      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 form-authentication.
      
      Table 1. Resources that require form-authentication
      
7. 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.
   1. 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.
      
   2. 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/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
      
   3. 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:
      

      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 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
      	/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
      
8. Specify a dynamic URL pattern to support the Blogs application and mail notification:
   1. 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
          
          
   2. 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
      
   3. To allow large Blogs posts, open the webseald.conf file and add the following parameter:
      
      dynurl-allow-large-posts = yes
      
9. 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.
   
10. 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
    
11. 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.
    
12. Update the values for the dynamicHosts and interService URL attributes in the LotusConnections-config.xml configuration file:
    1. 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()
           
       For example: LCConfigService.checkOutConfig("c:/temp","foo01Cell01")
       
    2. 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.
           
           
    3. (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
             
             
    4. 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.
    
13. 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
    
14. 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.
15. Save and close the httpd.conf file.
16. Restart IBM HTTP Server.
17. 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.
    
    • 1. Use the following command to 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 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 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 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()
             
         For example: LCConfigService.checkOutConfig("c:/temp","foo01Cell01")
         
      2. Update the custom authenticator value by running the following command:
         
         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.
         
      3. Check the LotusConnections-config.xml file back in by running the following command:
         
         LCConfigService.checkInConfig()
         
18. 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
    
19. 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, complete the following steps:
    1. Use the following command to 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 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 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 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:
       
       FilesConfigService.checkOutConfig("c:/temp","foo01Cell01")
       
    2. Update the reauthenticate property by running the following command:
       
       FilesConfigService.updateConfig("security.reauthenticateAndSaveSupported", "false")
       
    3. Check the files-config.xml file in by running the following command:
       
       FilesConfigService.checkInConfig()
       
20. 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: Configuring single sign-on

Related concepts
Securing IBM Connections

Related tasks
Enabling single sign-on for standalone LDAP
Changing references to administrative credentials
Adding certificates to the WebSphere trust store
Enabling single sign-on for Tivoli Access Manager with SPNEGO

Related information