• No results found

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

N/A
N/A
Protected

Academic year: 2021

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

Copied!
40
0
0

Loading.... (view fulltext now)

Full text

(1)

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

(2)

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

(3)

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:

(4)

 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:

(5)

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

(6)

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.

Figure 1-1 Securing communication in a SMS-enabled TAM environment by using SSL

Internet Load Balancer Replica Set WebSEAL Replica set 1 WebSEAL Replica set 2

WebSphere Application Server

Session Management Server Junctioned Servers

Junctioned Servers Junctioned Servers

TAM Policy Server

(7)

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.

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

(8)

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

(9)

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.

(10)

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

(11)

 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

(12)

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:

Replica Set WebSEAL Replica set 1 WebSEAL Replica set 2

WebSphere Application Server

Session Management Server Junctioned Servers Junctioned Servers Junctioned Servers TAM Authorization Server (SMS command line extension configured) Firewall Session Management Server ISC TAM Authorization Server for credential

(13)

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.

(14)

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 sms-administrator 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

(15)

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 command-line 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

(16)

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

(17)

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

john-w2k3.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 SMSDsessnodetwoNode01nodetwoServer port 7777 -mode remote -domain Default -policysvr w2k3.test.gc.au.ibm.com:7135:1 -authzsvr

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

(18)

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

john-w2k3.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 SMSDsessnodeoneNode01nodeoneServer port 7777 -mode remote -domain Default -policysvr w2k3.test.gc.au.ibm.com:7135:1 -authzsvr

john-w2k3.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:

(19)

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

(20)

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

(21)

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

(22)

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

(23)

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

(24)

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

(25)

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 ssl-keyfile-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 [dsess-cluster] 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

(26)

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

(27)

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.

(28)

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:

(29)

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.

(30)

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

(31)

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

(32)

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

sms-admin-group.

For the sms-administrator role:

(33)

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

(34)

Figure 4-13 A summary of all the groups mapped to roles

(35)

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

(36)

Figure 5-2 TAM WebSEAL logo presented on successful logon request

5.2 Trace and logging

(37)

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:

(38)

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-keyfile-stash 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-keyfile-stash 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 [dsess-cluster] stanza for enabling secure communication for SMS.

For example, the [junction] stanza might look as follows:

(39)

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

(40)

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

References

Related documents

IBM Tivoli Access Manager for e-business and IBM Tivoli Privacy Manager for e-business let organizations manage users and data access to implement and enforce privacy policies

To backup DB2 databases using Tivoli Storage Manager, you must register a node on the Tivoli Storage Manager server, install the Tivoli Storage Manager API, define

LAN SAN 1 2 LAN-free Data Movement Tivoli Storage Manager Server Library Manager Data Owner Tivoli Storage Manager Client Storage Agent Library Client Changer Control Changer

The validation data at such times reflected two distinct travel time patterns in which a portion of traffic moved at a slower speed than the rest of the traffic flow. See Figure 4

Actually, Interim Administrator has to submit report to the Tribunal and the Tribunal after considering report of the Interim Administrator and after being satisfied that

[r]

applied to the surface of freshly placed concrete to produce some special result.

The main objective of this project is to make a C++ program which maintains a person’s account in a bank and provide ease of service to the user.. char type;