Enabling single sign-on for Security Verify Access
Configure HCL Connections™ to use single sign-on with Security Verify Access (formerly Security Access Manager).
Before you begin
Install the supported version of IBM Security Verify Access (ISVA).
Ensure that you can access the installed Connections applications from a web browser.
Set the IBM® WebSphere® Application Server single sign-on domain to the same value as that of the Security Verify Access server.
- Connections supports the WebSphere® cookie-based lightweight third-party authentication (LTPA) mechanism as an SSO solution for SVA. 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.
- For more information, refer to IBM Security Verify Access on the IBM Documentation site.
About this task
Single sign-on (SSO) enables users to log in to one application of Connections and switch to other applications and resources without having to authenticate again.
Connections supports the use of encrypted connections Transparent Path junctions with SVA. Connections does not support TCP type junctions or Standard junctions. This procedure uses a WebSphere® Application Server LTPA key and WebSEAL Transparent Junctions.
To set up SSO using Security Verify Access, complete the following steps:
Procedure
- 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 HTTP Server certificate into the Security Verify Access keystore. To import the
certificate, complete the following steps:
-
To support SSO with the Lightweight Third-Party Authentication (LTPA) key, the same keys
and passwords must be shared by Security Verify Access and WebSphere® Application Server. To export the keys from WebSphere® Application Server, complete the following
steps:
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 Security Verify Access server, to the same location that you used to create the Security Verify Access junctions. See Step 4 for more details.
-
Use the exported LTPA key to configure the transparent path junctions in Security Verify
Access.
For more information about using the pdadmin command line utility, refer to Server task commands for junctions in the Security Verify Access knowledge center.
-
Create a default 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.
-
Define the unprotected access control list and then attach unprotected resources and
resources where Connections requires basic authentication using the pdadmin command line
utility, so that Security Verify Access passes HTTP requests for these resources through to
WebSphere Application Server for authentication.
-
To get the activity stream on the Homepage to display, you must import an encrypted
connection (SSL) certificate from the SVA server to the nodes.
- Navigate to .
- Restart the Homepage application.
Note: To get the ECM events to appear, the SVA certs must be imported to the NodeDefaultTrustStore.If the SVA server and the WebSEAL server are different, you need to import the cert from the WebSEAL server. -
Specify a dynamic URL pattern to support the Blogs application and mail notification:
-
Configure Security Verify Access to use form-authentication over HTTPS by updating the
webseald-server-name.conf file. Add the following
line to the [forms] stanza:
forms-auth = https
Note: You cannot specify HTTP-only authentication. To specify both HTTP and HTTPS, add the following line: forms-auth = both. -
(Do not complete this step for Security Verify Access with SPNEGO) Add HCL Allow access to
the Embedded Experience gadget by adding the following line to the [ba] stanza in the
webseald-server-name.conf file:
ba-auth = none
- Configure content filtering by adding the following lines
to the webseald-server-name.conf file:
[filter-content-types]
type = text/xml
type = application/atom+xml
[script-filtering]
script-filter = yes
rewrite-absolute-with-absolute = yes
- Configure recognition of double-byte character sets. Update
the webseald-server-name.conf file:
Add the following lines:
decode-query = yes
utf8-qstring-support-enabled = yes
-
Configure Security Verify Access as the reverse proxy for 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
-
Configure Security Verify Access to include host information in the HTTP header. Update the
webseald-server-name.conf file:
In the
[header-names]stanza, add the following line:httphdr{host} = X-Forwarded-Host
Stop and restart your WebSEAL instance.
-
Determine how you want the system to behave when users log out of Connections. By default, when
users click Log out in the SSO environment, they are not fully logged out of
Connections. Edit the 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 that are 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 a Connections application becomes unavailable.
- Save and close the httpd.conf file.
- Restart HTTP Server.
- 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 Security Verify Access 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
- Restart your cluster: Stop all application servers and all nodes, and then restart the deployment manager, all the nodes, and all the application servers.