Enabling secure communication for a Tivoli Access Manager Session Management Server environment

Enabling secure communication for a Tivoli Access Manager Session Management Server environment Skill Level: Advanced Authors: Jenny Wong (jenwong@au1.ibm.com) Software Engineer IBM Tivoli Software Simon Stebbins (s.stebbins@au.ibm.com) Software Engineer IBM Tivoli Software Page 1

Table of Contents 1 About this tutorial...3 1.1 Prerequisites...3 1 Background Information...5 1.1 Introduction...5 1.2 Securing Communications...6 1.3 TCP level measures...8 1.4 TAM certificates...8 1.5 User registry...9 1.6 Authorization and Administration...10 1.6.1 Enabling pdadmin and pdsmsadmin to perform SMS administrative tasks...13 2 Enable security using TAM certificates between WebSEAL and SMS...15 2.1 Configuring SSL from SMS client...15 3.1.1 Enable TAM Integration in SMS...15 3.1.2 Changing the WebSphere SSL Configuration...18 3.1.3 Configuring the SMS Client...24 3.2 Enabling Authentication...25 3.2.1 (Optional) Define a valid server DN in the SMS client...26 3.2.2 Enable client authentication in DSessSSLConfig of the SMS Client...26 4 Enabling Authorization...27 4.1 Creating an administrative user...27 4.1.1 Enable administrative security in WebSphere Application Server...27 4.1.2 Configure security role membership for the SMS administrator...28 4.1.3 Configuration of Security Roles...30 5 Troubleshooting and Testing...35 5.1 Verify WebSEAL connected to SMS via HTTPS...35 5.2 Trace and logging...36 6 Other SMS Configurations...38 6.1 Recording Last Login Information...38 Resources...39 About the team who wrote this article...40 Page 2

1 About this tutorial This article provides specific guidance on how to step up a secure environment for the Tivoli Access Manager Session Management Server. It provides a summary of product pre-requisites, required background information, and describes how to achieve secure communication using certificates generated from a Tivoli Access Manger (TAM) infrastructure configured in both a stand-alone and clustered environment. Configuration instructions for using custom certificates are not covered in this article. 1.1 Prerequisites This article assumes, as a prerequisite, that the reader has a good knowledge and understanding of Tivoli Access Manager (TAM), WebSphere Application Server (WAS), Lightweight Access Directory Protocol (LDAP), and Secure Socket Layer (SSL). It is also assumed that the following products are already installed in the test environment: WebSphere Application Server 6.1 - with security disabled in a clustered or stand-alone environment A registry supported by Tivoli Access Manager for e-business 6.1 Global Security Toolkit (GSKit) ikeyman utility or equivalent Tivoli Access Manager for e-business 6.1including the following components o IBM Tivoli Access Manager Runtime o IBM Tivoli Access Manager Policy Server o IBM Tivoli Access Manager Authorization Server o IBM Tivoli Security Utilities o IBM Tivoli Access Manager Web Security Runtime o IBM Tivoli Access Manager Session Management Command Line o IBM Tivoli Access Manager Web Security ADK o Either IBM Tivoli Access Manager WebSEAL or Access Manger Plug-in for Web Servers o IBM Tivoli Access Manager Session Manager Server (SMS) configured to operate with the non-secure WAS server or cluster To demonstrate such a deployment, an example test environment was set up during the process of writing this tutorial. The example test environment is a clustered environment. The various product components were installed and configured in the following servers, where each has been assigned to these hosts: tam61.test.gc.au.ibm.com Policy server and Authorization server Page 3

ids61.test.gc.au.ibm.com LDAP User Registry nodeone.test.gc.au.ibm.com WebSphere Application Server where it includes a Deployment manager and node one (with SMS deployed to it). Node One is one of the members of the clustered environment nodetwo.test.gc.au.ibm.com Node Two (with SMS deployed to it) is a second member of the clustered environment webseal61.test.gc.au.ibm.com WebSEAL 6.1, a SMS client application Figure 1-1 presents an example environment of a clustered WebSphere Network Deployment with TAM 6.1 SMS configured: Figure 1-1 Example of a clustered lab environment Page 4

This article was written using Tivoli Access Manager 6.1. Since the time of writing this article, Tivoli Access Manager 6.1.1 has become available. The overall concept described in this article still applies with the newer version of the product. Although similar steps apply to the latest version of the product, there may be minor differences in the instructions when following this tutorial for newer versions. Please note that whenever changes are made in the WebSphere Application Server (WAS) environment, it is generally required to save the new configuration, synchronize the nodes (if using a cluster of servers), and then restart the WebSphere infrastructure. This will mean restarting the deployment manager and all node agents and servers in a clustered environment, or restarting the server when using a standalone system. The example in this article uses a WebSphere cluster, but most of the steps are similar (and simpler) for a standalone server. 1 Background Information 1.1 Introduction The introduction of the Session Management Server (SMS) in Tivoli Access Manager 6.1 brought new capabilities to the existing Tivoli Access Manager Web security servers, WebSEAL and the Plugin for Web Servers. In brief, it provides Centralized session management, giving an overview and control of all active sessions. Enforcement of limits on the number of concurrent sessions a user can have at one time. Failover between Web security servers without using the failover cookie. SMS increases the amount of security-related data transferred between components of the Tivoli Access Manager infrastructure during normal operation. With session data stored within a single server, network exchange of security data occurred only during authentication. The Web security server compares the password provided by the user with that stored in the user registry, and optionally retrieves additional information from the registry to store in the user's credential. When the Tivoli Access Manager environment includes SMS, a complete representation of the user's session is transmitted from the Web security server, authenticating the user to the SMS; and from there to any other Web security server instance processing a request from that user. The session information includes the session ID and any attributes extracted from the user registry in the user's credential. An intruder with the ability to capture data transiting between the Web security servers and SMS can hijack user sessions, and may have access to confidential user information. The session data also includes the active Tivoli Access Manager credential for the session, which the Web security servers use for authorization. If an intruder has the ability to modify the data in transit from SMS to a Web security server, or to issue requests directly to the SMS, they can effectively bypass any authorization performed by the Web security server; and may be able to impersonate any other user to applications protected by that Web security server. Page 5

