IBM Security Access Manager, Version 8.0 Distributed Session Cache Architectural Overview and Migration Guide

Transcription

1 IBM Security Systems Access Management June, 2014 IBM Security Access Manager, Version 8.0 Distributed Session Cache Architectural Overview and Migration Guide Authors Jenny Wong Trevor Norvill Special Thanks Peter Horner and John Sedgmen Version P age

2 Note: Before using this information and the product it supports, read the information in "Notices." Edition notice This edition applies to version 8.0 of IBM Security Access Manager (product number C87) and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright International Business Machines Corporation Note to U.S. Government Users Restricted Rights - - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. 2 P age

3 Table of Contents 1 About this document Understanding the Distributed Session Cache Overview Distributed Session Cache replaces Session Management Server Deployment considerations Failover with distributed Session Cache...Error! Bookmark not defined External Reference Entity Session Management Clients High Availability Requirements Disaster Recovery Requirements Migration General Migration Considerations and limitations Migration to Distributed Session Cache In- line migration Parallel migration Configuring Distributed Session Cache Creating a clustered ISAM 8 environment Configuring the WebSEAL servers Verify Single Data Centre Environment Advanced configuration for the Distributed Session Cache DSC Administrative Tools Using LMI Using dscadmin RESTful Web Services Configure concurrent session policy in DSC Managing user sessions in DSC View sessions Terminating sessions Advanced WebSEAL configurations Maximum Concurrent Sessions WebSEAL Session Cache sizes Timeout Inactivity re- authentication Page

4 5 Troubleshooting Appendix 1 - Multiple Data Centers with session sharing Creating a clustered ISAM 8 environment Configuring the WebSEAL servers Testing the environment Table of Contents for Figures and Table Figure 1 Single Data Center Distributed Session Cache Deployment Table 1 Session Manager Server and Distributed Session Cache capabilities... 9 Table 2 In- line Migration Versus Parallel Migration from SMS to DSC Table 3 Testing Single Data Center P age

5 1 Preface This section provides: Links to Online publications. A link to the IBM Terminology website. The statement of good security practices Access to online publications IBM posts product publications when the product is released and when the publications are updated at the following locations: IBM Security Systems Documentation Central provides an alphabetical list of all IBM Security Systems product libraries and links to the online documentation for specific versions of each product. IBM Knowledge Center ( 01.ibm.com/support/knowledgecenter/) offers customized search functions to help you find all the IBM publications you need. IBM Terminology website The IBM Terminology website consolidates terminology for product libraries in one location. You can access the Terminology website at Statement of Good Security Practices IT system security involves protecting systems and information through prevention, detection and response to improper access from within and outside your enterprise. Improper access can result in information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of your systems, including for use in attacks on others. No IT system or product should be considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access. IBM systems, products and services are designed to be part of a comprehensive security approach, which will necessarily involve additional operational procedures, and may require other systems, products or services to be most effective. IBM DOES NOT WARRANT THAT ANY SYSTEMS, PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE YOUR ENTERPRISE IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT OF ANY PARTY. 5 P age

6 Document Control Information Date Person Short Description 05/03/14 Jenny Wong Initial Version 20/03/14 Trevor Norvill Document Review 21/03/14 Jenny Wong Add Advanced configuration for DSC and Troubleshooting 31/03/14 Jenny Wong Edited migration section. 04/06/14 Michalea Moore Document Review 09/06/14 Jenny Wong General formatting and Document Review 6 P age

7 1 About this document This document provides users with an overview about the Distributed Session Cache feature in IBM Security Access Manager, version 8.0, appliance. This article examines differences between the IBM Security Access Manager Session Management Server component and its replacement, the Distributed Session Cache. The aim is to provide users an outline of configuration requirements and architectural dependencies; as well as considerations when it comes to planning and deploying a solution that meets availability and performance requirements 7 P age

8 2 Understanding the Distributed Session Cache 2.1 Overview The IBM Security Access Manger, Version 8.0, appliance introduces a new component called the Distributed Session Cache (DSC). It provides a centralized cache to store and maintain user session data and state across a clustered server environment. The IBM Security Access Manager Session Manager Server is deprecated starting with IBM Security Access Manger, Version 8.0, and is replace by the DSC. The key capabilities it provides include: Managing sessions across clustered Web security servers. Resolving session inactivity and session lifetime timeout consistency issues in a replicated Web security server environment. Providing secure failover and single sign- on among replicated Web security servers. Providing a policy that can enforce the maximum number of concurrent sessions per user. Providing single sign- on capabilities and single sign- off among other websites in the same DNS domain. Providing performance and high availability protection to the server environment in the event of hardware or software failure. Offering administrators the ability to view and modify sessions on the WebSEAL server. The Distributed Session Cache is available in both IBM Security Access Manger for Web, Version 8.0, and IBM Security Access Manager for Mobile, Version 8.0. Customers can apply license keys to activate either product to utilize the Distributed Session Cache component. 2.2 Distributed Session Cache replaces Session Management Server The Distributed Session Cache feature replaces the IBM Security Access Manager Session Manager Server component that was released in IBM Tivoli Access Manager, Version 6.0.0, and remains available through IBM Security Access Manager for Web, Version 7.0. To simplify the architecture of the deployment and management of a session management solution, the Distributed Session Cache adds session management capabilities to the IBM Security Access Manager appliance technology. Benefits include: Reduced cost of deployment, maintenance, and monitoring Reduced complexity and increased stability Improved management and user experience Table [1] compares the capabilities of the Distributed Session Cache and the Session Manager Server component. Topic Session Manager Server Distributed Session Cache Implementation uses WebSphere ObjectGrid and WebSphere Extreme Scale (for later versions of Session Manager Server). This requires deployment of additional hardware and software: Ease of deployment Runs on IBM Security Access Manager appliance technology. The Distributed Session Cache component is enabled by selecting a single checkbox. Less required hardware and software. 8 P age

