Comments
Description
Transcript
Document 1303382
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 ([email protected]) Trevor Norvill ([email protected]) Special Thanks Peter Horner and John Sedgmen Version 1.0 1 | P a g e 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 5724-‐C87) and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright International Business Machines Corporation 2014. Note to U.S. Government Users Restricted Rights -‐-‐ Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. 2 | P a g e Table of Contents 1 About this document ..................................................................................................................................................... 7 2 Understanding the Distributed Session Cache............................................................................................................... 8 3 2.1 Overview ................................................................................................................................................................ 8 2.2 Distributed Session Cache replaces Session Management Server......................................................................... 8 2.3 Deployment considerations ................................................................................................................................. 10 2.3.1 Failover with distributed Session Cache ..........................................................Error! Bookmark not defined. 2.3.2 External Reference Entity ............................................................................................................................ 10 2.3.3 Session Management Clients ....................................................................................................................... 11 2.3.4 High Availability Requirements .................................................................................................................... 11 2.3.5 Disaster Recovery Requirements ................................................................................................................. 12 Migration ..................................................................................................................................................................... 13 3.1 General Migration Considerations and limitations .............................................................................................. 13 3.2 Migration to Distributed Session Cache............................................................................................................... 13 3.2.1 In-‐line migration........................................................................................................................................... 14 3.2.2 Parallel migration......................................................................................................................................... 14 3.3 4 Configuring Distributed Session Cache ................................................................................................................ 14 3.3.1 Creating a clustered ISAM 8 environment ................................................................................................... 15 3.3.2 Configuring the WebSEAL servers................................................................................................................ 21 3.3.3 Verify Single Data Centre Environment ....................................................................................................... 25 Advanced configuration for the Distributed Session Cache ........................................................................................ 30 4.1 DSC Administrative Tools ..................................................................................................................................... 30 4.1.1 Using LMI ..................................................................................................................................................... 30 4.1.2 Using dscadmin ............................................................................................................................................ 31 4.1.3 RESTful Web Services................................................................................................................................... 31 4.2 Configure concurrent session policy in DSC......................................................................................................... 31 4.3 Managing user sessions in DSC ............................................................................................................................ 32 4.3.1 View sessions ............................................................................................................................................... 32 4.3.2 Terminating sessions.................................................................................................................................... 33 4.4 Advanced WebSEAL configurations ..................................................................................................................... 34 4.4.1 Maximum Concurrent Sessions ................................................................................................................... 34 4.4.2 WebSEAL Session Cache sizes ...................................................................................................................... 35 4.4.3 Timeout........................................................................................................................................................ 36 4.4.4 Inactivity re-‐authentication ......................................................................................................................... 37 3 | P a g e 5 Troubleshooting........................................................................................................................................................... 39 Appendix 1 -‐ Multiple Data Centers with session sharing ................................................................................................... 41 5.1.1 Creating a clustered ISAM 8 environment ................................................................................................... 41 5.1.2 Configuring the WebSEAL servers................................................................................................................ 49 5.1.3 Testing the environment.............................................................................................................................. 52 Table of Contents for Figures and Table Figure 1 Single Data Center Distributed Session Cache Deployment .................................................................................. 11 Table 1 Session Manager Server and Distributed Session Cache capabilities ....................................................................... 9 Table 2 In-‐line Migration Versus Parallel Migration from SMS to DSC ................................................................................ 13 Table 3 Testing Single Data Center ...................................................................................................................................... 29 4 | P a g e 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 ( http://www-‐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 http://www.ibm.com/software/globalization/terminology. 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 a g e Document Control Information Date 05/03/14 Person Jenny Wong Short Description 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 a g e 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 a g e 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 Ease of deployment • Session Manager Server Implementation uses WebSphere ObjectGrid and WebSphere Extreme Scale (for later versions of Session Manager Server). This requires deployment of additional hardware and software: • • Distributed Session Cache 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 a g e Separate WebSphere Application Server cluster. o Separate WebSphere eXtremeScale catalog service cluster. Separate component that requires additional configuration Multi-‐step process to start the required components. Requires clustered WebSphere Application Server and separate WebSphere eXtremeScale Catalog service cluster for a highly available solution. Provides pdadmin and pdsmsadmin command-‐line based administration utility. o Ease of configuration • • Scalability • Session Management • 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 • More hardware and software components required for a HA solution. • Requires fix packs for WebSphere Application Server, WebSphere eXtremeScale (Session Manager Server, Version 6.1 and later), IBM Http Server, and Session Manager Server. • Concurrent session policy enforcement. • Last login information stored in Session Manager Server. • Failed login count. • Session termination via pdsmsadmin. Availability Maintenance and Upgrade Session Policy • 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. Concurrent session policy enforcement (on a per replica set basis). Session termination via dscadmin. Last login data not supported on Distributed Session Cache component. Last login data stored in directory server (IBM Security Directory Server only) as of IBM Security Access Manager, Version 6.1.1. 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 a g e • • 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. 2.3.1 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. 2.3.2 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. 2.3.3 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 a g e 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: • • • 2.3.5 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 7.0. 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 a g e 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. 2.3.6 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 a g e 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 In-‐line upgrade: Parallel deployment Advantages • 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. • Provides fall back environment. • Less downtime. • Allows testing of new systems before going into production. Disadvantages • No fall back environment. • Testing cannot be done before going live. • Requires more hardware. • More costly. Table 2 In-‐line Migration Versus Parallel Migration from Session Manager Server to Distributed Session Cache 13 | P a g e 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. 3.2.1 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. 3.2.2 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 8.0. 4. 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 a g e • • • • 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. 3.3.1 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. 3.3.1.1 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 3.3.1.2 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 (http://10.150.25.55). 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 a g e 4. Select General tab > Select Set this appliance as the primary master. 5. Save and deploy this update. The appliance with IP address 10.150.25.55 is now configured as the primary master of a cluster that can contain multiple nodes. 16 | P a g e 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 10.150.25.32, 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 a g e > 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 a g e 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 10.150.0.1 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 a g e 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. 3.3.1.3 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 9081. 20 | P a g e 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. 3.3.2 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 10.150.25.40). 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 a g e 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 a g e 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 a g e 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, http://<primary_master_IP>:port_number server = 8, http://<secondary_master_IP>:port_number server = 7, http://<tertiary_master_IP>:port_number server = 6, http://<quaternary_master_IP>:port_number 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,http://10.150.25.55:9081/DSess/services/DSess #primary master server = 8,http://10.150.25.32:9081/DSess/services/DSess #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 a g e [dsess] dsess-sess-id-pool-size = 125 dsess-cluster-name = dsess [dsess-cluster] server = 9,http://10.150.25.55:9081/DSess/services/DSess #primary master server = 8,http://10.150.25.32:9081/DSess/services/DSess #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: 4-02-04-17:40:41.378+10:00I----- 0x38CF0156 webseald WARNING wwa server config.cpp 4795 0x7fa8f83e5720 -- 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' 2014-02-04-17:40:42.515+10:00I----- 0x38B9A430 webseald WARNING wns session WSRemoteCache.cpp 889 0x7fa8f83e5720 -- 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. 2014-02-04-17:40:42.650+10:00I----- 0x1354A0CD webseald WARNING ivc general azn_maint.cpp 5729 0x7fa8f83e5720 -- 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 a g e 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. 3.3.3 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 http://isam8.webseal1.ibm.com. 26 | P a g e 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 http://isam8.webseal2.ibm.com . You are not prompted to re-‐authenticate and see the following image: 27 | P a g e 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 http://isam8.webseal1.ibm.com. The user is not prompted to log in to WebSEAL2. Logout between WebSEALs works 1. Log in to WebSEAL1 at http://isam8.webseal1.ibm.com). 2 2. Access WebSEAL2 at http://isam8.webseal2.ibm.com. 2. Access WebSEAL2 at http://isam8.webseal2.ibm/pkmslogout and log out. The user is prompted to log back in when re-‐accessing WebSEAL1. 3. Access WebSEAL1 again at http://isam8.webseal1.ibm.com). 3 Distributed Session Cache Master Failover 1. Stop primary master in single data center. 2. Log in to WebSEAL1 at http://isam8.webseal1.ibm.com. 3. Access WebSEAL2 and log out at http://isam8.webseal2.ibm/pkmslogout. 4. Access WebSEAL1 again at http://isam8.webseal1.ibm.com. 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 a g e Test Case Number Test Description Test Steps Expected Behavior 5 Confirm the login policy 1. Set up a user who can only have 1 session. (pdadmin>policy set max-concurrentis used across data websessions 1 -user testuser) centers. The user is successfully logged in to the first instance, but cannot log in to second. 2. Log the user into a WebSEAL instance in the data center at http://isam8.webseal1.ibm.com . 3. Create a browser session. 4. Try to log in to the second WebSEAL instance in the data center at http://isam8.webseal2.ibm.com. Table 3 Testing Single Data Center 29 | P a g e 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. 4.1.1 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 a g e 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. 4.1.3 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: • http://www-‐ 01.ibm.com/support/knowledgecenter/SSPREK_8.0.0.2/com.ibm.amweb.doc_8.0.0.2/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 a g e 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 http://www-‐ 01.ibm.com/support/knowledgecenter/SSPREK_8.0.0.2/com.ibm.amweb.doc_8.0.0.2/admin/task/tsk_manage_ dsc.html?lang=en • Understand dscadmin commands options from the command-‐line interface http://www-‐ 01.ibm.com/support/knowledgecenter/SSPREK_8.0.0.2/com.ibm.amweb.doc_8.0.0.2/admin/concept/con_dsca dmin.html?lang=en 4.3.1 View sessions Use the dscadmin tool to list all the session management sessions in a specified replica set. Use the following syntax: 32 | P a g e 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 4.3.2 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 a g e 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. 4.4.1 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 = 7200. Therefore, this leaves 1800 sessions remaining. In the next 30 minutes, another 9000 are created, leaving 10800 total sessions remaining. Consequently, at any one time, ~ 11000 authenticated sessions remain in the Distributed Session Cache. 34 | P a g e 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 11000. 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 4096. 1. 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 a g e 3. Once you have completed the change, Click on Save, Deploy the changes, and Restart the instance. 4.4.3 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 a g e 5. Click Save, Deploy the changes, and Restart the instance. 4.4.4 Inactivity re-authentication When a user session times out due to inactivity, you can configure WebSEAL to remove the session from its local session store or retain the session until the session lifetime is reached. Retaining the session in the local session cache after an inactivity expiry event is useful for improving user experience during re-‐authentication. You can achieve it by using the reauth-for-inactive configuration settings under the [reauthenticate] stanza. By enabling this in a WebSEAL Reverse Proxy instance, it notifies the Distributed Session Cache with the time the session was last updated. The frequency at which WebSEAL client updates the session last access time at the Distributed Session Cache is defined by the dsess-last-access-update-interval configuration item. Consider the following example for this configuration: [session] inactive-timeout = 600 dsess-last-access-update-interval = 60 With these configuration values, a user's session can be flagged as inactive at the distributed session cache anywhere between 540 seconds and 600 seconds after the user's last access to the WebSEAL server. Enabling the reauth-for-inactive setting: • Increases the network traffic between a WebSEAL client and the Distributed Session Cache. • Further increases the memory usage of both the WebSEAL client and the Distributed Session Cache as sessions are stored for the entire lifetime of the session. • Results in the sessions not being removed on an idle time out event. 37 | P a g e Small values for the dsess-last-access-update-interval parameter can seriously impact WebSEAL server performance. Enable this feature only if it is a mandatory business requirement. To configure this inactivity re-‐authentication setting on the appliance: 1. Go to the Web Gateway Appliance. 2. Select Secure Web Settings > Manage Reverse Proxy. 3. Select a configured WebSEAL instance. 4. Click Manage > Configuration. 5. Select Edit Configuration File > Within the Advanced Configuration File Editor for the WebSEAL instance 6. Locate the [reauthenticate] stanza and edit the reauth-for-inactive 7. Click on Save, Deploy the changes, and Restart the instance. 38 | P a g e 5 Troubleshooting This section provides information about tools and options to help troubleshoot, isolate, and resolve problems in the IBM Security Access Manager appliance environment. • • Before in-‐depth troubleshooting, familiarize yourself with any known limitation or known issues and proposed solutions that were identified in the appliance product documentation. Some useful references include: -‐ Known issues and solutions -‐ Known limitations To help troubleshoot issues related to WebSEAL Reverse Proxy, consider the following: Inspect the WebSEAL logs by going to the Web Gateway Appliance > Secure Web Settings > Manage Reverse Proxy > Select a configured WebSEAL instance > Click Manage > Logging. Under the Manage Reverse Proxy Log Files window, you can view the log files and troubleshoot the issue. WebSEAL provides the following components to trace HTTP requests including pdweb.debug and pdweb.snoop. To enable these trace components, go to this link. • To troubleshoot issues related to Distributed Session Cache, consider the following information: -‐ Inspect WebSEAL Reverse Proxy logs to investigate whether WebSEAL is communicating with Distributed Session Cache. 39 | P a g e -‐ Inspect the Distributed Session Cache Log files on the Distributed Session Cache environment under Application Logs. To view these logs, go to Monitor Analysis and Diagnostics > Logs > Application Log Files. Under Application Log Files > expand dsc. • • As shown in the preceding screenshot, there is a list of dsc* related log files. These logs contain useful failover and reload notices along with error messages. You can either select the dscd.log file to inspect it in the local management interface console or export the logs. You can create a support file from the appliance to troubleshoot issues. IBM support uses support files to troubleshoot problems with the appliance. The support files contain all log files, temporary and intermediate files, and command output that is needed to diagnose customer support problems. The size of these files can grow large over time. To reduce the disk space that is occupied by these files, download unused support files to an external drive. Then, delete the support files from the appliance. For detailed instructions, see Managing support files. If you try a series of inspections and investigation without reaching a solution, contact IBM Support. Before contacting IBM Support, ensure your company or organization has an active IBM software subscription and support contract. You must be authorized to submit problems to IBM. For information about the types of available support, see the Support portfolio topic in the Software Support Handbook. 40 | P a g e Appendix A - Multiple Data Centers with session sharing The Distributed Session Cache can share sessions across multiple datacenters for disaster recovery scenarios. However, carefully consider implementing this solution since distributing sessions between geographically separated data centers: • Reduces the performance of the solution. • Increases management and monitoring overhead. • Increase the complexity of the solution. Weigh this solution against the limited benefits provided by a single session solution. Before configuring the clustered IBM Security Access Manager, Version 8.0, environment, you must configure IBM Security Access Manager, Version 8.0, policy server and user registry. • • A IBM Security Access Manager, Version 8.0, Web Gateway appliance is activated with the WGA license and set up with 4 WebSEAL instances. You must -‐ Activate WGA. -‐ Configure runtime component (LDAP and Policy Server). -‐ Configure Management and Application Interfaces as required. -‐ Configure 4 Reverse Proxy and modify to become forms based. 4 IBM Security Access Manager, Version 8.0, Web Gateway appliances were set up and used as the dedicated Distributed Session Cache cluster. 5.1.1 Creating a clustered IBM Security Access Manager 8 environment As mentioned before in Section 3.3, Configuring Distributed Session Cache, for Distributed Session Cache to address failover, you must configure multiple appliances into a cluster. The configuration in this section for multi-‐data center is further details in Section 5.1.1.2. 5.1.1.1 Activate the appropriate license on the appliances. Instructions on how to obtain and activate your license on the appliance can be found 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 5.1.1.2 Set up a cluster environment with the four appliances to be Distributed Session Cache dedicated server. This multi-‐data center environment includes the following: • Primary master -‐ dsc1.dc1-‐cluster.ibm.com (10.150.25.38) 41 | P a g e • • • • Secondary master -‐ dsc2.dc1-‐cluster.ibm.com (10.150.25.36) Third master -‐ dsc1.dc2-‐cluster.ibm.com (10.150.25.49) Fourth Master -‐ dsc2.dc2-‐cluster.ibm.com (10.150.25.47) 4 WebSEAL instances -‐ isam8-‐dsc-‐multicellwebseal1 (10.150.25.46) -‐ web-‐host-‐name = isam8-‐dsc-‐multicellwebseal1.ibm.com -‐ isam8-‐dsc-‐multicellwebseal2 (10.150.25.45) web-‐host-‐name = isam8-‐dsc-‐multicellwebseal2.ibm.com o isam8-‐dsc-‐multicellwebseal3 (10.150.25.44) web-‐host-‐name = isam8-‐dsc-‐multicellwebseal3.ibm.com o isam8-‐dsc-‐multicellwebseal4 (10.150.25.48) web-‐host-‐name = isam8-‐dsc-‐multicellwebseal4.ibm.com 1. Select one of the four dedicated IBM Security Access Manager 8 Distributed Session Cache appliances to be the primary master. In this example, the appliance on IP 10.150.25.38 is the primary master. In the local management interface console, go to Manage System Settings > Cluster Configuration: 2. Under the General tab, select Set this appliance as the primary master. 42 | P a g e 3. Under Primary Master, click on the dropdown box to select the IP address for this appliance, which is 10.150.25.38 in this example. 4. Save and deploy this update. Appliance on IP address 10.150.25.38 is now configured as the primary master of a cluster that can contain multiple nodes. 43 | P a g e 5. Return to the Overview tab. The Export button is enabled, and the Import button is disabled. 6. Export the cluster signature file from primary master. The cluster signature file contains configuration information that cluster members can use to identify and communicate with the primary master. 7. Save this configuration to a convenient location on your desktop or to any convenient location of your preference. 8. Go to the second appliance (http://10.150.25.36) and import this saved 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 44 | P a g e Settings > Cluster Configuration > Overview Tab > Import. 9. Browse to the signature output file and click join. On the new added appliance, the following nodes are under Cluster Configuration of the primary master local management interface console. 10. Update the cluster configuration on the primary master to promote the second appliance a secondary master. Return to the local management interface console of the Primary Master, go to Manage System Settings > Cluster Configurations > General tab. 45 | P a g e 11. Select the IP of the second appliance as the Secondary Master using the drop down box. 12. Define the Master External Reference Entity to a network reference point such as a router. In this example, use the IP router at 10.150.0.1 as the reference entity. 13. C lick Save. 14. Review and deploy these changes to the appliance. 15. Repeat steps [6] to [14] for the remaining two appliances to be dedicated Distributed Session Cache servers. At this point, you configured a clustered IBM Security Access Manager appliance environment with 2 master nodes and 2 non-‐master nodes. 46 | P a g e 16. Promote the last two appliances that were added to the cluster as the tertiary and quaternary masters of the cluster environment. To do this, go to primary master’s local management interface console > Manage System Settings > Cluster Configurations > General tab > Select the dropdown box under Tertiary Master and choose one of the non-‐master nodes IP address, which is 10.150.25.47. 17. Select the dropdown box under Quaternary Master and choose the final IP address of the non-‐master nodes. Choose 10.150.25.49. 18. Define the Replica External Reference Entity as a network reference point such as a router. Use the IP router at 10.150.0.1. 47 | P a g e 19. Click Save. 20. Review and deploy these changes to the appliance. At this point, you configured a clustered appliance environment with a primary master, a secondary master, a tertiary master, and a quaternary master node. At this point, you have a primary master (10.150.25.38) for the cluster, you must manage any further cluster configuration updates through the primary master local management interface console. 48 | P a g e 5.1.1.3 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 > Select Support internal and external clients. This indicates that both internal and external clients can utilize the Distributed Session Cache. Examples of external clients are web security servers, such as WebSEAL instances, that are located on an appliance other than the Distributed Session Cache cluster. 2. Assign a port number for external clients to communicate with the session cache. Use 9082 for this instance. This port is used in later steps during the WebSEAL Configurations phase. 3. Save and deploy these changes. Note: Update the Host file so that each node knows about 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. * Remember to manually assign the port. Do not use 9080, which is used by WebSphere Liberty, and causes the following error: Note: You can configure a maximum of 4 master for an appliance cluster. Nonetheless, it is possible to add more non-‐ master nodes to the cluster for future failover purposes. At this point, the IBM Security Access Manager 8 Distributed Session Cache cluster is set up. You can now configure the web security servers, that is WebSEAL, to utilize Distributed Session Cache. 5.1.2 Configuring the WebSEAL servers Configure the web security servers for the Distributed Session Cache in a cross data center environment where: • • Sessions are shared between the data centers. The web security servers in each data center must fail over to the next master node of the cluster if the preceding master node becomes unavailable. This section focuses on setting up external WebSEALs to utilize the Distributed Session Cache. A set of external WebSEAL instances on separate IP addresses have been configured. The WebSEAL appliance is not part of the Distributed Session Cache cluster environment. Follow these steps: 1. Configure each WebSEAL instance in data center 1 and data center 2 to use the Distributed Session Cache servers with the following configurations: o On the appliance hosting the WebSEAL instances, go to Secure Web Settings > Manage Reverse Proxy 49 | P a g e In this instance, there are four new reverse proxy instances that are configured. 2. In the Distributed Session Cache cluster through the Primary Masters local management interface console, select the Support internal and external clients with a port number assigned. Note: To configure SSL communication between the clients and Distributed Session Cache, see later section of this document. 3. 4. 5. 6. For each WebSEAL instance, enable a distributed session cache. On the WebSEAL appliance local management interface console, go to Secure Web Settings > Manage Reverse Proxy. Select the radio button for the WebSEAL Instance Select Edit under Session tab. Check the Enable Distributed Session Cache option. 7. Save and Deploy the settings. 50 | P a g e 8. Open the WebSEAL configuration file for isam8-‐dsc-‐multicellwebseal1. 9. Select isam8-‐dsc-‐multicellwebseal1 > Manage > Configuration > Edit Configuration File. 10. Configure each WebSEAL instance in data center 1 and data center 2 to use the Distributed Session Cache 11. 12. 13. 14. servers in Data Center 1 and only fail over to the data center 2 when required. Ensure the load priority is defined based on the ordering of the distributed session cache master server; allocated the highest priority to the primary master and the lowest priority to the quaternary master of the cluster. See the illustration at the end of these steps. Save and deploy changes. Repeat the same sets of steps from (3) to (6) for the remaining three (3) WebSEAL server with the same WebSEAL configuration details outlined in step f. NOT CORRECT Save and deploy changes. Restart all WebSEAL instances. [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-multicell-set1 [replica-sets] replica-set = default-multicell-set1 [dsess] dsess-sess-id-pool-size = 125 dsess-cluster-name = dsess [dsess-cluster] server = 9,http://10.150.25.38:9082/DSess/services/DSess server = 8,http://10.150.25.36:9082/DSess/services/DSess server = 7,http://10.150.25.47:9082/DSess/services/DSess server = 6,http://10.150.25.49:9082/DSess/services/DSess # # # # primary master secondary master tertiary master quaternary master response-by = 60 handle-pool-size = 10 51 | P a g e handle-idle-timeout = 240 timeout = 30 [session-cookie-domains] domain = ibm.com Now that you configured the web security servers to use the Distributed Session Cache servers in their own data centers, you can test the environment. 5.1.3 Testing the environment Use the following basic scenarios to test the environment. It is assumed that WebSEAL was configured for forms-‐based authentication to ensure pkmslogout can be used appropriately. Test Case Number Test Description 1 The user is not prompted to log in to WebSEAL2 1. Log in to WebSEAL1 in DC1. (http://isam8-‐dsc1-‐ SSO between WebSEALs in DC1. multicellwebseal1.ibm.com) in a single data center 2. Access WebSEAL2 in DC1. (http://isam8-‐dsc1-‐ You will see a session logged under Secure Web works. multicellwebseal2.ibm.com) Settings > Distributed Session Cache > Sessions. 2 The user is not prompted to log in to WebSEAL1 1. Log in to WebSEAL1 in DC1. (http://isam8-‐dsc1-‐ SSO between WebSEALs in DC2 multicellwebseal1.ibm.com) in different data centers 2. Access WebSEAL1 in DC2. (http://isam8-‐dsc2-‐ You will see a session logged under Secure Web works. multicellwebseal3.ibm.com ) Settings > Distributed Session Cache > Sessions.. 3 4 Logout between WebSEALs in a single data center works. DSC fail over in a data center. Test steps 1. Log in to WebSEAL1 in DC1. (http://isam8-‐dsc1-‐ multicellwebseal1.ibm.com) 2. Access WebSEAL2 in DC1 and log out. (http://isam8-‐dsc1-‐ multicellwebseal2.ibm.com/pkmslogout) 3. Access WebSEAL1 in DC1 again. (http://isam8-‐ dsc1-‐multicellwebseal1.ibm.com) 1. Stop the primary master in DC1. 2 . Repeat Test case 1 -‐3 . Expected Behaviour The user is prompted to log back in when re-‐ accessing WebSEAL1 in DC1. You will see no sessions logged under Secure Web Settings > Distributed Session Cache > Sessions. Monitor nodes status in the LMI console of the Secondary Master. You are expected to see a red cross under Accessible for the primary master in the nodes table. WebSEALs are expected to function as expected in test case 1 – 3. 5 DSC fail over between data centers. Monitor nodes status in the LMI console of the Tertiary Master. You are expected to see a red 1. Stop the primary master and secondary master cross under Accessible for the primary and in DC1.. secondary masters in the nodes table. 2. Repeat Test Case 1 – 3. WebSEALs are expected to function as expected in test case 1 – 3. 52 | P a g e Test Case Number Test Description 6 1. Set up a user who can only have 1 session. (pdadmin>policy set maxconcurrent-websessions 1 -user testuser) Confirm login policy is 2. Log the user into a WebSEAL instance in DC1. used across data centers. (http://isam8-‐dsc1-‐multicellwebseal1.ibm.com ) 3. Create a browser session. 4. Try to log in to a WebSEAL instance in DC2. (http://isam8-‐dsc2-‐multicellwebseal4.ibm.com) Test steps Expected Behaviour The user is successfully logged in to DC1, but is not be able to log in to DC2. 53 | P a g e Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-‐IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-‐1785 U.S.A. For license inquiries regarding double-‐byte character set (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 19-‐21, Nihonbashi-‐Hakozakicho, Chuo-‐ku Tokyo 103-‐8510, Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law : INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-‐ INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement might not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-‐IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation 2Z4A/101 11400 Burnet Road Austin, TX 78758 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases payment of a fee. 54 | P a g e The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-‐level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-‐IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-‐IBM products. Questions on the capabilities of non-‐IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. All IBM prices shown are IBM's suggested retail prices, are current and are subject to change without notice. Dealer prices may vary. This information is for planning purposes only. The information herein is subject to change before the products described become available. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows: © IBM 2014. Portions of this code are derived from IBM Corp. Sample Programs. © Copyright IBM Corp 2014. All rights reserved. If you are viewing this information in softcopy form, the photographs and color illustrations might not be displayed. 55 | P a g e Trademarks IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at ibm.com/legal/copytrade.shtml. Statement of Good Security Practices IT system security involves protecting systems and information through prevention, detection and response to improper access from in 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. 56 | P a g e © International Business Machines Corporation 2014 International Business Machines Corporation New Orchard Road Armonk, NY 10504 Produced in Australia 06-2014 All Rights Reserved References in this publication to IBM products and services do not imply that IBM intends to make them available in all countries in which IBM operates. 57 | P a g e