In Tivoli Access Manager for e-business, the confidentiality and integrity measures offered to prevent the security issue describe above utilize Secure Sockets Layer (SSL) technology. All SMS traffic is sent as SOAP over Hypertext Transfer Protocol (HTTP), where SSL is well supported by the underlying WebSphere infrastructure. The following sections describe various considerations for ensuring complete security in the SMS environment. Later, detailed steps are provided that demonstrate the necessary steps to set up a secure connection between SMS and a Web security server known as WebSEAL. 1.2 Securing Communications The SMS introduces several new communication channels into the Web security system. As described earlier, several of these carry security-critical data, such as Web session IDs and credential data. Most of the traffic in these channels is SOAP over HTTP, which is not necessarily secure for transiting such sensitive and critical information. To help ensure such messages are transited securely and to achieve security goals include confidentiality, integrity and authentication, HTTP over SSL (HTTPS) with client certificates are used. The main communication channel is between the Web security servers (WebSEAL and Web plug-ins) and the WebSphere Application Server (WAS) instances hosting the SMS. Figure 2-1 illustrates a typical SMS-enabled TAM deployment to showcase where SSL technology is used to secure traffic requests between the involved TAM components and Web Security server instances, such as WebSEAL. Demilitarized Zone (DMZ) Load Balancer Junctioned Servers Junctioned Servers Junctioned Servers HTTPS (high volume SSL sessions) HTTPS HTTPS SSL Replica Set WebSphere Application Server Internet WebSEAL Replica set 1 SSL Session Management Server WebSEAL Replica set 2 SSL (TAM communications) TAM Policy Server TAM Registry Protocol Firewall Domain Firewall Figure 1-1 Securing communication in a SMS-enabled TAM environment by using SSL Page 6

Use of SSL for communication between the Web security servers and the SMS is controlled by: Web security server's configuration WAS Web container transport chain configuration At the TCP level, WebSphere Application Server can be configured to only accept connections from expected client hosts. To achieve this in WebSphere, this is done in the TCP configuration for the Web container transport chains. For best practice purposes, it is recommended to have a dedicated virtual host and transport chain for SMS communication, so you can make the security configuration as restrictive as possible. The SMS application can also be bound to a virtual host that only has host aliases for HTTPS ports. An alternative to this is to disable all Web container transport chains that do not use SSL. If the TAM environment is configured with Federal Information Processing Standard (FIPS) mode enabled, this must be extended to WAS as well, otherwise the SSL handshake will fail. Communication between the SMS administration interfaces and SMS itself operates in the same way as communication between the Web security servers and the SMS, where the same transport layer security measures apply. Remember that the connection, when using pdadmin to administer SMS, originates from the authorization server process hosting the SMS Command Line Interface (CLI), not from the pdadmin process. Likewise, the connection from the WebSphere Integrated Solutions Console (ISC) SMS portlet (hereafter called the SMS ISC) to the SMS application originates from the WebSphere application server. If the pdsmsadmin CLI command is configured and used, it talks directly to an SMS web service. Figure 2-2 illustrates the different communication paths taken by the two administrative interfaces when used to administer SMS. WebSphere Application Server pdsmsadmin Session Management Server Administrator pdadmin Policy Server Authorization Server Session Management Server ISC Figure 1-2 SMS administration interfaces to manage SMS Notice from the figure, when configured accordingly, pdsmsadmin communicates and administrates SMS directly, where as pdadmin administers SMS via a process from the authorization server to WAS. Of less concern is the communication between the SMS configuration program and the WAS administration service. When WAS global security is enabled, this communication is always done over Page 7

SSL. Unless WAS is configured to use a custom SSL configuration, this uses the dummy key file shipped with WAS. Any WAS that requires global security to be enabled should at least have a server certificate specifically created for that server for the WAS administration service. If SMS is configured to use a database to store last login or session data, the connection between SMS and the database should be considered. The universal Java Database Connectivity (JDBC) provider shipped with WebSphere Application Server does not encrypt data, check integrity, or authenticate the database server. Securing database connections is beyond the scope of this tutorial. Clustered SMS installs perform data replication using the WebSphere DCS communication protocol. This protocol operates over a variety of transports, including multicast UDP, TCP, and SSL. While the multicast UDP transport offers greater performance, it provides no security. To enable SSL for SMS data replication, select the DSessSSLConfig SSL configuration. We show you how to do this in later sections of this article. 1.3 TCP level measures Before configuring encryption and authentication, it's a good idea to look at the lower layers of the protocol stack. Physical (premises and network) security is outside the scope of this tutorial, but simple TCP level measures can be investigated that, while they do not provide any meaningful security, can protect against mis-configuration and help ensure that the components of the SMS environment are communicating as expected. WebSphere Application Server Web container transport chains can be configured to only accept connections from particular clients. Because no clients besides the Web security servers and SMS administration hosts should be connecting to WAS, the Web container transport chains should be configured to reject connections from anywhere other than the Web security servers and SMS administration hosts. 1.4 TAM certificates The process of configuring a system consisting of multiple different components to use SSL is relatively involved and complex, as it involves creating a new certificate system to allow each component to trust the certificates presented by the others. Internal communication between TAM servers is encrypted using SSL, and the certificates used to authenticate the connections are generated and signed by Access Manager itself. The policy server generates a new Certificate Authority (CA) certificate during its configuration. Configuration of a Web security server involves generation of a private key and a signing request. In order to get a certificate signed by the policy server, the request must be issued by an authorized user on the TAM /Management/Config object - usually sec_master. When a Web security server has a signed TAM certificate, it can authenticate to any other TAM server. These certificates are used to secure all Access Manager infrastructure communication; security policy distribution; secure all authentication and authorization activity for remote mode Access Manager applications; and administration commands issued through the SMS CLI utilities or SMS ISC. SMS traffic is simply another form of communication between components of the Tivoli Access Manager infrastructure; therefore it makes sense to protect it using the same certificate system. Page 8