9 o Separate WebSphere Application Server cluster. o Separate WebSphere extremescale catalog service cluster. Ease of configuration Separate component that requires additional configuration Multi- step process to start the required components. Scalability Requires clustered WebSphere Application Server and separate WebSphere extremescale Catalog service cluster for a highly available solution. Session Management Provides pdadmin and pdsmsadmin command- line based administration utility. Infrastructure Requires: WebSphere Application Server with extremescale and a separate catalog service cluster (Session Manager Server, Version 6.1 and later), IBM HTTP Server with WebSphere Web Server Plug- in, and Session Manager Server application Availability More hardware and software components required for a HA solution. Maintenance and Upgrade Requires fix packs for WebSphere Application Server, WebSphere extremescale (Session Manager Server, Version 6.1 and later), IBM Http Server, and Session Manager Server. Simple administration interface built on appliance technology. Scalability built into appliance technology. Distributed Session Cache cluster configuration supports up to 4 master appliance nodes for HA failover. Distributed Session Cache administrative functions are in the local management interface console or via the Distributed Session Cache command- line tool (dscadmin). Features packaged on the IBM Security Access Manager appliances for easy deployment. Appliance clustering technology allows simple deployment of a HA solution. Single appliance firmware update. Distributed Session Cache can interoperate with IBM Security Access Manager, Version 7.0, servers for easy migration. Session Policy Concurrent session policy enforcement. Concurrent session policy enforcement Last login information stored in Session (on a per replica set basis). Manager Server. Session termination via dscadmin. Failed login count. Last login data not supported on Session termination via pdsmsadmin. Distributed Session Cache component. Last login data stored in directory server (IBM Security Directory Server only) as of IBM Security Access Manager, Version Does not provide Multiple session realms. Table 1 Session Manager Server and Distributed Session Cache capabilities The Distributed Session Cache provides user session sharing for a clustered IBM Security Access Manager environment, concurrent session policy enforcement, and central management of sessions. A few Session Manager Server capabilities are no longer supported in the Distributed Session Cache. These include: Last Login Information in Distributed Session Cache: In previous releases of IBM Security Access Manager, last login information was accessible through the Session Manager Server. Storage and retrieval of last login data is no longer supported in the Distributed Session Cache. As of IBM Security Access Manager, Version 6.1.1, last login information can be stored and retrieved using LDAP functionality. This is supported on IBM Security Directory Server only. 9 P age

10 Session refresh capability: This function provided a mechanism to refresh a credential (e.g. a change of group membership) in a Session Manager Server session. This capability is no longer supported in the Distributed Session Cache. Multiple session realms: Distributed Session Cache no longer supports multiple session realms. The scope of a user s session is defined by a session realm and it is now limited to a single session realm. For session sharing to function correctly, all of the following conditions must be met: o The values for session lifetime and inactivity timeouts on all reverse proxy servers in the replica sets must be identical. o Authentication configuration and policy on all servers in the replica sets must be compatible. 2.3 Deployment considerations This section discusses deployment considerations that are new to the Distributed Session Cache Administering the Distributed Session Cache Section, Administering the Distributed Session Cache, outlines configuration options and policy settings for the Distributed Session Cache and how you can configure the Distributed Session Cache system to reflect your current Session Manager Server deployment. An overview of the administrative capabilities includes the command line interface, restful web services interface, and the local management interface. It also details how to set appropriate policy and WebSEAL configuration to reflect the existing Session Manager Server capabilities Cluster deployment considerations You must configure the IBM Security Access Manger appliance into an IBM Security Access Manger cluster to setup a highly available solution. Distributed Session Cache approaches high availability using a different mechanism to the Session Manager Server. The extremescale technology used by the Session Manager Server was replaced with clustering technology in the IBM Security Access Manger appliance. This simplifies the deployment, configuration, maintenance, and overall complexity of the solution. A Distributed Session Cache cluster must have at least 1 master appliance node called the primary master. It is possible to configure up to a maximum of four 4 masters in the cluster for resilience. The subsequent masters are called the secondary, tertiary, and quaternary masters. They operate as back- up servers if the primary master fails. Choose the size of the cluster based on the required level of tolerance to failures. It is possible to configure other appliances to join the cluster as nodes (non- masters). Appliances configured as a node can be promoted to a master if an existing master stops functioning. Distributed Session Cache runs on the primary master node, while other non- primary masters act as stand- by masters in case the primary master fails External Reference Entity An External Reference Entity (ERE) is a network reference point for configured masters of an IBM Security Access Manager cluster to check the health of the network. The External Reference Entity is configured between two paired master nodes of the same cluster. It helps determine the status of the communication link between two masters if it fails, whether it is a hardware or brownout failure. 10 P age

