Enable single sign-on for Tivoli Access Manager 




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

Before you begin


 

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:

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

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

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

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

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

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

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

  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 WAS 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/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

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

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

    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:

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

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

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

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

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

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

    1. 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")

    2. Update the reauthenticate property...

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

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

        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

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



January 30, 2012
   

 

Jan 30, 2012 3:42:08 PM 9 Jan 30, 2012 3:40:51 PM 8 Dec 6, 2011 5:19:09 PM Added URLs to Table 2. 7 Oct 19, 2011 6:32:45 PM Removed seedlist URLs from table of resources that require forms-based... 6 Aug 29, 2011 6:19:26 AM Fix layout error. 5 Aug 29, 2011 6:17:45 AM Removed note about Realm Name from the "Before you begin" section. 4 Aug 3, 2011 4:11:33 PM O Perez   Fix typo in step #10. [filter-content-types should be [filter-conte... 3 Jul 27, 2011 11:40:42 AM Correcting code formatting. 2 Jul 27, 2011 11:38:34 AM Added third bullet about -k /mobile to the Notes section of Step 4c. 1 Submitted by Carlo Garcia on Jan 30, 2012 3:48:56 PM

Re: Enabling single sign-on for Tivoli Access Manager

If you use case-insensitive junctions in your TAM config, use the lowercase Profiles tag cloud rule tagcloud.do instead of tagCloud.do.

This resolved an issue where the Mobile application could not be reached in this particular configuration.

Error:

"Unable to access the Connections server."

});