If the WebSphere Application Server hosting the SMS is shared by other applications, you need to create separate virtual hosts and listening ports to allow each application to have its own SSL configuration. There are three steps to this process: 1. Create a new Web container transport chain. This allows the application server to receive requests on a new port, which can use a different SSL configuration to the existing ports. The transport chain configuration is located under Application servers server Web Container Settings Web container transport chains in the WebSphere administration console. Create a new transport chain based on the WebContainer-Secure template; assign it a name, port number, and port name. After you have saved the new transport chain, you can set the SSL configuration, and apply TCP access control measures as described earlier. 2. Create a new virtual host and host alias. This allows the application server to dispatch requests received on the new port to Web applications installed in the application server. The virtual host configuration is located under Environment Virtual Hosts in the WebSphere administration console. Create a new virtual host and assign it a name. After you have saved the new virtual host, you can create a new host alias for it, specifying the port number for the transport chain created in Step 1. 3. Map the SMS application to the new virtual host. This causes the application server to dispatch requests matching the new virtual host to the SMS application. The virtual host mapping for the SMS web application is located under Enterprise Applications DSess Virtual hosts in the WebSphere administration console. Select the new virtual host from the list and save the configuration changes. 1.5 User registry The recommended user registry configuration for WAS is to use the same user registry as TAM. The main benefit of this is that users of the SMS administration CLI or ISC will already be present in the registry. By using TAM-generated certificates to authenticate SMS clients, it also ensures that the principals corresponding to these certificates are also present in the registry. When using custom certificates for SMS authentication, the client certificates for each Web security server and each administration server must map to users in the registry. When using TAM certificates to authenticate SMS clients, the WAS registry Base distinguished name setting must be left blank. Otherwise, WAS is not able to authenticate users from both the LDAP suffix that stores regular users and the TAM secauthority=default suffix that stores the principals for TAM servers. The LDAP bind user must also have permission to read the secauthority=default suffix. Because these users are not authenticated using passwords, the bind user need not have permission to read the userpassword LDAP attribute in this suffix. As the TAM Runtime for Java registry configuration is separate to that of WAS itself, the WAS registry configuration does not affect the ability of the SMS to perform credential refresh operations and to record last login data for users. If the WAS and TAM registries are separate, credential refresh Page 9

and last login recording will still work. When using custom certificates, you may need to use a certificate mapping filter to allow WAS to find the user in the registry corresponding to the certificate. 1.6 Authorization and Administration When handling traffic and requests between WAS and SMS, it is not only important to achieve security goals such as confidentiality, authentication and integrity, but also authorization. By enforcing authorization, it ensures that only specific clients, administrators and delegators that have been authorized are able to use the SMS. For requests from Web security servers, SMS relies on regular J2EE authorization. Any client granted the sms-client role is authorized to create, manipulate, and destroy sessions stored in the SMS. In the TAM environment, the simplest way to configure this role is to map it to the pdwebpi-servers and webseal-servers TAM groups, of which Plug-in for Web Servers and WebSEAL server principals are members. The bulk of this tutorial covers the process of configuring the SMS clients to be able to authenticate to WebSphere using client certificates. The SMS administration interface, used to list and terminate sessions through pdadmin, employs a more complex authorization scheme, as the clients of this interface access it as proxies for the actual administrator, and do not have access to sufficient material (such as a password or client certificate) to authenticate to WebSphere as the administrator. The client authenticates itself using a client certificate, and provides the username of the administrator issuing the request. To account for this, the SMS first checks that the client is granted access to the sms-delegators role, which implies that it is trusted to pass on the name of the administrator. If the requesting client is authorized to a sms-delegators role, then it checks that the administrator supplied by the client is granted the sms-administrator role. We demonstrate how to configure and ensure the appropriate client grants and role mappings are achieve later in this article. Administrative tasks for session management server can be performed by any and all of the following administrative tools: pdadmin - command-line based extension utility to perform administration and management tasks for TAM components Figure 1-3 Using pdadmin as an administrative and management utility for SMS Page 10

pdsmsadmin command-line based administration utility specific for session management server purposes Figure 1-4 Using pdsmsadmin to administrator SMS Session Management Server ISC this is installed and deployed as an extension to the WebSphere ISC, where it is displayed as a portlet on the left-hand menu bar. Figure 1-5 Using SMS Integrated Solutions Console as a graphical user interface to administrator SMS The availability of these tools is dependent on the installed session management components in the environment. The following figure (Figure 2-6) illustrates an example structure of how the various administration interfaces for the session management server reside and interact. Page 11

Junctioned Servers Junctioned Servers Junctioned Servers Replica Set WebSEAL Replica set 1 WebSEAL Replica set 2 WebSphere Application Server Session Management Server Session Management Server ISC pdsmsadmin (direct SMS administration) TAM Authorization Server (SMS command line extension configured) TAM Authorization Server for credential refresh TAM Policy Server pdadmin (with SMS administration enabled) Firewall Figure 1-6 Architecture of Session Management Server Administration In order to employ and administrator SMS with commands in the either pdadmin or pdsmsadmin extension tools, the PDSMSCLI package needs to be installed. To use pdadmin to perform administrative tasks on SMS, it is necessary to install and configure the SMS Command Line Extension component on a system hosting a Tivoli Access Manager Authorization server. If using pdadmin to administer SMS, it is necessary to first run a utility called Access Manager Session Management Command Line Configuration tool, pdsmsclicfg, to configure pdadmin for SMS. The pdsmsclicfg tool is found in the %SMS_Installation_dir%/bin directory on the machine that will run the administration utility. Figure 2-7 presents a graphical user interface of the configuration tool: Page 12