11 2.3.4 Distributed Session Cache Clients The Distributed Session Cache is an optional service that acts as a centralized session repository for a clustered IBM Security Access Manager WebSEAL server environment. It is an embedded cluster service feature in the appliance that manages the session for the following sources: Appliance- based Reverse Proxy instances that are members of the same clustered distributed session cache server. Appliance- based Reverse Proxy instances that are on appliances that are not in the same cluster as the distributed session cache server. It is recommended to include the appliance in the same cluster as the distributed session cache server. Software- based WebSEAL (Reverse Proxy) instances of version High Availability Deployment Considerations The Distributed Session Cache is a critical component to the operation of an IBM Security Access Manager infrastructure. When deploying a solution with high availability requirements, the solution must be designed to offer component redundancy and fault tolerance. A typical deployment of the Distributed Session Cache involves a set of reverse proxies and a set of Distributed Session Cache servers. There can be between 1 and 4 Distributed Session Cache servers, depending on the availability requirements of the solution. Figure [1] shows a typical single data center Distributed Session Cache deployment with 2 Distributed Session Cache servers and 2 reverse proxy servers to achieve failover. Figure 1 Single Data Center Distributed Session Cache Deployment 11 P age

12 In this configuration, there is 1 primary Distributed Session Cache server and 1 secondary Distributed Session Cache server. The primary master server is the active server that services requests. The secondary server acts as a stand- by server to provide failover capabilities. When an update of configuration or policy data must be made to the cluster, it can be achieved via the primary master only. The primary master maintains the master copy of the Distributed Session Cache while the secondary master keeps a replica copy (or local read- only). It is possible to configure up to 4 masters in the cluster along with non- master nodes to provide extra failover for the Distributed Session Cache Disaster Recovery Deployment Considerations An IBM Security Access Manager solution often requires a separate disaster recovery site for catastrophic failures of a primary data center. A typical approach to this problem is to deploy 2 separate IBM Security Access Manager/Distributed Session Cache environments in separate data centers. Switching to the disaster recovery site typically involves a major catastrophic event, and it is usually acceptable to ask users to re- establish a new session in such an event. User sessions are typically not replicated between the two data centers, because it simplifies the IBM Security Access Manager/Distributed Session Cache solution and provides better performance during normal operation. It is possible to deploy an IBM Security Access Manager deployment that spans 2 geographically separated data centers with shared sessions, if required. The Distributed Session Cache can support this requirement; consider it carefully because it increases the complexity of the solution, especially if the distance between data centers is large. A solution that limits the scope of a session to a single datacenter increases the performance of the system, improves data center isolation, simplifies management of, and reduces the overall complexity of the solution. Appendix A - Multiple Data Centers with session sharing discusses a multi- data center shared session use case. 12 P age

13 3 Migration The Distributed Session Cache replaces the Session Manager Server solution that was available in earlier releases of IBM Security Access Manager. You have several options for migrating to the Distributed Session Cache component that depend on your current system and session management requirements. This section covers general migration considerations, describes an in- line upgrade process, and outlines a parallel deployment approach. Section 3.3, Configuring Distributed Session Cache, details the Reverse Proxy and Distributed Session Cache configuration required to implement these approaches. 3.1 General Migration Considerations and limitations When performing a migration, there are some aspects about which customers must be aware: User sessions are not retained across the upgrade. A parallel system migration, where a separate IBM Security Access Manager, Version 8.0, system runs in parallel with the production system, minimizes any down time requirement. This parallel system migration makes detailed system testing of the new solution possible before going live. It is not recommended to perform in place upgrades for IBM Security Access Manager systems to minimize downtime during migration. The IBM Security Access Manager appliance, Version 8.0, Distributed Session Cache can interoperate with IBM Security Access Manager, Version 7.0, servers. IBM Security Access Manager, Version 6.x, does not support the Distributed Session Cache. The Distributed Session Cache requires significantly less hardware to deploy a highly available solution. To ensure a successful migration from an Session Manager Server enabled environment to Distributed Session Cache, allocate enough resources when carrying out the process. 3.2 Migration to Distributed Session Cache IBM Security Access Manager, Version 7.0, supports the Distributed Session Cache for migration purposes. There are two possible approaches, in- line upgrade and parallel migration. An in- line upgrade can only be performed if the IBM Security Access Manager system is at version 7. Table [2] presents the advantages and disadvantages of each approach. Migration type Advantages Disadvantages In- line upgrade: Less hardware required. Optimized upgrade path. Less costly. Quick upgrade process. Requires production system to be at a minimum of IBM Security Access Manager, Version 7.0. No fall back environment. Testing cannot be done before going live. Parallel deployment Provides fall back environment. Less downtime. Allows testing of new systems before going into production. Requires more hardware. More costly. Table 2 In- line Migration Versus Parallel Migration from Session Manager Server to Distributed Session Cache 13 P age