Figure 1-7 Access Manager Session Management Command Line configuration There are also other methods to perform this configuration, though they are not covered in this tutorial. Refer to the TAM for e-business 6.1 Shared Session Management Administration Guide for further coverage on this. 1.6.1 Enabling pdadmin and pdsmsadmin to perform SMS administrative tasks To begin the configuration, specify whether to enable TAM integration or not. If set to no, pdadmin is not configured to perform SMS administrative tasks. If pdadmin is to be used with a secure connection, it is necessary to enable the TAM integration option and supply the path to the configuration file for the authorization server to be used as the delegate for SMS. A qualified name of the configuration file for the hosting authorization server is to be defined for the configuration command to write properties to. A local copy of this file should exist. Be sure to browse to the correct configuration file. The configuration process further requires the path to the client certificate, including the client key database (.kdb) and stash file (.sth) need to be specified (Figure 2-8). The client key database contains the certificate to be used and the stash file contains the password needed to access the certificate file. These can be the same set of files as those used for the SMS client if a TAM certificate is being used by the SMS server. Ensure that the client certificate is signed by a trusted CA that WebSphere recognizes to ensure that it trusts any administrative request invoked within pdadmin in the secure environment. For further information about configuring secure communications using certificates, refer to the TAM for e-business 6.1 Shared Session Management Administration Guide. The certificate specified in configuration can be anyone trusted by SMS if pdsmsadmin is to be used. Alternatively, if pdadmin is to be used, the certificate must be able to be mapped to a TAM principal by the TAI installed in the WebSphere server when SMS is configured. Usually this means the certificate created for the authorization server should be used when configuring SSL in the pdsmsclicfg utility. Page 13

Figure 1-8 Setting SSL and other properties in the pdsmsclicfg utility Once the necessary options and setting is completed, click on the Configure button to complete the configuration. The authorization server is to be restarted after using the configuration program. By contrast, pdsmsadmin does not require an authorization server as it communicates directly to WebSphere Application Server. This is shown in Figure 2-6. Only users who are assigned the smsadministrator role are able to perform any administrative tasks. Pdsmsadmin does not talk to an authorization server to determine if a user has the sms-administrator role; instead, it sends a request, contenting the login user name and password information, to ask SMS. SMS receives that request and verifies the user role privileges. If the login user is assigned with the appropriate administrator role, they have authority to perform any SMS administrative task; otherwise, if the user is not assigned with the sms-administrator role, an error message will be displayed to notify them that authority is not granted to perform the requested administrative operation. Later in this tutorial, in section Configure security role membership for the SMS administrator, it will demonstrate how users are assigned to the sms-administrator role. Page 14

2 Enable security using TAM certificates between WebSEAL and SMS The following provided details on how to achieve a secure environment configuration between a Web Security server instance (a SMS client), known as WebSEAL, and SMS. 2.1 Configuring SSL from SMS client To achieve secure communication between SMS clients and SMS server, the initial step is to establish a working secure connection between the SMS client, such as WebSEAL or the Plug-In for Web Servers, and the WebSphere Application Server environment it will be communicating with. There are three steps that need to be performed: 1 Enable TAM Integration in SMS 2 Changing the WebSphere SSL Configuration 3 Configuring the SMS Client 3.1.1 Enable TAM Integration in SMS TAM integration capability needs to be enabled for the deployed SMS instance to facilitate secure communications using TAM certificates. There is the option to enable this setting via the commandline SMS configuration utility or via the WebSphere ISC. In this article, we will demonstrate how to achieve this via the SMS command-line based configuration utility. When performing this configuration step, ensure to explicitly define the authorization server as one of the parameters. The following presents an example (Example 3-1) of stepping through this process. During this process, ensure to follow the prompts and define the correct values. C:\Program Files\Tivoli\PDSMS\bin>smscfg -action config -authzsvr john-w2k3.test.gc.au.ibm.com:7136:1 ------------------ WebSphere application server port: 8879 value (/h=help, /p=prev): ------------------ Secure connection to WebSphere application server: no value (/h=help, /p=prev): CTGSD0858I Attempting to establish a connection to the WebSphere Application Server. 28/07/2010 11:33:44 com.ibm.ws.management.connector.interop.jmxclassloader WARNING: Could not find tmx4jtransform.jar in C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01/etc/tmx4jTransform.jar - Interoperability to older versions of WebSphere is disabled 28/07/2010 11:33:45 com.ibm.ws.ssl.config.sslconfig WARNING: ssl.default.password.in.use.cwpki0041w 28/07/2010 11:33:45 com.ibm.ws.ssl.config.sslconfigmanager INFO: ssl.disable.url.hostname.verification.cwpki0027i ------------------ 1. Dsess value (/h=help, /p=prev): 1 Page 15

------------------ Session realm: 1. realm1:0=rs1 value (/h=help, /p=prev, /d<num>=delete): ------------------ Tivoli Common Directory enabled: no value (/h=help, /p=prev): ------------------ Integrate with Tivoli Access Manager: yes value (/h=help, /p=prev): ------------------ Policy server host name: john-w2k3.test.gc.au.ibm.com value (/h=help, /p=prev): ------------------ Policy server port: 7135 value (/h=help, /p=prev): ------------------ Tivoli Access Manager administrator ID: sec_master value (/h=help, /p=prev): ------------------ Tivoli Access Manager administrator password: value (/h=help, /p=prev): ------------------ Tivoli Access Manager domain: Default value (/h=help, /p=prev): ------------------ Credential refresh rules: value (/h=help, /p=prev, /d<num>=delete): ------------------ Enable storage of last login data: no value (/h=help, /p=prev): ------------------ Enable recording of audit records: no value (/h=help, /p=prev): ------------------ Client idle timeout (seconds): 600 value (/h=help, /p=prev): ------------------ Key lifetime (days): 186 value (/h=help, /p=prev): ------------------ Summary: WebSphere application server port: 8879 Secure connection to WebSphere application server: no SMS instance: Dsess Session realm: realm1:0=rs1 Tivoli Common Directory enabled: no Integrate with Tivoli Access Manager: yes Policy server host name: john-w2k3.test.gc.au.ibm.com Policy server port: 7135 Tivoli Access Manager administrator ID: sec_master Tivoli Access Manager administrator password: ******** Tivoli Access Manager domain: Default Credential refresh rules: Enable storage of last login data: no Enable recording of audit records: no Client idle timeout (seconds): 600 Key lifetime (days): 186 Page 16

Do you wish to continue (yes/no)? yes CTGSD0767I Configuring the Tivoli Access Manager session management server... Example 2-1 Configuring a deployed SMS instance via command-line The output messages for when the configuration of SMS is in place should look like the following in the command line: CTGSD0327I Configuration of the session management server on WebSphere:cell=nodeoneCell01,node=nodetwoNode01,process=nodetwoServer is complete. 2010-07-28 11:42:49.812+1000 [Dsess:nodetwoNode01/nodetwoServer] AMebUtils rununconfigure() CTGSM1350I Running the Tivoli Access Manager Runtime for Java configuration command, C:\Program Files\IBM\WebSphere\AppServer\java\jre\bin\java.exe com.tivoli.pd.jcfg.svrsslcfg -action unconfig - admin_id sec_master -admin_pwd ******** -appsvr_id SMS-Dsess-nodetwoNode01-nodetwoServer -domain Default -policysvr john-w2k3.test.gc.au.ibm.com:7135:1 -cfg_file \C:\Program Files\IBM\WebSphere\AppServer\profiles\Custom01\installedApps\nodeoneCell01\Dsess.ear\DSess.war\WEB- INF\nodetwoServer\pdjrtecfg.properties -host nodetwo.tam61.gc.au.ibm.com. 2010-07-28 11:42:57.812+1000 [Dsess:nodetwoNode01/nodetwoServer] AMJRTEConfigurator unconfigurekeyfiles() CTGSM1352I Deleting the SSL key files, C:\Program Files\IBM\WebSphere\AppServer\profiles\Custom01\etc\SMSKeyStore.jks and C:\Program Files\IBM\WebSphere\AppServer\profiles\Custom01\etc\SMSTrustStore.jks, created for Tivoli Access Manager certificate authentication. 2010-07-28 11:43:00.062+1000 [Dsess:nodetwoNode01/nodetwoServer] AMebUtils dopdjrtecfg() CTGSM1350I Running the Tivoli Access Manager Runtime for Java configuration command, C:\Program Files\IBM\WebSphere\AppServer\java\jre\bin\java.exe -Dpd.home=C:\Program Files\IBM\WebSphere\AppServer\java\jre\PolicyDirector com.tivoli.pd.jcfg.pdjrtecfg -action unconfig - java_home C:\Program Files\IBM\WebSphere\AppServer\java\jre -was. 2010-07-28 11:43:02.296+1000 [Dsess:nodetwoNode01/nodetwoServer] AMebUtils dopdjrtecfg() CTGSM1350I Running the Tivoli Access Manager Runtime for Java configuration command, C:\Program Files\IBM\WebSphere\AppServer\java\jre\bin\java.exe -Dpd.home=C:\Program Files\IBM\WebSphere\AppServer\java\jre\PolicyDirector com.tivoli.pd.jcfg.pdjrtecfg -action config - config_type full -java_home C:\Program Files\IBM\WebSphere\AppServer\java\jre -host johnw2k3.test.gc.au.ibm.com -was -port 7135 -domain Default. 2010-07-28 11:43:05.484+1000 [Dsess:nodetwoNode01/nodetwoServer] AMebUtils runconfigure() CTGSM1350I Running the Tivoli Access Manager Runtime for Java configuration command, C:\Program Files\IBM\WebSphere\AppServer\java\jre\bin\java.exe com.tivoli.pd.jcfg.svrsslcfg -action config - admin_id sec_master -admin_pwd ******** -appsvr_id SMS-Dsess-nodetwoNode01-nodetwoServer -port 7777 - mode remote -domain Default -policysvr john-w2k3.test.gc.au.ibm.com:7135:1 -authzsvr johnw2k3.test.gc.au.ibm.com:7136:1 -cfg_file \C:\Program Files\IBM\WebSphere\AppServer\profiles\Custom01\installedApps\nodeoneCell01\Dsess.ear\DSess.war\WEB- INF\nodetwoServer\pdjrtecfg.properties -key_file \C:\Program Files\IBM\WebSphere\AppServer\profiles\Custom01\installedApps\nodeoneCell01\Dsess.ear\DSess.war\WEB- INF\nodetwoServer\pdjrtecfg.jks -host nodetwo.tam61.gc.au.ibm.com. 2010-07-28 11:43:17.656+1000 [Dsess:nodetwoNode01/nodetwoServer] AMJRTEConfigurator configurekeyfiles() CTGSM1351I Creating SSL key files, C:\Program Files\IBM\WebSphere\AppServer\profiles\Custom01\etc\SMSKeyStore.jks and C:\Program Files\IBM\WebSphere\AppServer\profiles\Custom01\etc\SMSTrustStore.jks, for Tivoli Access Manager certificate authentication. CTGSD0327I Configuration of the session management server on WebSphere:cell=nodeoneCell01,node=nodeoneNode01,process=nodeoneServer is complete. 2010-07-28 11:42:48.656+1000 [Dsess:nodeoneNode01/nodeoneServer] AMebUtils rununconfigure() CTGSM1350I Running the Tivoli Access Manager Runtime for Java configuration command, C:\Program Files\IBM\WebSphere\AppServer\java\jre\bin\java.exe com.tivoli.pd.jcfg.svrsslcfg -action unconfig - admin_id sec_master -admin_pwd ******** -appsvr_id SMS-Dsess-nodeoneNode01-nodeoneServer -domain Default -policysvr john-w2k3.test.gc.au.ibm.com:7135:1 -cfg_file \C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\nodeoneCell01\Dsess.ear\DSess.war\WEB- INF\nodeoneServer\pdjrtecfg.properties -host nodeone.tam61.gc.au.ibm.com. 2010-07-28 11:42:56.312+1000 [Dsess:nodeoneNode01/nodeoneServer] AMJRTEConfigurator unconfigurekeyfiles() CTGSM1352I Deleting the SSL key files, C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\etc\SMSKeyStore.jks and C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\etc\SMSTrustStore.jks, created for Tivoli Access Manager certificate authentication. 2010-07-28 11:42:59.515+1000 [Dsess:nodeoneNode01/nodeoneServer] AMebUtils dopdjrtecfg() CTGSM1350I Running the Tivoli Access Manager Runtime for Java configuration command, C:\Program Files\IBM\WebSphere\AppServer\java\jre\bin\java.exe -Dpd.home=C:\Program Files\IBM\WebSphere\AppServer\java\jre\PolicyDirector com.tivoli.pd.jcfg.pdjrtecfg -action unconfig - java_home C:\Program Files\IBM\WebSphere\AppServer\java\jre -was. Page 17