14 Note: To use the Distributed Session Cache on IBM Security Access Manager, Version 7.0, WebSEAL Web Proxy Servers, you must apply the latest fixpack on the IBM Security Access Manager, Version 7.0, systems before modifying the WebSEAL Web Proxy instances for communication with Distributed Session Cache In-line migration The following process describes an in- line migration of Session Manager Server to Distributed Session Cache. Note: This process is only valid when upgrading from an IBM Security Access Manager, Version 7.0, system. 1. Install IBM Security Access Manager, Version 8.0, Distributed Session Cache. 2. Modify the IBM Security Access Manager, Version 7.0, WebSEAL Reverse Proxy instances to use the Distributed Session Cache. 3. Restart WebSEAL Reverse proxy instances Parallel migration The following process documents a parallel upgrade where an IBM Security Access Manager environment using Session Manager Server is run in parallel with an IBM Security Access Manager, Version 8.0, environment. The directory and policy servers are migrated in- line. These components can also be run in parallel to further minimize the risk to the production, but this process is outside the scope of this document. 1. Keep the existing WebSEAL and Session Manager Server environment until they are ready to be decommissioned. It can serve as a fall back environment in case of problems with the new system. 2. Upgrade the directory server to IBM Security Access Manager, Version 8.0, specifications. 3. Upgrade the policy server to IBM Security Access Manager, Version Configure the existing WebSEAL and Session Manager Server environment against the IBM Security Access Manager, Version 8.0, policy server. 5. Setup a parallel environment that includes IBM Security Access Manager, Version 8.0, Reverse Proxies (WebSEALs) and Distributed Session Cache. 6. Configure IBM Security Access Manager, Version 8.0, WebSEAL and Distributed Session Cache against IBM Security Access Manager, Version 8.0, policy server, which is also now used for the production IBM Security Access Manager environment. 7. Perform extensive testing on the new IBM Security Access Manager, Version 8.0, environment while production load continues to go through the existing IBM Security Access Manager system. 8. Switch to the IBM Security Access Manager, Version 8.0, system. You can do it over time; for example, start with internal users and then move external users to the new infrastructure. 9. Use the original WebSEAL/Session Manager Server environment as a fall back/disaster recovery environment until there is a high degree of confidence in the new system. 3.3 Configuring Distributed Session Cache This section covers the configuration steps to set up a single data center and focuses on setting up the deployment environment illustrated in Figure [1]. You should read this section in conjunction with the IBM Security Access Manager Web Reverse Proxy Administration Guide, which describes the necessary tasks to set up an IBM Security Access Manager appliance environment, details on cluster support, and ways to manage the appliance. In this chapter, Configuring Distributed Session Cache, it outlines how to configure a highly available IBM Security Access Manager environment with Distributed Session Cache. Assumptions 14 P age

15 The IBM Security Access Manager for Web environment is already set up, including LDAP, Policy Server, Authorization Server, and Reverse Proxy instances. The solution is deployed in a single data center. An IBM Security Access Manger 8 appliance has been activated with the Web Gateway appliance license and set up with 2 Reverse Proxy instances. You must: 1. Activate Web Gateway appliance mode on appliances. 2. Configure Runtime Component (LDAP and Policy Server). 3. Configured Management and Application Interfaces as required. 4. Configured 2 Reverse Proxy instances. 5. Modify each Reverse Proxy instance configuration file to enable forms authentication. Two separate IBM Security Access Manger, Version 8.0, appliances are set up and used as the dedicated Distributed Session Cache cluster Creating a clustered IBM Security Access Manager 8 environment For Distributed Session Cache to address failover, you must configure multiple appliances into a cluster. The configuration in this section requires one of the appliances to be a designated primary master and another as a secondary master Activate the appropriate license on the appliances. You can find instructions on how to obtain and activate your license on the appliance in the IBM Knowledge Center. Refer to the Product Documentation in IBM Knowledge Center under Section Release Information for the appliance. Documentation for the web and mobile appliance can be found via the following links: IBM Security Access Manager for Web appliance product documentation IBM Security Access Manager for Mobile appliance product documentation Set up a cluster environment with the two appliances to be Distributed Session Cache dedicated server. 1. Select an appliance to be the primary master ( 2. Go to Manage System Settings > Select Cluster Configuration: 3. Set the value Primary Master on the selected appliance to the IP address of the first management interface. 15 P age

16 4. Select General tab > Select Set this appliance as the primary master. 5. Save and deploy this update. The appliance with IP address is now configured as the primary master of a cluster that can contain multiple nodes. 16 P age

17 6. Return to the Overview tab. The Export button is enabled, and the Import button disabled. 7. Export the cluster signature file on the primary master. The cluster signature file contains configuration information that cluster members can use to identify and communicate with the primary master. 8. Save this configuration to a convenient location on your desktop. 9. On the second appliance, which is IP , import this cluster signature file to make it become a cluster member. The process of joining an appliance to the cluster is called registration. Go to Manage System Settings 17 P age

18 > Cluster Configuration > Overview Tab > Import. 10. Browse to the signature output file and click join. On the new appliance, you should see the following nodes under Cluster Configuration of the primary master local management interface console. 11. Update the cluster configuration on the primary master to make the second appliance a secondary master. Go to the local management interface console of the Primary Master and select Manage System Settings > Cluster Configurations > General tab. 18 P age

19 12. Select the IP of the second appliance as the Secondary Master using the drop down box. 13. Define the Master External Reference Entity to a network reference point such as a router. Use the IP router at as the External Reference Entity. 14. Click Save. 15. Review and deploy these changes to the appliance. At this point, you have configured a clustered appliance environment with two nodes, which are both masters. 19 P age

20 Now that you have a primary master for the cluster, you must manage any further cluster configuration updates must through the primary master local management interface console Modify the Session Cache configuration for the cluster 1. In the local management interface console of the primary master, select Manage System Settings > Cluster Configuration > Session Cache tab > Select Support internal and external clients. This indicates that both internal and external clients can utilize Distributed Session Cache. Examples of external clients are web security servers, such as WebSEAL instances, that are located on a separate appliance than the Distributed Session Cache cluster. 2. Assign a port number which external clients use to communicate with the session cache. This example uses P age

21 This port is used in later steps during the WebSEAL Configurations phase. Remember to manually assign the port. It cannot be 9080, which it is utilized by WebSphere Liberty, and causes the following error: 3. Save and deploy these changes. Note: Update Host file so that each node knows of other nodes in the cluster. Updating ensures the non- primary nodes can contact the runtime on the primary node of the cluster. Otherwise, the status is no status. Now that the Distributed Session Cache cluster is set up, you can now configure the web security servers Configuring the WebSEAL servers There are two options to configure WebSEAL/Reverse Proxy to use Distributed Session Cache: WebSEAL running on a cluster node, which includes a node running the distributed session cache cluster. WebSEAL configured externally to the distributed Session Cache cluster. In this example, a WebSEAL instance is configured on a different virtual appliance (IP address ). This WebSEAL appliance is not part of the Distributed Session Cache cluster. Assumptions: You have Configured runtime component on the external WebSEAL appliance. Configured two new reverse proxy instances. The process for setting up an external WebSEAL to utilize the Distributed Session Cache is as follows: 1. Configure each WebSEAL instance to use the Distributed Session Cache. a. Go the local management interface console of the WebSEAL appliance. 21 P age

22 b. Select Secure Web Settings > Manage Reverse Proxy. In this instance, there are already two configured reverse proxy instances. c. In the Distributed Session Cache cluster, via the Primary Masters local management interface console, ensure that Support internal and external clients is selected. Note: If you want to configure SSL communication between the clients and Distributed Session Cache, go to the Product Documentation in IBM Knowledge Center under Configuring Web Reverse Proxy and refer to the section on SSL Configuration for WebSEAL and the distributed Session cache. 2. On the WebSEAL appliance machine, go to the WebSEAL instances. 3. Enable the distributed session cache. Select Session >Edit and check Enable Distributed Session Cache. 22 P age

23 4. Save and Deploy the settings. 5. Open the WebSEAL configuration file for one of the WebSEAL instances. Choose external1 first by selecting external1 > Manage > Configuration > Edit Configuration File. 6. Make the following modifications to enable the Distributed Session Cache and configure it against the existing Distributed Session Cache cluster environment. 23 P age

24 Sessions are always served from the Primary Master. The Secondary master starts serving sessions only if the Primary Master fails. With highest to lowest priority level for each Distributed Session Cache server is based on the ordering of the masters such as: [dsess-cluster] server = 9, server = 8, server = 7, server = 6, The following configuration is for the example environment: [server] web-host-name = isam8.webseal1.ibm.com [session] logout-remove-cookie = yes dsess-enabled = yes prompt-for-displacement = yes register-authentication-failures = yes dsess-last-access-update-interval = 60 standard-junction-replica-set = default-rset1 [replica-sets] replica-set = default-rset1 [dsess] dsess-sess-id-pool-size = 125 dsess-cluster-name = dsess [dsess-cluster] server = 9, #primary master server = 8, #secondary master response-by = 60 handle-pool-size = 10 handle-idle-timeout = 240 timeout = 30 [session-cookie-domains] domain = ibm.com 7. Save and deploy changes. 8. Repeat the same sets of steps from (3) to (7) for WebSEAL server external2 with the following details in the WebSEAL configuration [server] web-host-name = isam8.webseal2.ibm.com [session] logout-remove-cookie = yes dsess-enabled = yes prompt-for-displacement = yes register-authentication-failures = yes dsess-last-access-update-interval = 60 standard-junction-replica-set = default-rset1 [replica-sets] replica-set = default-rset1 24 P age

25 [dsess] dsess-sess-id-pool-size = 125 dsess-cluster-name = dsess [dsess-cluster] server = 9, #primary master server = 8, #secondary master response-by = 60 handle-pool-size = 10 handle-idle-timeout = 240 timeout = 30 [session-cookie-domains] domain = ibm.com 9. Save and deploy changes. 10. Restart all WebSEAL instances. Expect to see the following message in the WebSEAL logs: :40: :00I x38CF0156 webseald WARNING wwa server config.cpp x7fa8f83e DPWWA0342W The configuration data for this WebSEAL instance has been logged in '/var/pdweb/external1/log/config_data external1-webseald-isam8.webseal.ibm.com.log' :40: :00I x38B9A430 webseald WARNING wns session WSRemoteCache.cpp 889 0x7fa8f83e DPWNS1072W WebSEAL received notification that the distributed session cache for replica-set 'default-rset1' was cleared. All local references to sessions are being discarded to synchronize the local session cache with the distributed session cache :40: :00I x1354A0CD webseald WARNING ivc general azn_maint.cpp x7fa8f83e HPDCO0205W Note: It is feasible to have the WebSEAL dedicated appliance configured as a node in the same cluster environment as the configured Distributed Session Cache. The WebSEAL instances can be configured internally on any node instance (master node or not) in the cluster. If internal WebSEALs are an appropriate configuration for the environment, you use instead the Support internal clients only option under the Session Cache configuration for the cluster. Port numbers are automatically assigned when using Support Internal Clients only. When the Enable distributed session cache option is checked in the WebSEAL instance Edit menu, the server URL entries under the [dsess-cluster] stanza are updated automatically in the WebSEAL instance configuration file with the assigned port number. An example of the URL entries look like the following example: 25 P age

26 Note: The number of URLs included are based on the number of master configured in the Distributed Session Cache cluster. All other configurations explained in the previous section remain the same Verify Single Data Centre Environment After you complete the steps for setting up the data center environment, the following steps help verify the environment. 1. Log into the Primary Master local management interface console > Secure Web Settings > Manage > Distributed Session Cache. The replica- set you defined in the previous section is listed. 2. Test Distributed Session Cache by opening a new browser and going to 26 P age

27 3. Authenticate with a valid user such as sec_master. Upon a successful authentication, you see the following screen: 4. To ensure Distributed Session Cache failover to a different WebSEAL Reverse Proxy is working in the existing browser, change the URL so that it points to the second WebSEAL Reverse Proxy instance, which is You are not prompted to re- authenticate and see the following image: 27 P age

28 This indicates single sign- on between the WebSEAL Reverse Proxy instances is operating as expected. Below is a table of other basic scenarios you can utilize to help test this environment. Test Case Number Test Description Test Steps Expected Behavior 1 SSO between WebSEALs works 1. Log in to WebSEAL1 at 2. Access WebSEAL2 at The user is not prompted to log in to WebSEAL2. 2 Logout between WebSEALs works 3 Distributed Session Cache Master Failover 1. Log in to WebSEAL1 at 2. Access WebSEAL2 at and log out. 3. Access WebSEAL1 again at 1. Stop primary master in single data center. 2. Log in to WebSEAL1 at 3. Access WebSEAL2 and log out at 4. Access WebSEAL1 again at The user is prompted to log back in when re- accessing WebSEAL1. Monitor logs in the Reverse Proxy from the Web Gateway Appliance: 1. Log into the local management interface. 2. Select Secure Web Settings > Manage Reverse Proxy. 3. Select WebSEAL instance > Manage > Logging> Inspect the msg webseal- <instancename>.log file to see the following error: An error occurred when attempting to communicate with the SOAP server URL <primary> master The user is not prompted to log in to WebSEAL2 4 Distributed Session Cache Master Failover 1. Stop secondary master in single data center Monitor logs in the Reverse Proxy from the Web Gateway Appliance: 1. Log into the local management interface. 2. Select Secure Web Settings > Manage Reverse Proxy > Select on the WebSEAL instance > Manage > Logging> Inspect the msg webseal- <instancename>.log file to see the following error: An error occurred when attempting to communicate with the SOAP server URL <secondary> master The user is not prompted to log in to WebSEAL2 28 P age

29 Test Case Number Test Description Test Steps Expected Behavior 5 Confirm the login policy is used across data centers. 1. Set up a user who can only have 1 session. (pdadmin>policy set max-concurrentwebsessions 1 -user testuser) 2. Log the user into a WebSEAL instance in the data center at 3. Create a browser session. 4. Try to log in to the second WebSEAL instance in the data center at Table 3 Testing Single Data Center The user is successfully logged in to the first instance, but cannot log in to second. 29 P age

30 4 Administering the Distributed Session Cache This section outlines the configuration options and policy setting for the Distributed Session Cache and how you can configure them to reflect your current Session Manager Server deployment. 4.1 Distributed Session Cache Administrative Tools There are a number of mechanisms on the appliance so that you can perform administrative operations on the Distributed Session Cache. These include the local management interface, CLI, and Restful services. The following sections discuss each of these tools in detail Using local management interface The browser- based graphical user interface called the local management interface is one of the tools for managing the Distributed Session Cache. Depending which license mode you activate on the appliances that host Distributed Session Cache, go to Secure Web Settings/Secure Mobile Settings > Manage > Distributed Session Cache. This displays the following information in the browser: You can perform several user session management operations through the local management interface. If you investigate which WebSEAL Reverse Proxy instances are utilizing this Distributed Session Cache cluster environment, you can select the replica- set name defined in the WebSEALs server, which in this case is default- rset1. 30 P age

31 4.1.2 Using dscadmin The dscadmin tool is accessible through the appliance command- line interface (CLI) through either an SSH session or the console. To access the tool via the console, perform the following steps: 1. Log onto the appliance CLI console with the admin account. 2. In this terminal session, enter isam dscadmin. 3. To view the available operations that you can perform with dscadmin, type help RESTful Web Services You can manage the Distributed Session Cache by sending RESTful web service request to the appliance. For further information on how to utilize this tool, see the appliance product documentation: 01.ibm.com/support/knowledgecenter/SSPREK_ /com.ibm.amweb.doc_ /admin/concept/con_web _service.html?lang=en 4.2 Configure concurrent session policy in Distributed Session Cache You can control the number of sessions each user can have at one time in a distributed session environment managed by the Distributed Session Cache. Configure the concurrent session policy in the Distributed Session Cache with the pdadmin tool on the appliance hosting the WebSEAL Reverse Proxy. The following examples show the command syntax for configuring this pdadmin policy (each command entered as one line): To set the policy, the command is as follows: 31 P age

32 policy set max-concurrent-web-sessions {unset number displace unlimited} [-user username] To retrieve the policy, use the following command: policy get max-concurrent-web-sessions [-user username] You can apply the concurrent session policy to a specific user or globally to all users registered in this secure domain. Consider the following examples for how to apply the policy using pdadmin: Applying a maximum of 3 sessions for the user John. Applying a maximum of 1concurrent sessions globally to all users registered in the secure domain: You also can configure the concurrent session policy that is tied to the WebSEAL instance. There is a WebSEAL configuration settings enforce-max-session-policy under [session] that controls whether the specific WebSEAL enforces maximum concurrent sessions. By default, this setting defaults to yes. This setting, however, is only effective when it has been defined in the configuration file that Distributed Session Cache manages the sessions for the environment. In other words, enforce-max-session-policy is only applicable when dsess-enabled is set to yes. 4.3 Managing user sessions in Distributed Session Cache You can perform administrative tasks, such as viewing and terminating user sessions, in the Distributed Session Cache. The appliance allows you to perform these tasks either via the Distributed Session Cache Management page in the local management interface or with Distributed Session Cache administrative tools from the command- line interface. The sections below explore the various administrative tasks available to help manage user session in the Distributed Session Cache. For further information about managing the Distributed Session Cache in the appliance, you may refer to the following product documentation: Managing Distributed Session Cache using the management page 01.ibm.com/support/knowledgecenter/SSPREK_ /com.ibm.amweb.doc_ /admin/task/tsk_manage_ dsc.html?lang=en Understand dscadmin commands options from the command- line interface 01.ibm.com/support/knowledgecenter/SSPREK_ /com.ibm.amweb.doc_ /admin/concept/con_dsca dmin.html?lang=en View sessions Use the dscadmin tool to list all the session management sessions in a specified replica set. Use the following syntax: 32 P age

33 session list pattern maximum_return replica_set_name The following screenshot presents an example that executes that command through the dscadmin tool: 1. To view sessions via the local management interface console, log into Primary Master Distributed Session Cache LMI > Secure Web Settings > Manage Distributed Session Cache. 2. Select the replica- set default- rset1 name, click Sessions to list all the existing user sessions under this replica- set Terminating sessions You can terminate a session in the Distributed Session Cache with either the command line interface or the local management interface. Administrators have the option to terminate sessions on a per- user basis or a per- session basis. When terminating sessions on a per- user basis, all existing sessions for a specific user in a specified replica set are terminated. When performing this in the dscadmin tool, you must use the following syntax: session terminate all_sessions user_id replica-set-name 33 P age

34 If you want to terminate sessions on a per- session basis, this is typically done by deleting sessions individually using a session ID in the specified replica set. When performing this in the dscadmin tool, you must use the following syntax: session terminate session session-id replica-set-name If you delete available sessions in a particular replica- set on the Distributed Session Cache through the local management interface console, you can do so by listing all the sessions using steps outlined in the View sessions section and by selecting the session you want to terminate and clicking on Delete. 4.4 Advanced WebSEAL configurations The goal of the Distributed Session Cache is to provide centralized caching to store and maintain user session data and state across a clustered server environment. There are a number of required configuration changes you must make to ensure optimum performance for the WebSEAL Reverse Proxy servers. These settings include: Understanding the maximum number of sessions a Distributed Session Cache server is required to hold. Defining settings include session cache size, timeout values, and re- authentication in WebSEAL Reverse Proxy to achieve optimal performance Maximum Concurrent Sessions It is important to consider the maximum number of concurrent sessions that a Distributed Session Cache- enabled IBM Security Access Manager system is required to handle. The number of concurrent sessions in the Distributed Session Cache dictates how much memory each Distributed Session Cache server and WebSEAL use. The number of concurrent sessions is determined by the number of authentications per second required across the IBM Security Access Manger Web Security server environment, the session idle timeout, and the maximum session lifetime. As an example, consider a deployment scenario there are: 2 configured WebSEAL servers. 2 configured Distributed Session Cache cluster members. 5 authentications per second with an idle timeout of 30 minutes and maximum session time of 1 hour. 80% of sessions idle timeout, and the remaining 20% reach the maximum session lifetime. To estimate the maximum number of concurrent sessions, use the following calculation: 5 authen/sec * 60 = 300 authentications/minute 300 authentications/min * 30 mins = 9000 sessions created in 30 minutes. After that time, 80% of these idle out = Therefore, this leaves 1800 sessions remaining. In the next 30 minutes, another 9000 are created, leaving total sessions remaining. Consequently, at any one time, ~ authenticated sessions remain in the Distributed Session Cache. 34 P age

35 4.4.2 WebSEAL Session Cache sizes A WebSEAL session cache stores information about all sessions established by authenticated and unauthenticated users. You can determine the maximum number of concurrent sessions in the Distributed Session Cache by the sum of the maximum number of sessions each WebSEAL server can hold. When the WebSEAL session caches reach their cache size limit, sessions are dropped from the WebSEAL cache using a least recently used (LRU) algorithm. The Distributed Session Cache maintains sessions only as long as there is a WebSEAL server referencing that session. Session information is removed from the Distributed Session Cache if no WebSEAL instance holds a reference to the session. Using the preceding example, set the cache size for each WebSEAL Reverse Proxy instance to a minimum of To configure the session cache sizes in WebSEAL on the appliance, the max-entries entry controls the maximum of entries in the WebSEAL session cache. This setting controls the number of sessions WebSEAL can manage. The ssl-max-entries entry controls the maximum number of SSL sessions handled in the SSL session cache. Typically both setting are set to the same size. Both max-entries and ssl-max-entries are in the [session] stanza and [ssl] stanza respectively in the WebSEAL configuration file. By default, it is set at To configure these settings on the appliance, do so by authentication to the Web Gateway Appliance > Secure Web Settings > Manage Reverse Proxy > Select a configured WebSEAL instance > Click Manage > Configuration > Edit Configuration File. 2. The Advanced Configuration File Editor for the WebSEAL instance opens; use it to find and edit the session cache configuration settings. 35 P age

36 3. Once you have completed the change, Click on Save, Deploy the changes, and Restart the instance Timeout There are two important timeout configuration parameters. These parameter settings are the user session time- out (timeout) and the user inactivity timeout (inactive-timeout). Both settings are under the [session] stanza of the WebSEAL configuration file and are defined in seconds. User session timeout determines the maximum lifetime value for all user sessions. The inactive-timeout parameter defines a timeout value for user session inactivity. With inactive-timeout defined, WebSEAL Reverse Proxy either deleted the user s inactive session or flags the session as requiring re- authentication if the user has a session that is inactive for longer than the specified parameter. Set the values for the User session time-out and inactive-timeout to align with business policy and typical user activity. The defaults are 1 hour and 10 minutes respectively. Note: As an alternative to the following steps, you can directly edit the configuration item through the WebSEAL configuration file with the steps in section 4.4.2, WebSEAL Session Cache sizes. 1. To configure these timeout settings on the appliance, go to the Web Gateway Appliance > Secure Web Settings > Manage Reverse Proxy > Select a configured WebSEAL instance > Click Manage > Configuration > Select Edit to display the Reverse Proxy Basic Configuration window. 2. Select the Session tab. 3. Take one or both of the following actions: To define the timeout setting, edit the Lifetime Timeout entry field. To define the inactive- timeout setting, edit the Inactive Timeout entry field. 36 P age