2010-07-28 11:43:01.625+1000 [Dsess:nodeoneNode01/nodeoneServer] AMebUtils dopdjrtecfg() CTGSM1350I Running the Tivoli Access Manager Runtime for Java configuration command, C:\Program Files\IBM\WebSphere\AppServer\java\jre\bin\java.exe -Dpd.home=C:\Program Files\IBM\WebSphere\AppServer\java\jre\PolicyDirector com.tivoli.pd.jcfg.pdjrtecfg -action config - config_type full -java_home C:\Program Files\IBM\WebSphere\AppServer\java\jre -host johnw2k3.test.gc.au.ibm.com -was -port 7135 -domain Default. 2010-07-28 11:43:04.843+1000 [Dsess:nodeoneNode01/nodeoneServer] AMebUtils runconfigure() CTGSM1350I Running the Tivoli Access Manager Runtime for Java configuration command, C:\Program Files\IBM\WebSphere\AppServer\java\jre\bin\java.exe com.tivoli.pd.jcfg.svrsslcfg -action config - admin_id sec_master -admin_pwd ******** -appsvr_id SMS-Dsess-nodeoneNode01-nodeoneServer -port 7777 - mode remote -domain Default -policysvr john-w2k3.test.gc.au.ibm.com:7135:1 -authzsvr johnw2k3.test.gc.au.ibm.com:7136:1 -cfg_file \C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\nodeoneCell01\Dsess.ear\DSess.war\WEB- INF\nodeoneServer\pdjrtecfg.properties -key_file \C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\nodeoneCell01\Dsess.ear\DSess.war\WEB- INF\nodeoneServer\pdjrtecfg.jks -host nodeone.tam61.gc.au.ibm.com. 2010-07-28 11:43:17.953+1000 [Dsess:nodeoneNode01/nodeoneServer] AMJRTEConfigurator configurekeyfiles() CTGSM1351I Creating SSL key files, C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\etc\SMSKeyStore.jks and C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\etc\SMSTrustStore.jks, for Tivoli Access Manager certificate authentication. CTGSD0865I The SMS configuration action has completed successfully. Another way to check that the TAM integration has been enabled is to examine the set of trace files that the WebSphere Application Server produces. This will show that SSL key files are created for SMS to use. This can be verified in the SystemOut.log entries of the Deployment Manager. The messages presented above should also appear in the log files. 3.1.2 Changing the WebSphere SSL Configuration An SSL configuration is generated if TAM integration was enabled during the SMS configuration. It is necessary to choose this SSL configuration for the secured transport chain that the SMS application uses. By default, the secured transport chain is configured as WCInboundDefaultSecure. Consider the following outlined steps to achieve this SSL configuration: a) Select the Servers portlet, and then click on Application servers. This will present a list of application servers that have been configured in your environment. Page 18

Figure 2-1 Listing the Application Server configured in environment b) From the presented table, select the Application_server_name Web container settings Web container transport chains Figure 2-2 Web Container Settings c) Select the option WCInboundDefaultSecure SSL Inbound Channel (SSL_2) Page 19

Figure 2-3 Web container Transport Chains d) By default, under the SSL configuration section, the option Centrally managed is selected. Modify this setting by selecting Specific to this endpoint option. In the drop down menu, select the SSL configuration to be DSessSSLConfig. Figure 2-4 SSL Configuration After making the SSL configuration changes, the setting in the console should look like this: Page 20

Figure 2-5 SSL Configuration set to DSessSSLConfig e) Click Apply and then OK to enforce that new changes. If the clustered environment has more than one application server, repeat the same set of steps for each of the application server instances belonging to the cluster. f) In order to test (in a browser) that the WebSphere server is returning the correct server certificate, client authentication needs to be disabled. To achieve this, click on the Security portlet and select the SSL certificate and key management options. Under the Related Items section, select SSL configurations. Figure 2-6 SSL Configurations for Security g) Select the SSL configuration DSessSSLConfig, which was created for the SMS. Page 21

Figure 2-7 SSL certification and key management h) Under the Additional Properties section, click on Quality of protection (QoP) settings. Figure 2-8 SSL configuration for DSessSSLConfig i) Under the General Properties section, select None in the drop down menu located under Client authentication. When complete, click Apply and save the settings made to the master configuration. Page 22

Figure 2-9 Quality of protection (QoP) settings j) Save the workspace changes to the master configuration to update the master repository and synchronize the changes with the nodes if in a cluster environment. It is necessary to restart the entire WebSphere cluster for these changes to take effect. If using a stand-alone WebSphere server, simply restart it. Checkpoint 1: Examining the TAM certificates Since client authentication has been disabled in WebSphere, we can now check that WebSphere is presenting the correct certificate when a secure connection is requested. Hit the DSess web service directly by browsing to https://<was_server_name>:9443/dsess/services/dsess. Examine the certificate and expect to see that it is issued by the Policy Director certification authority (pdca). Figure 3-10 and 3-11 illustrate examples of certification information when attempting to contact the Dsess web service directly at https://nodeone:9443/dsess/services/dsess. Page 23

Figure 2-10 Examining that TAM Certificates is issued by the contacted Web Service instance Figure 2-11 Examining the Subject of the certificate to be from the Policy Director 3.1.3 Configuring the SMS Client This article uses WebSEAL as the SMS client. Similar steps need to be taken if using the Plug-in for Web Servers as the SMS client. It is assumed that a WebSEAL instance has been installed and configured to communicate with the SMS. During this stage, the WebSEAL instance is configured to use a secure connection with SMS. A secure connection is achieved by employing mutual Page 24

authentication between SMS and its client. In this example, we show how to do this using TAM certificates. WebSEAL needs to be provided the following information: The CA certificate used to sign the SMS SSL server certificate. The DN contained in the SMS server certificate. The path to the client certificate WebSEAL should use to authenticate to the SMS. When the [dsess-cluster] server stanza entry specifies the HTTPS protocol in the URL, you must configure WebSEAL for SSL communication with the SMS. Since SMS is configured for authentication using Tivoli Access Manager SSL certificates, the client certificate automatically generated for WebSEAL communication with the policy server can also be used for WebSEAL authentication to the SMS, without needing to import the Policy Server s signer certificate into SMS s key database. Likewise, the Policy Server s signer certificate does not need to be imported into WebSEAL s key database. However, if custom certificates are used, importing the relevant signer certificate into each key database would be necessary. The location of the default key database file is determined by the ssl-keyfile stanza entry in the [dsess-cluster] stanza of the WebSEAL configuration file. Also, the specified location of the key database stash file (containing password information for access to the database file) needs to be correctly configured for WebSEAL to open a secure connection. This is determined by the sslkeyfile-stash stanza entry in the [dsess-cluster] stanza. For example, the [ssl] stanza might look as follows: [ssl] ssl-keyfile = /var/pdweb/key-tab-default/default/webseald.kdb ssl-keyfile-stash = /var/pdweb/key-tab-default/default/webseald.sth ssl-keyfile-label = PD Server Since we are using TAM certificates to authenticate with SMS, the values of the ssl-keyfile and ssl-keyfile-stash stanza entries can be copied directly from the [ssl] stanza to the [dsesscluster] stanza in the WebSEAL configuration file. Note that the ssl-keyfile-label value to use is always PD Server. [dsess-cluster] ssl-keyfile = /var/pdweb/key-tab-default/default/webseald.kdb ssl-keyfile-stash = /var/pdweb/key-tab-default/default/webseald.sth ssl-keyfile-label = PD Server Once the configuration is complete, restart the WebSEAL instance. 3.2 Enabling Authentication The next section describes the steps on how to enable mutual authentication between the SMS client and the SMS Server Page 25

3.2.1 (Optional) Define a valid server DN in the SMS client It is a good idea to specify which certificate DN received by WebSEAL is acceptable. This configuration step is an optional setting and is not required to support secure communication between the WebSEAL instance and SMS. The certificate DN field can be set by including a value for the ssl-valid-server-dn entry within the [dsess-cluster] stanza. If no DN is specified, WebSEAL will accept any trusted certificate from SMS. If unsure what the DN is, set the entry to a test value and start WebSEAL. A message in the WebSEAL logs will show the certificate DN presented by SMS. 3.2.2 Enable client authentication in DSessSSLConfig of the SMS Client It is necessary to re-enable client authentication in WebSphere s SSL configuration. Select Security SSL certificate and key management SSL configurations DSessSSLConfig Quality of protection (QoP) settings in the WebSphere web-console. From earlier steps, you will have configured Client authentication set to be None in the drop down box. Change this setting to Required. Figure 2-12 Setting Client Authentication to be Required Restart the WebSphere application server/cluster for the changes to take effect. Check point 2: Client authentication should now be enabled When you try to access the DSess web service https://nodeone:9443/dsess/services/dsess in a browser it should now fail, because client authentication is being enforced. Page 26

4 Enabling Authorization This section describes how to enforce authorization at the WebSphere Application Server. By enforcing authorization, it will ensure that only specific or approved clients, administrators and delegators are able to make use of the SMS. There are three steps that need to be performed: 1. Creating an administrative user 2. Enable administrative security in WebSphere Application Server 3. Configure security role membership for the SMS administrator 4.1 Creating an administrative user It is necessary to create a new TAM user in LDAP as the SMS and WebSphere administrator. The purpose for setting up this TAM user in LDAP is so that the WebSphere server will be able to authenticate as. To create the new user, this can be achieved by using the TAM command-line utility, pdadmin. The following presents an example of creating a new user called wasadmin. pdadmin sec_master> user create wasadmin cn=wasadmin,o=ibm,c=au wasadmin wasadmin password pdadmin sec_master> user modify wasadmin account-valid yes 4.1.1 Enable administrative security in WebSphere Application Server By enabling administrative security in WebSphere, it secures the WebSphere Application Server and also allows us to configure necessary security roles for SMS. To turn on administrative security in WebSphere Application Server, configure the following steps: a) Go to click Security Secure administration, applications, and infrastructure. Check the Enable administrative security checkbox. Figure 4-1 Enabling Administrative security in WebSphere Page 27

b) Configure the user account repository. By default, the current realm definition is set to Local operating system. This needs to be modified so the TAM LDAP registry is used instead. Click on Configure with Standalone LDAP registry selected. Note: Base distinguished name should not be used because this will limit the users and groups that SMS will be able to use for roles. Figure 4-2 Configure to LDAP registry c) Click OK to return to the previous screen, set the LDAP registry as the current realm definition, and click on Apply to update the security configuration and save the changes. 4.1.2 Configure security role membership for the SMS administrator When WebSphere administration security is enabled, it allows you to set the security roles for SMS for ensuring that that only the appropriate clients will be allowed to be SMS administrators, clients, and delegators. The set of security roles are pre-defined and only accessible when administrative security is enabled. The roles are sms-administrator, sms-delegrator and sms-client. These roles are used specifically to authorize access to the various SMS operations which will be shown how later in this section. The SMS administrator must be configured to be a member of Administrator and sms-administrator roles to be able to serve SMS administrative purposes. Configure the following steps: a) To add these roles to a user, click on Administrative User Roles or Administrative Group Roles (if you wish to map the administrative roles to a group), then click on Add. Page 28

Figure 4-3 Mapping roles to WebSphere Administrative user b) Enter the administrative user id created in the previous section (in our case, this is wasadmin) and select both Administrator and sms-administrator from the list of roles. If this is not set properly, the WebSphere Administrative user, wasadmin, will not see the Tivoli SMS portlet in WebSphere ISC. Figure 4-4 Selecting roles to WebSphere Administrative user Page 29

Figure 4-5 Adding Administrator and sms-administrator roles to WebSphere administrative user c) Save the settings and restart the server/cluster. Once the restart is complete, administration security to the ISC should now be enforced. You will be presented with the WebSphere login form. You are required to log onto the ISC with the administration account created in the former steps. Figure 4-6 Login form of WebSphere when Administrative Security is enforced 4.1.3 Configuration of Security Roles In this section, we describe the steps for configuring the set to security roles for SMS. With this configuration in place, it will ensure that only the correct users or groups will be allowed to be the clients, delegators or administrators of SMS. To configure these roles, consider the following steps: a) Go to Applications Enterprise Applications Dsess in the WebSphere console. Page 30

Figure 4-7 Configuring Enterprise application DSess to security roles b) Click on Security role to user/group mapping. Figure 4-8 Security role to user/group mapping The following table will be displayed listing each role that is defined in the application and its mapping to users or groups from the domain user registry. At the moment, no users or groups are mapped to the roles. Page 31

Figure 4-9 Display of mappings between security roles and groups c) Check the role to be configured, and click on Look up users to map a user to the role or Look up groups to map a group to the role. The sms-administrators group defines who is allowed to administer SMS through the SMS portlet or pdsmsadmin command line. The sms-delegator group should be mapped to the group that defines the TAM authorization servers, so that pdadmin can be used to administer the SMS. The sms-client group should be mapped to the WebSEAL and/or WebPI servers group. The sms-administrator role needs to be mapped to cn=wasadmin,o=ibm, c=au so that the wasadmin user can administer SMS. The following screen shots demonstrate how each role should be configured. It is assumed that WebSphere Administrative user, wasadmin, has been added to a group called smsadmin-group. For the sms-administrator role: Figure 4-10 Mapping for sms-administrator role Page 32

For the sms-delegator role: Figure 4-11 Mapping for sms-delegator role For the sms-client role: Figure 4-12 Mapping for sms-client role d) Once complete, the table should look like the following: Page 33

Figure 4-13 A summary of all the groups mapped to roles e) Save the configuration changes. Page 34

5 Troubleshooting and Testing In this section, it provides information on how to test whether the secure communication between a SMS client, such as WebSEAL, and SMS is operating correctly. 5.1 Verify WebSEAL connected to SMS via HTTPS It should now be possible to login to WebSEAL using an authorized account. Figure 5-1 presents a WebSEAL instance configured to the SMS environment using https. Figure 5-1 Access Manager for e-business login form When presented with the Access Manager for e-business Login page, enter a set of valid credentials to authentication to the WebSEAL. If the authentication was successful, the browser will present the Tivoli Access Manager WebSEAL logo as shown below: Page 35

Figure 5-2 TAM WebSEAL logo presented on successful logon request 5.2 Trace and logging To ensure that SMS is configured correctly, turn on the trace component for SMS in the WebSphere console. To do this navigate to Troubleshooting Logs and Trace server name Change Log Detail Levels Runtime and add com.tivoli.am.sms.*=finest to the list of trace levels, and click on OK. Figure 5-3 Changing the logging level for WebSphere server instances Page 36

Once WebSEAL starts, something like the following message should be printed in trace.log, typically found in WebSphere_home/profiles/profile_name/logs/server_name on the file system. [4/08/10 09:30:26:734 EST] 0000003b AMebCertifica 1 com.tivoli.am.sms.tai.amebcertificatetai mapcertificate() Mapped TAM certificate subject "CN=default-webseald-win2k3se, OU=Default, O=Access Manager, C=US" to principal "cn=default-webseald/win2k3se,cn=securitydaemons,secauthority=default" When SMS is configured correctly, you will see the sessions displayed in the Tivoli SMS console as shown below: Figure 5-4 Display of logged in user session in SMS Page 37

6 Other SMS Configurations In the previous sections of this tutorial, it has provided the reader detailed steps on configuring a secure environment for SMS. Once a secure environment is in place, it is possible that the user may want to enable specific configuration settings in SMS. SMS offers a number of different configuration considerations to its users. To find out about the different configuration options that are available and supported, refer to the TAM for e-business 6.1 Shared Session Management Administration Guide. The configuration setting that this of interest is the enabling of last login recording in a secure SMS configuration environment. The following section discusses this. 6.1 Recording Last Login Information One of the configuration considerations that SMS offers is the option to record last login information when authenticating to SMS clients, such as a WebSEAL server. With this configuration option in place, it allows users to view the date and time of the last login (from the current browser). It also displays to users the number of failed login attempts since the last successful login session before the current login. To understand the steps required to enable last login information in SMS, refer to the TAM for e-business 6.1 Shared Session Management Administration Guide. Also, refer to the TAM for e-business 6.1WebSEAL Administration Guide for details on how to configure WebSEAL with last login enabled. Last login is not demonstrated in this tutorial. Nonetheless, it is important to note that if one were interested to configure last login information support for SMS in a secure environment, it requires configuring with a client certificate that is signed by a trusted CA in order to obtain the last login information for users. When enabling last login for WebSEAL, there is a step which involves specify the certificate database and key stash in the [junction] jct-cert-keyfile and jct-cert-keyfilestash entries. Ensure to specify the jct-cert-keyfile entry with the key database file employed in the ssl-keyfile stanza entry in the [dsess-cluster] stanza of the WebSEAL configuration file. Similarly, the location of the key database stash file needed to be specified in the jct-cert-keyfilestash should match the value of ssl-keyfile-stash configured for WebSEAL to open a secure connection. In earlier sections of this tutorial, it explained the purpose of these entries in the [dsesscluster] stanza for enabling secure communication for SMS. For example, the [junction] stanza might look as follows: jct-cert-keyfile = /var/pdweb/key-tab-default/default/webseald.kdb jct-cert-keyfile-stash = /var/pdweb/key-tab-default/default/webseald.sth Page 38

Resources The Tivoli Access Manager for e-business Information Center contains documentation for all TAMeb products including WebSEAL and SMS. See WebSphere Application Server V7 advanced security hardening, Part 1: Overview and approach to security hardening and WebSphere Application Server V7 advanced security hardening, Part 2: Advanced security considerations to learn how to harden WebSphere Application Server V6.1 or V7. These articles cover everything from network-based attacks to internal application-based attacks. Page 39

About the team who wrote this article Jenny Wong works as a Software Engineer for the Tivoli Security Solutions Team at the IBM ADL Gold Coast site in Australia. She works with Tivoli Security products in Level 3 Support, as well as pre-sales and post-sales engagements. Jenny holds a dual degree in Bachelor of Applied Mathematics and Information Technology. Since joining IBM in 2009 she has worked on various Tivoli Security products. Simon Stebbins is a software engineer at the Gold Coast ADL in Australia. He is a member of the Solutions team and mainly performs Level 3 support for customers of SMS and other Tivoli security products. He received degrees in Mathematics and Information Technology (Honours) from Queensland University of Technology, and has six years experience in IT research and software development Page 40