Am611 Sms Admin

Tivoli Access Manager for e-business
Version 6.1.1
Shared Session Management Administration Guide
SC23-6509-01
Tivoli Access Manager for e-business
Version 6.1.1
SC23-6509-01
Note Before using this information and the product it supports, read the information in Appendix D, Notices, on page 101.
Edition notice This edition applies to version 6, release 1, modification 1 of IBM Tivoli Access Manager (product number 5724-C87) and to all subsequent releases and modifications until otherwise indicated in new editions. All rights reserved. Copyright IBM Corporation 2005, 2010. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
About this publication . . . . . . . . v
Adding a new member to an SMS cluster . . . . 26 Intended audience . . . . . . . . . . . . v Publications . . . . . . . . . . . . . . v IBM Tivoli Access Manager for e-business library vi Related products and publications. . . . . . vii Accessing terminology online . . . . . . . viii Accessing publications online . . . . . . . viii Ordering publications . . . . . . . . . . ix Accessibility . . . . . . . . . . . . . . ix Tivoli technical training . . . . . . . . . . ix Tivoli user groups . . . . . . . . . . . . x Support information . . . . . . . . . . . . x Conventions used in this publication . . . . . . x Typeface conventions . . . . . . . . . . x Operating system-dependent variables and paths xi
Chapter 3. Using the session management server . . . . . . . . . 27

Searching user sessions . . . . . . Ending user sessions . . . . . . . Setting the maximum concurrent sessions Displaying session realms and replica sets Managing replica sets and realms . . . Managing keys . . . . . . . . . Session management server statistics . . Tracking login activity . . . . . . . Storing the login activity data . . . Creating the login activity database . Setting rules for credential refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 28 28 29 29 30 30 31 31 32 32
Chapter 1. Introduction . . . . . . . . 1
Session management server administration options . 1 Session management server features . . . . . . 2 Session information consistency . . . . . . . 3 Cluster-wide login policy enforcement . . . . . 3 Failover . . . . . . . . . . . . . . . 3 Session information management . . . . . . 3 Support for multiple instances . . . . . . . 3 Limited session realms . . . . . . . . . . 4 Session management server architecture . . . . . 4 Deployment considerations . . . . . . . . . 6 Security considerations . . . . . . . . . . . 9 Configuring secure communications . . . . . 9 Configuring secure communications between the WebSphere Web server plug-in and the WebSphere server . . . . . . . . . . . 10 Configuring session management server authorization . . . . . . . . . . . . . 11 Configuring security role membership for SMS administrator . . . . . . . . . . . . . 13 WebSEAL and Plug-in for Web Servers configuration . . . . . . . . . . . . . . 14 Single sign-on with the session management server 14 Back-end storage mechanisms . . . . . . . . 15 Single server . . . . . . . . . . . . . 15 Clustered server . . . . . . . . . . . . 16
Chapter 4. Session management server best practices. . . . . . . . . . . . 35

Zone rules and zone configuration. . . . . . . Zone configuration . . . . . . . . . . . Zone rule . . . . . . . . . . . . . . WebSphere eXtreme Scale zones . . . . . . Load balancer settings . . . . . . . . . . . SMS sessions and session limit policy . . . . . Session limit policy . . . . . . . . . . . Number of concurrent sessions . . . . . . . Session cache size . . . . . . . . . . . Tuning the Java Virtual Machine . . . . . . . WebSphere Application Server Heap Size . . . WebSphere Application Server Deployment Manager Heap Size. . . . . . . . . . . WebSphere Application Server Node Agent Heap Size . . . . . . . . . . . . . . . . 32-bit and 64-bit considerations . . . . . . . Configuring the Object Request Broker . . . . Session Management Server High Availability Considerations . . . . . . . . . . . . . Hard failure detection . . . . . . . . . . eXtreme Scale container JVMs . . . . . . . Container failure . . . . . . . . . . . eXtreme Scale Catalog service . . . . . . . Running catalog servers inside WebSphere Application Server JVM processes . . . . . . Running catalog servers inside stand-alone JVMs Catalog service failure . . . . . . . . . . Catalog service quorum behavior . . . . . . Failure scenarios. . . . . . . . . . . . Recovery procedures . . . . . . . . . . 35 35 35 35 36 37 37 37 37 38 38 38 39 39 39 39 40 40 41 41 41 42 43 43 45 47
Chapter 2. Configuration . . . . . . . 17
Installing the session management server . . Installing Fixpack upgrades . . . . . . Deploying the session management server . . Configuring the session management server . Gathering configuration details . . . . . Running the configuration utility . . . . Configuring the command line extensions . . Which command line to use? . . . . . Other considerations . . . . . . . . Unconfiguring the session management server Deploying and configuring additional instances
Copyright IBM Corp. 2005, 2010
. . . . . . . . . . .
. . . . . . . . . . .
17 18 18 19 20 23 23 23 23 24 24
Appendix A. SMS pdsmsadmin and pdadmin commands . . . . . . . . . 49

Reading syntax statements . login . . . . . . . . set instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 . 50 . 51
iii
instances list . . . . . . server list . . . . . . . key change . . . . . . key show . . . . . . . realm list . . . . . . . realm show . . . . . . session refresh all_sessions . session refresh session . . . replica set list. . . . . . replica set show . . . . . session list. . . . . . . session terminate all_sessions session terminate session . . trace get . . . . . . . trace set . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
52 53 54 56 58 60 62 64 66 68 70 72 74 76 78
Appendix C. Support information . . . 95

Searching knowledge bases . . . . . . . . Searching information centers . . . . . . Searching the Internet . . . . . . . . . Obtaining fixes . . . . . . . . . . . . Registering with IBM Software Support . . . . Receiving weekly software updates . . . . . Contacting IBM Software Support . . . . . . Determining the business impact . . . . . Describing problems and gathering information Submitting problems . . . . . . . . . . . . . . . . . 95 95 95 95 96 96 97 97 98 . 98
Appendix D. Notices . . . . . . . . 101

Trademarks . . . . . . . . . . . . . . 103
Appendix B. SMS utilities. . . . . . . 81

pdsmsclicfg . smsbackup . smscfg . . . smsservicelevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 85 87 94
Glossary . . . . . . . . . . . . . 105 Index . . . . . . . . . . . . . . . 115
iv
About this publication

IBM Tivoli Access Manager for e-business session management server (SMS) manages sessions across clustered Tivoli Access Manager security servers. Implemented as a WebSphere Application Server service, the session management server permits the sharing of session information and provides a user interface from which authorized persons can administer and monitor user sessions. IBM Tivoli Access Manager for e-business provides an access control management solution to centralize network and application security policy for e-business applications. For details about supported platforms, disk and memory requirements, see the IBM Tivoli Access Manager for e-business: Release Notes. For details about software prerequisites and installation and initial configuration of the session management server components, see the IBM Tivoli Access Manager for e-business: Installation Guide. For technical reference information, deployment considerations, and usage information for the session management server with Tivoli Access Manager Plug-in for Web Servers, see the IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Administration Guide. For technical reference information, deployment considerations, and usage information for the session management server with Tivoli Access Manager WebSEAL, see the IBM Tivoli Access Manager for e-business: WebSEAL Administration Guide.
Intended audience
This guide is for system administrators responsible for the deployment and administration of the Tivoli Access Manager session management server. Readers should be familiar with the following: v Microsoft Windows and UNIX operating systems. v Database architecture and concepts. v Security management. v Internet protocols, including HTTP, HTTPS and TCP/IP. v WebSphere Application Server administration. v Authentication and authorization. If you are enabling Secure Sockets Layer (SSL) communication, you also should be familiar with SSL protocol, key exchange (public and private), digital signatures, cryptographic algorithms, and certificate authorities.
Publications
This section lists publications in the IBM Tivoli Access Manager for e-business library and related documents. The section also describes how to access Tivoli publications online and how to order Tivoli publications.
IBM Tivoli Access Manager for e-business library

The following documents are in the Tivoli Access Manager for e-business library: v IBM Tivoli Access Manager for e-business: Quick Start Guide, GI11-9333 Provides steps that summarize major installation and configuration tasks. v IBM Tivoli Access Manager for e-business: Release Notes, GC23-6501 Provides information about installing and getting started, system requirements, and known installation and configuration problems. v IBM Tivoli Access Manager for e-business: Installation Guide, GC23-6502 Explains how to install and configure Tivoli Access Manager for e-business. v IBM Tivoli Access Manager for e-business: Upgrade Guide, SC23-6503 Upgrade from version 5.0, 6.0, or 6.1 to version 6.1.1. v IBM Tivoli Access Manager for e-business: Administration Guide, SC23-6504 Describes the concepts and procedures for using Tivoli Access Manager. Provides instructions for performing tasks from the Web Portal Manager interface and by using the pdadmin utility. v IBM Tivoli Access Manager for e-business: WebSEAL Administration Guide, SC23-6505 Provides background material, administrative procedures, and reference information for using WebSEAL to manage the resources of your secure Web domain. v IBM Tivoli Access Manager for e-business: Plug-in for Edge Server Administration Guide, SC23-6506 Provides instructions for integrating Tivoli Access Manager with the IBM WebSphere Edge Server application. v IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Administration Guide, SC23-6507 Provides procedures and reference information for securing your Web domain using a Web server plug-in. v IBM Tivoli Access Manager for e-business: Shared Session Management Administration Guide, SC23-6509 Provides deployment considerations and operational instructions for the session management server. v IBM Global Security Kit: Secure Sockets Layer Introduction and iKeyman User's Guide, SC23-6510 Provides information for enabling SSL communication in the Tivoli Access Manager environment. v IBM Tivoli Access Manager for e-business: Auditing Guide, SC23-6511 Provides information about configuring and managing audit events using the native Tivoli Access Manager approach and the Common Auditing and Reporting Service. You can also find information about installing and configuring the Common Auditing and Reporting Service. Use this service for generating and viewing operational reports. v IBM Tivoli Access Manager for e-business: Command Reference, SC23-6512 Provides reference information about the commands, utilities, and scripts that are provided with Tivoli Access Manager. v IBM Tivoli Access Manager for e-business: Administration C API Developer Reference, SC23-6513
vi
Provides reference information about using the C language implementation of the administration API to enable an application to perform Tivoli Access Manager administration tasks. v IBM Tivoli Access Manager for e-business: Administration Java Classes Developer Reference, SC23-6514 Provides reference information about using the Java language implementation of the administration API to enable an application to perform Tivoli Access Manager administration tasks. v IBM Tivoli Access Manager for e-business: Authorization C API Developer Reference, SC23-6515 Provides reference information about using the C language implementation of the authorization API to enable an application to use Tivoli Access Manager security. v IBM Tivoli Access Manager for e-business: Authorization Java Classes Developer Reference, SC23-6516 Provides reference information about using the Java language implementation of the authorization API to enable an application to use Tivoli Access Manager security. v IBM Tivoli Access Manager for e-business: Web Security Developer Reference, SC23-6517 Provides programming and reference information for developing authentication modules. v IBM Tivoli Access Manager for e-business: Error Message Reference, GI11-8157 Provides explanations and recommended actions for the messages and return code. v IBM Tivoli Access Manager for e-business: Troubleshooting Guide, GC27-2717 Provides problem determination information. v IBM Tivoli Access Manager for e-business: Performance Tuning Guide, SC23-6518 Provides performance tuning information for an environment consisting of Tivoli Access Manager with the IBM Tivoli Directory Server as the user registry.
Related products and publications

This section lists the IBM products that are related to and included with a Tivoli Access Manager solution.
IBM Global Security Kit

Tivoli Access Manager provides data encryption through the use of the Global Security Kit (GSKit), version 7.0. GSKit is included on the IBM Tivoli Access Manager Base CD for your particular platform, as well as on the IBM Tivoli Access Manager Web Security CDs, the IBM Tivoli Access Manager Shared Session Management CDs, and the IBM Tivoli Access Manager Directory Server CDs. The GSKit package provides the iKeyman key management utility, gsk7ikm, which creates key databases, public-private key pairs, and certificate requests. The IBM Global Security Kit: Secure Sockets Layer Introduction and iKeyman User's Guide is available on the Tivoli Information Center Web site in the same section as the Tivoli Access Manager product documentation.
IBM Tivoli Directory Server

IBM Tivoli Directory Server, version 6.1, is included on the IBM Tivoli Access Manager Directory Server set of CDs for the required operating system.
vii
You can find additional information about Tivoli Directory Server at: http://www.ibm.com/software/tivoli/products/directory-server/
IBM Tivoli Directory Integrator

IBM Tivoli Directory Integrator, version 6.1.1, is included on the IBM Tivoli Directory Integrator CD for the required operating system. You can find additional information about IBM Tivoli Directory Integrator at: http://www-306.ibm.com/software/tivoli/products/directory-integrator/
IBM DB2 Universal Database

IBM DB2 Universal Database Enterprise Server Edition, version 9.1, is provided on the IBM Tivoli Access Manager Directory Server set of CDs and is installed with the Tivoli Directory Server software. DB2 is required when using Tivoli Directory Server or z/OS LDAP servers as the user registry for Tivoli Access Manager. For z/OS LDAP servers, you must separately purchase DB2. You can find additional information about DB2 at: http://www.ibm.com/software/data/db2
IBM WebSphere Application Server

WebSphere Application Server, version 6.1, is included on the IBM Tivoli Access Manager WebSphere Application Server set of CDs for the required operating system. WebSphere Application Server enables the support of the following applications: v Web Portal Manager interface, which administers Tivoli Access Manager. v Web Administration Tool, which administers Tivoli Directory Server. v Common Auditing and Reporting Service, which processes and reports on audit events. v Session management server, which manages shared session in a Web security server environment. v Attribute Retrieval Service. You can find additional information about WebSphere Application Server at: http://www.ibm.com/software/webservers/appserv/infocenter.html
Accessing terminology online

The Tivoli Software Glossary includes definitions for many of the technical terms related to Tivoli software. The Tivoli Software Glossary is available at the following Tivoli software library Web site: http://publib.boulder.ibm.com/tividd/glossary/tivoliglossarymst.htm The IBM Terminology Web site consolidates the terminology from IBM product libraries in one convenient location. You can access the Terminology Web site at http://www.ibm.com/software/globalization/terminology .
Accessing publications online

The documentation CD contains the publications that are in the product library. The format of the publications is PDF, HTML, or both. Refer to the readme file on the CD for instructions on how to access the documentation.
viii
The product CD contains the publications that are in the product library. The format of the publications is PDF, HTML, or both. To access the publications using a Web browser, open the infocenter.html file. The file is in the appropriate publications directory on the product CD. IBM posts publications for this and all other Tivoli products, as they become available and whenever they are updated, to the Tivoli Documentation Central Web site at http://www.ibm.com/tivoli/documentation. Note: If you print PDF documents on other than letter-sized paper, set the option in the File Print window that allows Adobe Reader to print letter-sized pages on your local paper.
Ordering publications
You can order many Tivoli publications online at http:// www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss. You can also order by telephone by calling one of these numbers: v In the United States: 800-879-2755 v In Canada: 800-426-4968 In other countries, contact your software account representative to order Tivoli publications. To locate the telephone number of your local representative, perform the following steps: 1. Go to http://www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss. 2. Select your country from the list and click Go. 3. Click About this site in the main panel to see an information page that includes the telephone number of your local representative.
Accessibility
Accessibility features help users with a physical disability, such as restricted mobility or limited vision, to use software products successfully. With this product, you can use assistive technologies to hear and navigate the interface. You can also use the keyboard instead of the mouse to operate all features of the graphical user interface. Visit the IBM Accessibility Center at http://www.ibm.com/alphaworks/topics/ accessibility/ for more information about IBM's commitment to accessibility. For additional information, see the Accessibility Appendix in IBM Tivoli Access Manager for e-business: Installation Guide.
Tivoli technical training

For Tivoli technical training information, refer to the following IBM Tivoli Education Web site at http://www.ibm.com/software/tivoli/education.
ix
Tivoli user groups

Tivoli user groups are independent, user-run membership organizations that provide Tivoli users with information to assist them in the implementation of Tivoli Software solutions. Through these groups, members can share information and learn from the knowledge and experience of other Tivoli users. Tivoli user groups include the following members and groups: v 23,000+ members v 144+ groups Access the link for the Tivoli Users Group at http://www.tivoli-ug.org/.
Support information
If you have a problem with your IBM software, you want to resolve it quickly. IBM provides the following ways for you to obtain the support you need: Online Access the Tivoli Software Support site at http://www.ibm.com/software/ sysmgmt/products/support/index.html?ibmprd=tivman. Access the IBM Software Support site at http://www.ibm.com/software/support/ probsub.html . IBM Support Assistant The IBM Support Assistant is a free local software serviceability workbench that helps you resolve questions and problems with IBM software products. The Support Assistant provides quick access to support-related information and serviceability tools for problem determination. To install the Support Assistant software, go to http://www.ibm.com/software/ support/isa. Troubleshooting Guide For more information about resolving problems, see the IBM Tivoli Access Manager for e-business: Installation Guide.
Conventions used in this publication

This publication uses several conventions for special terms and actions, operating system-dependent commands, and paths.
Typeface conventions
This publication uses the following typeface conventions: Bold v Lowercase commands and mixed case commands that are otherwise difficult to distinguish from surrounding text v Interface controls (check boxes, push buttons, radio buttons, spin buttons, fields, folders, icons, list boxes, items inside list boxes, multicolumn lists, containers, menu choices, menu names, tabs, property sheets), labels (such as Tip:, and Operating system considerations:) v Keywords and parameters in text Italic v Citations (examples: titles of publications, diskettes, and CDs v Words defined in text (example: a nonswitched line is called a point-to-point line)
v Emphasis of words and letters (words as words example: "Use the word that to introduce a restrictive clause."; letters as letters example: "The LUN address must start with the letter L.") v New terms in text (except in a definition list): a view is a frame in a workspace that contains data. v Variables and values you must provide: ... where myname represents.... Monospace v Examples and code examples v File names, programming keywords, and other elements that are difficult to distinguish from surrounding text v Message text and prompts addressed to the user v Text that the user must type v Values for arguments or command options
Operating system-dependent variables and paths

This publication uses the UNIX convention for specifying environment variables and for directory notation. When using the Windows command line, replace $variable with % variable% for environment variables and replace each forward slash (/) with a backslash (\) in directory paths. The names of environment variables are not always the same in the Windows and UNIX environments. For example, %TEMP% in Windows environments is equivalent to $TMPDIR in UNIX environments. Note: If you are using the bash shell on a Windows system, you can use the UNIX conventions.
xi
xii
Chapter 1. Introduction
The session management server is an optional Tivoli Access Manager component that runs as a WebSphere service. It manages user sessions across Tivoli Access Manager servers, ensures that the session state remains consistent across the participating servers, and allows for the implementation of session policy across the participating servers. The session management server allows Tivoli Access Manager WebSEAL and the Tivoli Access Manager Plug-in for Web Servers to share a unified view of all current sessions, and permits authorized users to monitor and administer user sessions. The session management server also makes available session statistics, provides secure and high-performance failover, and provides single sign-on capabilities for clustered environments. Designed to manage sessions across clustered Web server environments, the session management server can adapt to complicated deployment architectures. The session management server is a J2EE application that runs on the WebSphere server, or within a WebSphere cluster.
Session management server administration options

Sessions can be administered using any (or all) of the following tools: pdadmin Details of pdadmin commands that can be used for session management are described in Appendix A, SMS pdsmsadmin and pdadmin commands, on page 49. pdsmsadmin The pdsmsadmin command line uses the SOAP protocol to communicate directly with a session management server installed on WebSphere Application Server. The session management server Integrated Solutions Console The session management server Integrated Solutions Console (hereafter referred to as the ISC) is a graphical user interface that resides on the WebSphere Application Server, and is installed as an extension to the WebSphere ISC. Figure 1 on page 2 shows the extended main menu items.
Figure 1. Integrated Solutions Console session management server extension menu
For further details of specific administration tasks, see Chapter 3, Using the session management server, on page 27. Additional administrative tasks are performed using the session management server utilities described in Appendix B, SMS utilities, on page 81. When deciding which administration options are best suited to your session management server environment, see Deployment considerations on page 6.
Session management server features

Session management server functions generally require initial configuration, and minimal user intervention thereafter.
Session information consistency

The session management server is a centralized Web service that maintains session information across Web security servers. Session data includes user credentials, session timeout information, and other data used by Tivoli Access Manager to track the state of all user sessions. For example, this consistency applies to users' authentication level so that when a user steps up to a higher authentication level, all replicated WebSEAL and Web server plug-in servers automatically have the updated credential available. Similarly, when a user's session times out, either due to inactivity or session lifetime expiry, the user session ends across all servers.
Cluster-wide login policy enforcement

The centralized view of all user sessions maintained by the session management server provides a single point from which to enforce user identity-based session policies. The maximum number of concurrent sessions a user has across the cluster can be limited by policy. The session management server enforces the policy that can either be set to disallow a new session that exceeds the maximum or set to replace a current session with the new session.
Failover
Earlier versions of Tivoli Access Manager required the use of a failover cookie to approximate the session replication capabilities of the session management server. When configured to use the session management server, there is no longer any need to use the failover cookie. The session management server provides a more consistent and complete view of user sessions across sets of replicated Web security servers.
Session information management

The session management server records a variety of session information. Having session information available in a central location offers the ability to manage and monitor sessions across servers. The session management server records the following session information: v Concurrent log in information v Session statistics information, such as the number of users logged in Authorized users have access to this information and can use this information to promote system security.
Support for multiple instances

Tivoli Access Manager for eBusiness version 6.1 supports multiple session management server installations on a single WebSphere Application Server. Each installation is called an instance. Each session management server instance can contain one or more session realms, and each session realm can contain one or more replica sets. These terms and concepts are explored more fully in Session management server architecture on page 4. Using the session management server administrative tools, you can view all available instances, deploy and configure new instances, or swap from one instance to another to perform administrative tasks.
Limited session realms

Tivoli Access Manager for eBusiness version 6.1 allows you to limit the maximum number of sessions for a particular session realm. Once the maximum number of sessions has been reached, further session requests will be denied until the number of sessions has dropped below the set threshold.
Session management server architecture

The session management server is built to run on WebSphere Application Server and WebSphere Network Deployment. The session management server supports communications using the IBM WebSphere Web server plug-in (IBM HTTP Server) or Microsoft IIS (on Windows). During configuration you are prompted to provide the WebSphere port number. This port number should be the port for WebSphere communication using the WebSphere Web server plug-in. Figure 2 shows the Tivoli Access Manager blade and WebSphere interface.
Firewall
Replica set WebSphere Application Server
WebSEAL replica 2
IBM HTTP Server
WebSEAL replica 1
WebSphere Web server plug-in
Session Management Server
Figure 2. Simple session management server architecture.
The session management server is useful in environments that have replicated Web security servers. Web servers secured by Tivoli Access Manager are replicated to provide high availability and load balancing. Alternatively, single servers in a cluster of servers can form part of a larger application. When servers are clustered for reasons of high availability and load balancing, the content of the participating servers is identical. Often a load balancer is used to distribute the Internet traffic across each replicated server. The term replica set is used to refer to a collection of replicated WebSeal (or Web server plug-in) Web security servers. Replicated servers within a replica set serve the same content, are configured the same way, and enforce the same security policies. Figure 3 on page 5 and Figure 4 on page 5 show typical architectures for failover and load balancing with either Tivoli Access Manager Plug-in for Web Servers or WebSEAL. In both cases, WebSEAL and the plug-in are replicated, and both use the session management server to maintain session information across the clustered
servers. From a user point of view, a session exists as a single entity across each environment.
Firewall Firewall
Junctioned servers Replica set

SD
Load balancer Browser
WebSEAL replica 1
WebSphere Application Server Session management server
WebSEAL replica 2 Tivoli Access Manager communications WebSEAL replica 3 Policy database
DMZ
Registry
Figure 3. A typical session management server architecture with WebSEAL

Firewall Firewall
A.tivoli.com replica set

SD
plug-in
Load balancer Browser
A.tivoli.com
WebSphere Application Server Session management server
A.tivoli.com
plug-in
Tivoli Access Manager communications Policy database
A.tivoli.com
DMZ
plug-in
Registry
Figure 4. Basic session management server architecture with Tivoli Access Manager Plug-in for Web Servers.
The protected servers shown in Figure 3 and Figure 4 might also be used to host content for different (yet related) Web sites, or each server might form part of a larger, single application. When a user who is accessing these servers perceive them as a single application that requires a single login and consistent concurrent session policy, the session management server can be used to provide secure access across all of the servers.
The extent of a session within a server cluster is referred to as the session realm. The session management server can provide a seamless single sign-on experience across a session realm. Servers are added to or removed from session realms by configuration within WebSEAL or the Tivoli Access Manager Plug-in for Web Servers. Figure 5 shows a representation of a session realm. A session realm consists of one or more replica sets and the user's session is replicated across the entire session realm. When users log in, they are considered logged in to the entire session realm. Concurrent session policy is applied across the entire session realm. If a user who is limited to a single concurrent session logs in to one replica set within the realm and then tries to log in to another replica set within realm, the second login is denied.
Tivoli.com session realm

A.tivoli.com replica set
A.tivoli.com
SD
A.tivoli.com
plug-in
plug-in
Browser B.tivoli.com replica set
WebSEAL replica 1 Junctioned servers WebSEAL replica 2
Figure 5. An example architecture with two replica sets within a session realm.
Deployment considerations
Set up the Tivoli Access Manager environment before installing and configuring the session management server. The configuration requires that you have a thorough understanding of the structure of your session realms and associated replica sets and the replica sets that are not assigned to a specific session realm. Before installation and configuration, decide whether you want to have replicated session management server instances (WebSphere Network Deployment only). Having more than one session management server that serves your Tivoli Access Manager sessions can provide a failover capability and improve performance.
To use the pdadmin command for administration purposes, you must install and configure the Session Management Server Command Line Extension component to a Tivoli Access Manager authorization server. By contrast, pdsmsadmin does not require an authorization server as it communicates directly to WebSphere Application Server. The pdadmin command line provides server tasks that communicate with the session management server to perform administrative operations. As server tasks, they are suitable for use in custom administrative applications of your own that can be developed using Tivoli Access Manager administration APIs. Such API development can only be performed with pdadmin, not pdsmsadmin. An authorization server is required to make use of the credential refresh capabilities of the session management server or is required to use the certificates that are issued by the Tivoli Access Manager policy server. The certificates that are issued by the policy server provide authentication between the session management server and its client applications. For additional details, see Security considerations on page 9. When an authorization server is required, it is typical to deploy an authorization server to each machine that hosts an instance of the session management server. Figure 6 shows a basic structure of the various administration interfaces for the session management server.
Firewall Junctioned server
Replica set WebSEAL replica 2
SMS admin using pdsmsadmin
WebSEAL replica 1
Session Management Server ISC WebSphere Application Server
SD
Browser
Authorization server with SMS command line extension
Authorization server for credential refresh
Policy server
SMS administration using pdadmin
Figure 6. Session management server administration architecture
When deployed, the session management server is a critical Tivoli Access Manager component. It must remain highly available so that the client does not become unavailable. The session management server should therefore be run in a clustered environment consisting of at least two cluster members. If all clusters members become unavailable, the session data maintained by the session management server will be lost. For continued service when restarting the SMS cluster, only use the WebSphere Application Server ripple start functionality if there are three or more cluster members. If there are only two cluster members in the cluster, use a manual start and stop of each cluster member one at a time. This process ensures that the second cluster member is brought down only when the first one is back up and running again. To help ensure high availability, only restart the SMS cluster under conditions of low activity, when there are minimal Tivoli Access Manager sessions open. It is also important to ensure that the catalog service is always running and any container servers can connect to it during a restart. A WebSphere core group should be set up, and dedicated to the session management server. This core group should only include those cluster members which contain an instance of the session management server. To avoid unnecessary data replication across the network, the WebSphere Application Server Network Deployment Manager should not be a member of the session management server core group. More information about WebSphere Application Server Core Groups can be obtained from the WebSphere Application Server Information Center. In some situations, the heap size of the hosting WebSphere Application Servers will need to be increased. This will usually be required if a large number of concurrent sessions will be managed by the Session Management Server. To increase the heap size of the WebSphere Application Server, perform the following steps: 1. Open the Integrated Solutions Console 2. On the left hand side, expand the Servers' heading and click Application servers. 3. Click on the name of the server you wish to modify. 4. Under the Server Infrastructure heading, expand the Java and Process Management heading and click Process Definition. 5. Under the Additional properties heading, select Java Virtual Machine. 6. In the Maximum Heap Size text box, specify the new maximum heap size and click OK. 7. Click Save to save the changes. 8. Restart the application server for the changes to take effect. The maximum heap size of the Deployment Manager can be modified by performing the following steps: 1. Open the Integrated Solutions Console 2. On the left hand side, expand the System administration heading and click Deployment manager. 3. Under the Server Infrastructure heading, expand the Java and Process Management heading and click Process Definition. 4. Under the Additional properties heading, select Java Virtual Machine. 5. In the Maximum Heap Size text box, specify the new maximum heap size and click OK. 6. Click Save to save the changes.
7. Restart the deployment manager server for the changes to take effect.
Security considerations
There are two steps to applying security when using the session management server: 1. Configuring secure communications between the WebSphere server that hosts the session management server and the session management server client applications. 2. Enabling J2EE security on the WebSphere server that hosts the session management server including defining the membership of the session management server application roles.
Configuring secure communications

Referring to Figure 6 on page 7, secure communications can be configured among the following components: v The Tivoli Access Manager Web security and authorization servers and the WebSphere Web server plug-in that access the session management server. v The WebSphere Web server plug-in and the WebSphere server itself. Configuring SSL for these connections can result in a small performance degradation. However, session information should be considered sensitive and all attempts should be made to keep it secure. It is recommended that SSL be configured for these connections. Notes: 1. When security is enabled in a WebSphere environment, you must use the same user registry as that used by Tivoli Access Manager. You will also need to add the sms-administrator role to the list of users or groups who will access the session management server ISC. To perform this task, select Users and Groups in the WebSphere ISC. 2. For WebSphere clustered environments, changes to key and trust stores will need to be consistent across every server in the cluster. Refer to the WebSphere documentation for assistance. The following options can be used to achieve the communications previously described: v Leave the connections unsecured v Configure SSL between the connections using the certificates issued by the Tivoli Access Manager policy server during the configuration of each Tivoli Access Manager server v Configure SSL between the connections using certificates that you provide yourself.
Configuring secure communications using certificates issued by the policy server

When a Tivoli Access Manager server is configured, the policy server issues a certificate that the server uses to authenticate itself to the Tivoli Access Manager infrastructure. These same certificates can be used to authenticate SSL communications between these servers and the session management server. To use these certificates, the Web server that hosts the WebSphere Web server plug-in must be configured with a certificate issued by the Tivoli Access Manager policy server, and with the Tivoli Access Manager policy server CA certificate. The
WebSphere Web server plug-in is used to communicate with the session management server. The certificate issued by the policy server ensures that the client applications trust the Web server. The policy server CA certificate ensures that the Web server trusts the client applications. To obtain a certificate from the policy server for use by the Web server you can run the svrsslcfg utility on a machine that is configured with the Tivoli Access Manager runtime (for example, a machine running WebSEAL or an authorization server or the policy server). You can run the utility as follows:
touch /tmp/was-pi-sms.conf svrsslcfg -config -n was-pi-sms -h hostname_of_web_server -l no -a no \ -f /tmp/was-pi-sms.conf -d /tmp -r 0 -s remote
This will create a was-pi-sms.kdb and was-pi-sms.sth files in the /tmp directory that contains the certificate to be used by the Web server and the password needed to access the certificate file respectively. If you are using IBM HTTP Server as the Web server, these files can be configured directly to IBM HTTP Server when enabling it for SSL. For Web servers that do not understand the CMS key file format, use the IBM GSKit iKeyman tool to convert the key file into a format that the Web server can understand. The subject distinguished name (DN) specified in certificates issued by the policy server do not correspond directly to user entries in the Tivoli Access Manager user registry. When using certificates to authenticate to WebSphere, WebSphere requires the subject DN to map exactly to the DN of user defined in the WebSphere user registry. To overcome this, the session management server provides a Trust Association Interceptor (TAI) that maps the subject DN of a policy server issued certificate to the DN of the user to whom the certificate corresponds. Part of the session management server configuration process, therefore, enables TAIs. For more information about WebSphere TAIs, see the WebSphere documentation.
Configuring secure communications using user-provided certificates

You can use certificates other than those issued by the Tivoli Access Manager policy server for either end of the communications between the session management server and its client applications. You can obtain such certificates either from an external source, your own PKI infrastructure or by creating self-signed certificates using a tool like the IBM GSKit iKeyman tool. The only requirement is that each end of the communication has a certification authority (CA) certificate that can verify the validity of the certificate that is presented by the other end of the communication.
Configuring secure communications between the WebSphere Web server plug-in and the WebSphere server
When you install the WebSphere Web server plug-in you are provided with a key file that contains sample certificates for use in communication between the plug-in and the application server. Note: Do not use the sample certificates in an environment that requires secure communications between the plug-in and the application server.
10
The WebSphere documentation describes how to create your own certificates for the plug-in to use when communicating with WebSphere that you can follow. In addition, you can configure the plug-in to use the same certificates used by the Web server itself to communicate with the session management server client applications. To simplify this when you are using certificates issued by the Tivoli Access Manager policy server, the session management server configuration process creates a WebSphere SSL repertoire (also consisting of policy server- issued certificates). For details on changing the SSL repertoire that is used in communication with an application, see the WebSphere documentation.
Configuring session management server authorization

The session management server uses the J2EE role-based authorization model that is provided by WebSphere to authorize operations that are requested by its client applications. WebSphere J2EE security must be enabled before authorization of session management server operations can be performed. The WebSphere documentation describes in detail how to enable J2EE security. The requirements of the session management server are as follows: v Lightweight Third Party Authentication (LTPA) is enabled as the authentication mechanism. v The subject DNs of certificates used to authenticate to WebSphere by session management server client applications correspond to the DN of users in the WebSphere registry. This requires use of an LDAP-based user registry (for example, IBM Tivoli Directory Server or Microsoft Active Directory). v To avoid replication of user data between Tivoli Access Manager and WebSphere you should configure WebSphere to use the same user registry as Tivoli Access Manager. After security is enabled, access to the roles used to authorize access to the various session management server operations must be granted. The session management server defines the following interfaces: Session management interface The interface that is used by Web security servers to create, retrieve, modify, and end user sessions. Session administration interface The interface that is used by administrative applications to perform administration on the session management server and the sessions it maintains. Access to these interfaces is authorized separately.
Session management interface authorization

Access to the session management interface is controlled by the sms-client role. Session management server client applications authenticate to WebSphere using their certificate. This certificate corresponds to a WebSphere user. Access for session management server client application users can be granted either directly or by group membership. It is recommended that you define groups of users and assign these groups to roles, rather than assigning users to roles directly. This makes changes in role assignments simpler to manage because you just need to change the group membership.
11
assign a user or group to the sms-client role of the session management server: Login to the WebSphere administration console. Select Applications then Enterprise Applications then the instance name. Click Security role to user/group mapping. Select the sms-client role check box, and click either Lookup groups or Lookup users. 5. Lookup the groups and users you want to assign the sms-client role and add the required groups or users. 6. Click OK. 7. Save the WebSphere configuration changes (this will automatically restart the session management server application).
To 1. 2. 3. 4.
Session administration interface authorization

The authorization of accesses to the session administration interface is slightly different. Because administration operations are requested by either pdsmsadmin or the Tivoli Access Manager authorization server, it is the user identity for these processes that authenticates to WebSphere. Users logging in to pdsmsadmin or the Tivoli Access Manager authorization server pass user identity information on to the session management server, indicating the identity of the real user who is requesting the administration operation (sec_master, for example). As such, the identity from the client certificate for either pdsmsadmin or the Tivoli Access Manager authorization server acts as a delegate of the real user requesting the operation.
sms-delegate pdsdmadmin sms-administrator IHS or IIS
SSL
WebSphere Application Server
session management server
Figure 7. Security levels for pdsmsadmin communications
The preceding diagram shows two levels of security between pdsmsadmin and the IHS or IIS server: v Communication channel security is provided by the client certificate. To ensure that only trusted entities can specify the identity of the real user who is requesting the administration operation, the first authorization that occurs checks that the user authenticated to WebSphere has the sms-delegate role, indicating that the user can be trusted to reliably specify the real identity of the user requesting the administration operation. v The User ID provides application security. If the first security test is passed, then the real user identity performs a second authorization. The real user must
12
possess the Administrator and sms-administrator roles to perform session management server administrative tasks. For example, consider a deployment where: v An authorization server is running on host server1.ibm.com, with a user name of ivacld/server1.ibm.com (configured with the session management server command line extension) v A user called sms-admin logs in to pdadmin to perform administration operations against the session management server For the administration operations to succeed, the ivacld/server1.ibm.com user must have the sms-delegate role and the sms-admin user must have the Administrator and sms-administrator roles. Access to these roles is granted in the same manner as access to the sms-client role previously described.
WebSphere usage of LDAP-based user registries

WebSphere allows configuration of a base distinguished name (DN). This is used as a starting point for all searches of the registry. Configuration of a base DN allows you to login, for example to the WebSphere administration console, without specifying the full DN of the user you are logging in as. However, when a base DN is specified, all DNs used for authentication must be a child of this base DN. If not, authentication will fail. For example, if you have configured a base DN of C=US, O=IBM, then DN of all users must begin with C=US, O=IBM. Users with a DN of C=AU, O=IBM will not be able to authenticate. Some Tivoli Access Manager administrative users have Tivoli Access Manager specific DNs. In particular, the administrative user sec_master will generally not have a DN of the form used by other users in the registry. To perform session management server administrative operations as the user sec_master you must therefore ensure no base DN is configured for the WebSphere LDAP user registry. Similarly, if you are using Tivoli Access Manager policy server issued certificates for authenticating SSL communications between the session management server and its client application, you must ensure no base DN is configured for the WebSphere LDAP user registry. Tivoli Access Manager certificates correspond to registry users with a DN in a Tivoli Access Manager specific part of the user registry.
Configuring security role membership for SMS administrator

When WebSphere Administrative Security is enabled, you must configure the SMS administrator to be a member of the following roles: v Administrator v sms-administrator You can configure security role membership for an SMS administrator for the WebSphere Application Server version 6.1 and version 7.0 using the WebSphere Integrated Solutions Console. For WebSphere Application Server 6.1, complete the following steps:
13
1. Open the Integrated Solutions Console. 2. Navigate to Security > Secure administration, applications, and infrastructure > Administrative User Roles > User. 3. Enter the SMS administrator ID. 4. Select Administrator and sms-administrator roles. 5. Click Ok. 6. Save the master configuration. For WebSphere Application Server 7.0, complete the following steps: 1. Open the Integrated Solutions Console. 2. Navigate to Users and Groups > Administrative User Roles. 3. Click Add to create a new user for the SMS administrator. 4. Select Administrator and sms-administrator roles, search for the appropriate user and click to add them to the Mapped to role box. 5. Click Ok. 6. Save the master configuration. Note: In WebSphere Application Server, version 7.0, you cannot change the roles of the primary administrative user. Create a separate administrative user to administer the SMS.
WebSEAL and Plug-in for Web Servers configuration

The participating Tivoli Access Manager blades (WebSEAL, the Plug-in for Web Servers, or both) need to be configured to use the session management server for managing sessions. Configuration of these products is not covered in this document and is instead detailed in the respective guides for these products: v IBM Tivoli Access Manager for e-business: WebSEAL Administration Guide v IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Administration Guide Configuration of these components is the last step in session management server configuration. However, it is important to realize that configuration of these entities is required. Therefore, they need to be installed and running before the session management server can operate. For complete installation instructions for Tivoli Access Manager components, see the IBM Tivoli Access Manager for e-business: Installation Guide.
Single sign-on with the session management server

The session management server provides a single sign-on (SSO) capability across replica sets in a session realm. This SSO is based on a domain cookie set by the Tivoli Access Manager blade. Use of a domain cookie requires that all of the replica sets be peer DNS domains, so that when set by a member of one replica set in the realm the browser will submit the cookie to the other replica sets in the realm. If SSO across DNS domains is required, an e-Community single sign-on (eCSSO), cross-domain single sign-on (CDSSO), or External Authentication Interface (EAI) solution should be considered. Details on these cross-domain SSO approaches are documented in the IBM Tivoli Access Manager for e-business: WebSEAL Administration Guide and the IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Administration Guide.
14
Note: Single sign-on performed using anything other than the session management server domain cookie results in multiple sessions for the user being created at the session management server. To apply concurrent session policy, you need to take this into account when designing your replica sets and session realms. If each replica set is configured as part of the same session realm, a single user, signed on to multiple replica sets using eCSSO, will have multiple sessions. If single sign-on can occur between replica sets using a method other than the session management server domain cookie and you want to make use of concurrent session policy in the replica sets, those replica sets should not be part of the same session realm. That is, the following conditions must apply before it is necessary to split the replica sets into different realms: v Requires concurrent session policy v Requires the ability to single sign-on between replica sets using a method other than session management server domain cookies The session management server single sign-on facility across replica sets within a DNS domain removes the need for the failover cookie. A single session ID is used across each replica set to represent the user's single session across the entire session realm. A session realm can consist of replica sets of any kind (for example, WebSEAL and Plug-in for Web Servers). If access privileges permit, the client (as illustrated in Figure 5 on page 6) can move between any of the servers in the session realm (tivoli.com, in the figure) without the need to re-authenticate. The session management server allows for single sign-off across replica sets. Signing out of one replica set ends the session across the entire realm.
Back-end storage mechanisms

You can configure the Session Management Server to use one of three different back-end storage mechanisms. The deployment configuration options on the target computer or cluster of the SMS deployment determine which storage mechanism is used.
Single server
Two back-end storage mechanisms are available for a stand-alone SMS server: v In-memory v Database
In-memory
The in-memory storage mechanism is the default mechanism for a single stand-alone SMS server. In-memory storage is not suitable for a production environment because this mechanism does not scale and is not fault tolerant. In-memory storage is a good option to use when performing a demo or reviewing the capabilities of the SMS in a proof-of-concept environment.
Database
You can store the SMS session data in a database. To enable this storage mechanism you need to specify yes to the Enable database storage option when deploying the SMS using the smscfg tool. Only a single-server SMS deployment supports storing session data in a database, which makes this storage mechanism less viable for a highly available production environment.
15
NOTE: Database storage can be used for last login information, even in a clustered environment.
Clustered server
For a clustered SMS environment, WebSphere eXtreme Scale storage is the only available back-end storage mechanism.
WebSphere eXtreme Scale

In a clustered environment, the SMS session data is stored using WebSphere eXtreme Scale, which is a separate IBM product that the SMS uses. WebSphere eXtreme Scale is a scalable data grid that can replicate data across JVM instances to ensure high availability. This configuration is the most appropriate for a production environment because of its high availability and scalability.
16
Chapter 2. Configuration
This chapter explains how to deploy, configure, and unconfigure session management server instances. It contains the following sections: v Installing the session management server v Deploying the session management server on page 18 v Configuring the session management server on page 19 v Configuring the command line extensions on page 23 v Unconfiguring the session management server on page 24 v Deploying and configuring additional instances on page 24 v Adding a new member to an SMS cluster on page 26
Installing the session management server

For complete session management server installation details, including pre-installation considerations and requirements, see the "Session Management Server" section of the IBM Tivoli Access Manager for e-business: Installation Guide. Installation of the session management server involves: v setting up a session management server, v setting up the session management command line(s). Both tasks can be performed using either native utilities or installation wizards. Following installation, the session management server application must be deployed and configured. For deployment details, see Deploying the session management server on page 18. For configuration details, see Configuring the session management server on page 19. Once you have installed, deployed and configured the session management server, administrative tasks for session management can be performed using any and all of the following administrative tools: v the pdadmin command line extension, v the pdsmsadmin command line extension, or v the Session Management Server ISC, which is installed as an extension to the WebSphere ISC. The availability of these tools will depend on your installed session management components. To administer the session management server with the pdadmin or pdsmsadmin commands, you must install the PDSMSCLI package. For pdadmin, the PDSMSCLI package must be installed on the same system as your Tivoli Access Manager authorization server. To administer the session management server from the ISC, you must install the PDSMS package on your WebSphere system. Once you have deployed the session management server ISC extension, you can use it to deploy and configure additional session management server instances (see Deploying and configuring additional instances on page 24). For full installation details, see the "Session Management Server" section of the IBM Tivoli Access Manager for e-business: Installation Guide.
17
Installing Fixpack upgrades

To install a new session management server fixpack: 1. Install the updated package (installshield, RPM, pkgadd, etc.) on your deployment manager (for network deployment) or application server machine (for single servers). 2. For each deployed SMS instance, run the command:
smscfg -action upgrade -instance instance_name
This will apply the installed fixpack level to the specified SMS application. During this process, the session management server application will be restarted. For clusters spread across multiple nodes, no data will be lost. To remove a fixpack, run the following command:
smscfg -action revert -instance instance_name
This will revert the most recent fixpack applied to the specified instance (that is, the version that was installed before the fixpack was applied). A complete version history is kept, so you can revert all the way back to the version that was originally installed. Again, the application will be restarted. You can only apply a fixpack if it is more recent than your current application version. To apply an older fixpack, you must first revert to a version older than the fixpack. For example, if you upgraded your SMS instance from fixpack 2 to fixpack 4 to fix one problem, but were not happy with fixpack 4, you would have to revert to fixpack 2 first before upgrading to fixpack 3. When fixpack 5 came out, however, you could upgrade directly to that.
Deploying the session management server

The installation process includes deployment of the session management server application. This can be done using the smscfg utility or the session management server ISC. Notes: 1. Before it can be used, the ISC extension must itself be deployed. This can be done with the command:
smscfg -action deploy -instance ISC
2. The use of DB2 as the session storage mechanism in a WebSphere Application Server clustered environment is unsupported. You can however use it for storing the last login information. 3. If you intend to use a DB2 database to store login history information, you must create the database before deploying the session management server application. For details, see the IBM Tivoli Access Manager for e-business: Installation Guide. 4. A supported version of WebSphere eXtreme Scale must be installed on each node of the WebSphere cluster prior to the deployment of the SMS. For details, see the "Session Management Server" section of the IBM Tivoli Access Manager for e-business: Installation Guide. To deploy the session management server application using the smscfg utility: 1. Prior to running smscfg, run the WebSphere setupCmdLine.bat or setupCmdLine.sh script (depending on your operating system).
18
2. Deploy the session management server application using the command:

smscfg -action deploy -instance instance_name
For further details, see smscfg on page 87. To deploy an instance of the Session Management Server application using the ISC: 1. Log in to the ISC as the Session Management Server administrator. 2. Select Tivoli Session Management Server then Deployment. 3. In the Application name field, enter the name of the Session Management Server application. This field is required. 4. In the Target field, enter the WebSphere Application Server cell element to which the Session Management Server instance will be deployed. 5. In the Virtual host field, enter the Web server virtual hosts that will service the Session Management Server application instance. 6. In the Data source field, enter the data source to use with the Session Management Server application instance. 7. When you are ready to deploy, click Deploy. Deployment of the application may take several minutes without generating any messages. Click the Refresh button to update the current progress. Upon successful deployment, the new instance should be visible.
Configuring the session management server

The session management server itself requires configuration to initialize it in the environment. After installing and configuring the session management server and extension components, the participating servers in the session realm (either WebSEAL or the Plug-in for Web Servers, or both) will require configuration. Configuration at WebSEAL and the plug-in points these blades at the session management server instance. The session management server configuration utility, smscfg, can be run in any of three ways, including a combination of the three: v Interactively using the interactive yes parameter. With this approach, you are prompted to input the required parameters as the utility proceeds. v Non-interactively using the interactive no parameter. With this approach all parameters are required to be supplied with the command entry. v Using a response file (rspfile path_to_file) to store the necessary parameters and having the utility read from the file. You can also record a response file and re-use the stored information for later configuration purposes. Parameters entered on the command line take precedence over parameters in the response file. The discussion of the session management server configuration commands in this chapter assumes you have used the interactive yes parameter so that the command prompts you for input. A complete listing and explanation of all session management server utilities is included in Appendix B, SMS utilities, on page 81.
19
Gathering configuration details

Before performing the configuration, run the setupCmdLine command to set up the correct execution environment for the tool. In network deployment environments, this utility is located in the WebSphere deployment manager /bin directory. Table 1 lists the information that should be gathered before beginning the configuration of the session management server.
Table 1. Session management server configuration considerations. Item WebSphere cluster name Description You must decide whether you are deploying the session management server to a WebSphere cluster or a standalone server. If deploying to a cluster, you will require the cluster name. Specifies the name of the host where the session management server is deployed. In WebSphere network deployment architectures, the host value is the same as that for the deployment manager. In WebSphere single server environments, the host value is for the WebSphere server where the session management server was installed. During configuration, default values are offered. These default values are obtained from the wsadmin.properties file. Note: The installation wizard uses wsadmin to connect to the WebSphere server and obtain a list of servers. Some additional setup is required for wsadmin to connect to the WebSphere server when security is enabled using private certificates. The soap.client.props file in the WAS_path/profiles/default/properties/ directory must be edited to reference the new client key files. WebSphere user name and password. To enable a secure connection between the participating Web servers and the WebSphere server that is hosting the session management server, supply the user name and password required for access to the WebSphere server. Values for the full path to the WebSphere trust store and the trust store password are only necessary when WebSphere security is enabled. A default value for the trust store location is offered during configuration. The full path to the key store and the associated password are only required when WebSphere security is enabled. Default values are offered. The configuration requires you to enter a session realm structure with associated replica sets. It is not necessary to specify any session realms but at least one replica set should be specified. Controls whether the session limit and displacement policy is enabled. The default value is to enable this policy.
The WebSphere server host name
The full path to the trust store and the trust store password. The full path to the key store and the key store password. Session realm and replica set structure.
Session limit policy.
20
Table 1. Session management server configuration considerations. (continued) Item Auditing configuration file. Description Two auditing log files are available, depending on whether you are logging to a file or a CARS service: v install_root/etc/ textfile_emitter.properties.template for logging to a file, and v install_root/etc/ webservice_emitter.properties.template for logging to a CARS service. These templates must be edited to add configuration details before you configure your SMS server. See the templates for further details. Key lifetime The lifetime of the key used to sign session management server session IDs will require configuration. After the configured time has elapsed the session management server will automatically regenerate the key. This process occurs without the need for user intervention. A reasonable setting for this option should take into consideration security issues associated with key lifetime. Tivoli Common Directory (TCD) Logging You will have the option of configuring the Tivoli Common Directory on each machine where the session management server is installed. This will require the entry of the full path location of the Tivoli Common Directory or the existing value can be used, if present. Information on the Tivoli Common Directory can be found in the IBM Tivoli Access Manager for e-business: Installation Guide. Tivoli Access Manager configuration information. You have the option to enable integration with Tivoli Access Manager. Tivoli Access Manager integration should be enabled if you want to use credential refresh functionality. It is not required for other SMS functionality. If you choose to enable Tivoli Access Manager integration, then you will be prompted to enter data covering the use of Tivoli Access Manager certificates for authentication of clients. Requested details include: v The policy server host name. v The policy server port. The default port is 7135. v The Tivoli Access Manager administrator ID. The default value is sec_master. v The Tivoli Access Manager administrator password. v Authorization server(s) details. PDJRTE 6.1 is required if multiple authorization servers are to be used.
21
Table 1. Session management server configuration considerations. (continued) Item Last login parameters. Description The session management server can be configured to record last login information. This information includes the date and time of the last login (from the current browser) and the number of failed login attempts since the last successful login before the current login. This information is then available for display in a browser if required. A number of parameters are required for configuring last login. You will be asked to enter: v The name of the database table used to store the last login information. This information is only required if you have selected a data storage type of DB (database). The default database table name is AMSMSUSERINFOTABLE. v The maximum number of entries to be stored in the memory cache for the last login information. The default number of maximum entries is 5000. v The name of the last login JSP file. The default value is lastLogin.jsp. This file is located on the install directory for the session management server. Data storage type. This parameter defines the registered JDBC database that is used for storing last login and session data, which facilitates recovery should your system fail. If you have chosen to deploy the session management server in a clustered WebSphere architecture, then session information is stored and distributed using WebSphere eXtreme Scale. In a clustered deployment it is not possible to store the session information to a DB2 database. In single server architectures, session information can be stored in a database. The session management server supports the use of DB2 for storage of session information in single server WebSphere architectures. The use of DB2 as the session storage mechanism in a WebSphere Application Server clustered environment is unsupported. You can however use it for storing the last login information. If you choose not to store session information or are using a database other than DB2 (in single server architectures), the session management server cannot recover session information after a failure. Last login data can either be stored to memory or to a database. If you are storing to a database, the selected source must be the same as used to store the session table. The session table can also be stored to a database, memory, or direct to a cluster. The session table can only be stored to memory if deploying to a standalone server rather than a cluster. Client idle timeout. The client idle timeout will require configuration. This is a time value, in seconds, after which the session management server will stop communication with a server. For a discussion of this, see Session information consistency on page 3.
22
Running the configuration utility

The session management server can be configured using the smscfg action config utility. If details are incomplete, the utility launches an interface that prompts you for additional information. The session management server configuration utility is installed in the /bin subdirectory of the session management server installation by default: Linux and UNIX operating systems /opt/pdsms/bin Windows operating systems C:\Program Files\Tivoli\pdsms\bin A log of the configuration progress is stored in the /var/pdsms/log/ msg_pdsms_config.log file. For complete details about this utility, see smscfg on page 87.
Configuring the command line extensions

The session management server requires configuration before either the pdsmsadmin or pdadmin command lines can be used for administrative purposes.
Which command line to use?

Integration with Tivoli Access Manager is required for pdadmin, but not for pdsmsadmin. From a programmer's perspective, pdadmin provides access to Tivoli Access Manager administrative API's, which can be used to execute session management server commands, whereas pdsmsadmin does not. pdadmin also provides backwards compatibility with version 6.0 of the session management server, for which integration with Tivoli Access Manager was compulsory.
Other considerations
The following points should be also considered prior to configuration: v Further configuration will require the name of the server that hosts the session management server and the port number used for communications. If you choose to integrate with Tivoli Access Manager, you will also require the name of the authorization server which hosts the command line extension utility. More than one session management server can be installed for failover and performance reasons. In such cases, the host name, instance and communication port number for each should be recorded. v If integration with Tivoli Access Manager is enabled, the configuration command writes properties to the host authorization server's configuration file, ivacld.conf. If this file is not in the default location then the exact location will need to be entered at the time of configuration. v You will need to decide whether to enable SSL communications between the authorization server and the WebSphere server that is hosting the session management server. While SSL can provide additional security for your network, this will entail a performance cost that should also be considered. SSL for this connection can use the authorization server certificates, but this relies on the session management server having also been configured to use the Tivoli Access Manager certificates. Alternatively, you can configure the SSL connection using custom or private certificates, as described in Security considerations on page 9. The configuration command will require the following information:
23
The full path to the SSL key file that is to be used to encrypt communications. The full path to the SSL key file stash file. The label of the client certificate in the SSL key file. To configure the session management server command line extension, use the pdsmsclicfg -action config utility. If integration with Tivoli Access Manager is enabled, you can also use the pdconfig utility. Run the command from the server that is hosting the session management server. The command is located in the /bin directory on the session management server installation. For complete information about this utility, see pdsmsclicfg on page 82. There are three ways to configure the session management server command line extension on Windows: v Tivoli Access Manager Configuration GUI, v SMS CLI GUI (this is C:\Program Files\Tivoli\PDSMS\bin\pdsmsclicfg.exe), or v SMS CLI command line (C:\Program Files\Tivoli\PDSMS\bin\pdsmsclicfgcl.exe).
Unconfiguring the session management server

Unconfiguration will remove the session management server from the Tivoli Access Manager Policy Server. This may be useful if you enabled Tivoli Access Manager integration when configuring your session management server instance. To unconfigure session management server components, use the following utilities: v smscfg action unconfig v pdsmsclicfg action unconfig For complete details about using these utilities, see smscfg on page 87 and pdsmsclicfg on page 82 respectively.
Deploying and configuring additional instances

You can use smscfg or the session management server ISC to deploy and configure additional instances on WebSphere Application Server. To deploy a new instance of the session management server using the smscfg command:
smscfg -action deploy [-instance instance_name]
You can deploy a new instance of the session management server using either the smscfg utility or the ISC. The smscfg command is:
smscfg -action config -instance instance_name
To 1. 2. 3.
deploy a new instance with the ISC: Select deployment from the main menu of the session management server ISC. Enter an Application name for the new instance in the text field. Use the dropdown menus to select appropriate values for the following: v Target v Virtual host v Data source
24
4. Click Deploy. Deployment of the application may take several minutes without generating any messages. Click the Refresh button to update the current progress. Upon successful deployment, the new instance should be visible. To configure a new instance of the session management server extension: 1. Select configuration from the main menu of the session management server ISC. 2. Select the checkbox next to the instance that you wish to configure. If a new instance is not visible, click the Update SMS instance list button. 3. Click the configure button to proceed. The configuration process involves providing the following information: Session Realms and Replica Sets Specify a new session realm name to create a new session realm, or modify an existing session realm by specifying a session realm name that already exists. To limit the maximum sessions for the session realm, select the checkbox and enter a limit value. Then click the Update Session Realms button. To create a replica set, specify a replica set name that does not already exist and the appropriate session realm and then click the Update replica sets button. To modify an existing replica set, specify the name of the existing replica set and the modified session realm name and then click the Update replica sets button. Clients which have the same configuration can connect to the same replica set, but clients with different configurations must connect to different replica sets. Click Next to proceed. Tivoli Access Manager integration Select the checkbox to enable Tivoli Access Manager integration. Click Next to proceed to dialogs requesting further data. Last Login recording Select the checkbox to enable Last Login recording. Click Next to proceed to dialogs requesting further data. Tivoli Common Directory logging Select the checkbox to enable Tivoli Common Directory (TCD) logging. Accept the default path for the log directory, or specify a new path. Click Next to proceed to dialogs requesting further data. Auditing Select the checkbox to enable auditing. Click Next to proceed to dialogs requesting further data. Timeouts Select the checkbox to configure timeouts. Accept the default values for timeouts (600 seconds) and key lifetime (186 days), or specify new values. Click Next to proceed. 4. The Summary screen displays the information you have entered. Click Finish to complete the configuration process. 5. Deployment may take a few minutes and progress is not displayed on screen. To verify whether the deployment has completed, click the Refresh button. On successful completion, the new instance should be visible.
25
Adding a new member to an SMS cluster

Adding additional Websphere Application Servers to an existing SMS cluster provides additional resources to process requests from SMS clients. The additional servers also expand the number of sessions that the SMS can store. The SMS can scale to double the original deployment size. After deployment, only some parts of the back-end storage system continue to scale. If a cluster doubles its original size, perform the following actions to reset the scalability limit: 1. Unconfigure and undeploy the cluster. 2. Re-deploy and re-configure the cluster. See smscfg on page 87 for more details. Perform the following steps to add a new cluster member to an SMS cluster: 1. Install WebSphere Application Server Network Deployment including appropriate fix packs on the new server and create an appropriate profile. 2. Install WebSphere eXtreme Scale and associated fixes, augmenting the new profile during installation. 3. Federate the new node into the existing cell. 4. Create a new WebSphere Application Server instance in the cluster.
26
Chapter 3. Using the session management server

You can administer the session management server and the sessions that it maintains using the various tools described in Session management server administration options on page 1. Tasks that can be performed using the ISC, pdsmsadmin or pdadmin include locating, refreshing and terminating sessions, managing key information for validating external sessions IDs, and generating new keys. Additionally, you can use the smscfg action config utility to modify the configuration by performing tasks such as: v Moving replica sets from one session realm to another. v Add and remove session realms. v Add and remove replica sets that are not assigned to a session realm. This chapter details how to perform a variety of common tasks, principally using the ISC. For further details on pdsmsadmin and pdadmin commands, see Appendix A, SMS pdsmsadmin and pdadmin commands, on page 49. For details of smscfg action config commands, see smscfg on page 87.
Searching user sessions

All currently active sessions can be listed, or more refined searches of sessions can be made. You can search user sessions as follows: 1. Select Search Sessions from the session management server ISC main menu. 2. Determine the session management server instance you wish to search. 3. The following fields are available to restrict your search: v The User ID field accepts wildcard values. v The Maximum Results field restricts the number of returned session IDs. v The Session Realm field must include a session realm value. 4. Click the Search button to start your search. Search results are returned showing the session user ID and the login time for the session. Users with multiple sessions are grouped together. You can select, filter and sort the results using the appropriate icons.
27
Figure 8. Filtered searching of session realms using the ISC
The pdsmsadmin and pdadmin command line utilities provide equivalent commands, such as session list for listing user sessions. The usage of these commands is described in detail in Appendix A, SMS pdsmsadmin and pdadmin commands, on page 49.
Ending user sessions

The ability to end user sessions is often useful when, for example, a browser error occurs and the user cannot log back in. When the administrator has located and ended the active session, the user will be required to authenticate again, thus creating a new session. To end one or more user sessions, search the current sessions using the ISC method described in the section above. Select the check box corresponding to the user ID you want to end and click Terminate. The pdsmsadmin and pdadmin command line utilities provides equivalent commands for ending user sessions using either terminate session or terminate all_sessions. The usage of these commands is described in detail in Appendix A, SMS pdsmsadmin and pdadmin commands, on page 49.
Setting the maximum concurrent sessions

The policy get and policy set commands in pdadmin allow you to display and set maximum concurrent Web session policy. These are standard Tivoli Access Manager pdadmin commands, which can be useful for session management purposes but are not available in pdsmsadmin or the ISC.
28
The following command returns an integer value corresponding to the maximum permitted Web sessions for a user:
policy get max-concurrent-web-sessions [-user user_name]
The search can be performed for a specific user by employing the user user_name option.
policy set max-concurrent-web-sessions {unset|number|displace|unlimited} [-user user_name]
This command sets the maximum number of Web sessions the session management server will permit for any one user. For details of the syntax used with these commands, see the IBM Tivoli Access Manager for e-business: Command Reference. Notes: 1. When an administrator switches to another user, the new session for the target user will not be subject to concurrent session policy. 2. This functionality is only available if the session limit policy option has been enabled during the configuration of the SMS instance.
Displaying session realms and replica sets

An authorized user can monitor session activity, display session realms, list the participating replica sets, list current sessions and search for specific sessions. The session management server components can be displayed using the ISC or the command line utilities. The following commands are available in pdadmin and pdsmsadmin: v realm show v realm list v replica set show v replica set list The usage of these commands is described in detail in Appendix A, SMS pdsmsadmin and pdadmin commands, on page 49.
Managing replica sets and realms

Replica sets and session realms can be managed using the Configuration menu of the ISC. New realms and replica sets can be added by working through the configuration dialogs. To add a new session realm or replica set, specify a name that does not already exist. To modify an existing realm or replica set, enter the name of an existing realm or replica set. Note: Clients which have the same configuration can connect to the same replica set, but clients with different configurations must connect to different replica sets. Realms and replica sets can be removed by selecting the relevant checkbox and clicking the Remove Selected button.
29
For further information, see Chapter 2, Configuration, on page 17, in particular the section Deploying and configuring additional instances on page 24.
Managing keys
The session management server uses a key to sign session IDs. This signing key lessens the possibility of a denial of service attack against the session management server. A single key is used across the entire cluster. The details of the session signing key can be accessed from the session management server ISC: 1. From the session management server ISC menu, select Key Management. 2. The Key Management screen is displayed. Use the current instance, or select another session management server instance. 3. The screen displays information about the current key. The date and time information is local to the application server that is hosting the WebSphere Application Server. 4. You can force the creation of a new key by clicking Generate new key now. You might want to forcibly create a new key when you suspect that the existing key has been compromised. The pdsmsadmin and pdadmin utilities provide equivalent commands for managing keys using key show and key change. These commands are detailed in Appendix A, SMS pdsmsadmin and pdadmin commands, on page 49.
Session management server statistics

Server statistics for Tivoli Access Manager session management server 6.1 are visible in the WebSphere ISC. Click on monitoring and tuning then performance viewer. The following statistics can provide a useful overview of session activity: session lifetime How long, on average, user sessions are lasting. session limit enforcements The number of times users have been denied a login due to concurrent session limits - only useful if there is a concurrent session limit. session displacements The number of times users have displaced an existing session to log in only useful if session displacement is enabled. active sessions The number of currently active sessions. active clients The number of web security servers currently accessing the SMS. To examine how sessions are created and deleted over a period of time, you can reset the sessions created, logouts, terminations, idle timeouts, and discarded sessions statistics, record them for a set duration, then plot the results. Other session management statistics are not particularly useful from a customer perspective.
30
For complete details about using WebSphere statistics, see the WebSphere documentation.
Tracking login activity

The session management server can record information about the last time a user logged in and the number of failed attempts to login since the last successful login. This information is useful when displayed to users at the time of login. This information alert users of any potential illegal activity on their account. A sample JSP file for displaying last login information is available in the following operating system-specific directory: Linux and UNIX operating systems /opt/pdsms/etc Windows operating systems C:\Program Files\Tivoli\PDSMS\etc This file can be used as a template for customizing your own display of last login information. Note: The login information displayed is dependent upon the browser that a user employs to access the system. Therefore, an unsuccessful attempt to login from another browser will not be displayed on the original browser. For example, consider the following activity.
1. 2. 3. 4. 5, 6. 7. Login at 12:00 Logout at 12:20 Login failure at 12:25 Login failure at 12:26 Login at 12:27 Login failure (from another browser) at 12:30 Display data via 1st browser
The following information would be displayed to the user:

Last Login=12:00, 2 login failures since that time, last failure at 12:26.
The login history is displayed as it was at the time of login only. Later events are not displayed.
Storing the login activity data

Login activity information is stored in session management server using a JDBC data source. This database is installed at the time of session management server installation. Login activity information is stored using the schema listed in Table 2.
Table 2. Login activity database schema. Value Data type Description The unique user name of the user. UUID for the user name. A count of the failed logins since the last successful login. A date/time stamp of the last failed login. A date/time stamp of the last successful login.
UserName (Primary Key) String UUID nFailures LastLoginFailure LastLoginSuccess String Integer String String
A mechanism for reconciling this data with the user registry is not provided. This data schema can be used to develop your own reconciliation capability.
31
Creating the login activity database

For details about creating the login activity database, see the IBM Tivoli Access Manager for e-business: Installation Guide. The sessions management server uses the generic JDBC interface provided by WebSphere to communicate with the database that is used for storing last login data. Despite JDBC being a common interface, different JDBC implementations provided by different database vendors often behave differently. This particularly pertains to database schema operations. If you use a database other than DB2 and you enable the last login data tracking capability of the session management server and then the session management server configuration fails when creating the last login database, you must create the last login database manually and restart the session management server configuration procedure. The details of the schema required by the session management server for the last login database are provided in Table 2 on page 31 to enable you to manually create this database.
Setting rules for credential refresh

Where a WebSEAL or Web Plug-in server has been configured for step-up authentication and SMS session storage, a user will be prompted to re-authenticate whenever an administrator refreshes user credentials via the SMS. This is because the default SMS credential refresh configuration does not preserve the "AUTHENTICATION_LEVEL" attribute in a user's credential. After their credential is refreshed, the authentication level is reset to zero, so any POPs that require higher authentication levels will result in the user being prompted to login again. To prevent this from occurring, you must update the SMS credential refresh configuration to include a rule that preserves the "AUTHENTICATION_LEVEL" attribute. This can be done using the graphic user interface or command line. GUI configuration: 1. Source the WebSphere setupCmdLine.sh or setupCmdLine.bat file to configure your Java environment. 2. Invoke the PDSMS configuration utility: /opt/pdsms/bin/smscfg -action config (for UNIX), or PDSMS_Install_Dir/bin/smscfg -action config (Windows). This launches the graphical configuration utility for the SMS. 3. Enter any required security information to contact the WebSphere server. 4. Once you reach the SMS configuration screens, click Next on each screen until you reach the Specify the credential attribute refresh rules dialog. 5. Click Add Rule to create a new rule. 6. Click on the Refresh entry of the new rule and change it to Preserve. 7. Click on the * entry of the rule and change it to authentication_level. 8. Click on Next until you reach the summary page. 9. Click Finish to start the configuration update.
32
10. Once the configuration update is complete, click OK to exit the configuration utility. Using the command line: 1. Create an SMS configuration response file smsconfig.rsp that contains any information necessary to contact the WebSphere server, such as the hostname of the WebSphere Application Server or deployment manager, the SOAP port number, and any WebSphere Application Server security information. For example:
was_host=wasdm.example.com was_port=8880 was_enable_security=yes was_admin_id=wasadmin was_admin_pwd=secret123 trust_store=/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/etc /AS01ClientTrustFile.jks trust_store_pwd=passw0rd
2. Update the smsconfig.rsp file to include the credential refresh rules you want to specify. Remember to include any existing credential refresh rules. The default credential refresh rule set is preserve=tagvalue_*. To add a rule to preserve the authentication_level attribute, include these two lines in the smsconfig.rsp file:
cred_refresh_rule=preserve=authentication_level cred_refresh_rule=preserve=tagvalue_*
3. Source the WebSphere setupCmdLine.sh (UNIX) or setupCmdLine.bat (Windows) file to configure your Java environment. 4. Change directories to the location of the smscfg program: /opt/pdsms/bin (UNIX) or PDSMS_Install_Dir/bin (Windows). 5. Invoke the SMS configuration tool with your response file:
./smscfg -action config -interactive no -rsp_file path-to-smsconfig.rsp
The configuration tool will update your configuration and restart the DSess application.
33
34
Chapter 4. Session management server best practices

This chapter covers the following topics: v Zone rules and zone configuration v Load balancer settings on page 36 v SMS sessions and session limit policy on page 37 v Tuning the Java Virtual Machine on page 38 v Session Management Server High Availability Considerations on page 39
Zone rules and zone configuration

You can use a combination of zone rules, zone configuration, and the Session Management Server (SMS) client configuration to minimize traffic in an SMS environment.
Zone configuration
A well-planned combination of WebSphere eXtreme Scale zones can minimize the SMS traffic between zone boundaries. When using zones in the SMS, the client configuration must reflect the SMS zone configuration to minimize cross-zone traffic. Zones can represent computer, building, or data boundaries. Rules determine how partitions are laid out in and between the zones. Use the WebSphere Application Server Network Deployment node group feature to configure the zone for a server.
Zone rule
The SMS includes a default zone rule and populates it with appropriate zone names. The WebSphere Application Server management interface provides these zone names during deployment. The default rule places primary and synchronous replicas in the same zone, and asynchronous replicas in a different zone. The WebSphere Application Server Network Deployment node groups define zones by prefixing the zone name with ReplicationZone. For example, the node group named ReplicationZoneOne represents the zone named One. Each server can belong to: v Multiple node groups. v Only one eXtreme Scale zone. If the deployment process discovers a server that belongs to multiple zones, it displays an invalid configuration error.
WebSphere eXtreme Scale zones

WebSphere eXtreme Scale zones and zone rules control the placement of partitions across the grid. Zones group servers in a particular location. Zone rules define how partitions are placed in and across these zones. Zone-preferred routing permits WebSphere eXtreme Scale clients to write to WebSphere eXtreme Scale servers in specific zones. Writing to specific zones limits the amount of cross-zone traffic in a grid. The following diagram shows an example deployment using eXtreme Scale zones.
35
Zone 1 Zone 2
Figure 9. Example deployment using eXtreme Scale Zones
You can find more information about eXtreme Scale zones in the WebSphere eXtreme Scale Version 7.0 information center: http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r0/index.jsp See "Using zones for replica placement" and "Zone-preferred routing" in the WebSphere eXtreme Scale Product Overview. The WebSphere Application Server information center also describes how to configure eXtreme Scale zones before deploying the SMS. The information center includes instructions for configuring cluster members to be part of a node group that represents a zone. See the "Viewing, adding, and deleting node group members" section in the Network Deployment (All operating systems), Version 7.0 Guide located in the Websphere Application Server Version 7.0 information center: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp
Load balancer settings

Use a load balancer to: v Spread the load equally across a cluster of SMS clients. v Provide fault tolerance and scalability. You can use many different load balancers and numerous algorithms. Session Stickiness in the load balancer is the most important setting for an SMS
36
environment. Stickiness is the ability of a load balancer to forward all requests from a particular client to the same server for the duration of the client session. Use the client IP address to maintain session stickiness. You must set session stickiness for an SMS cluster to function efficiently and effectively. Set the timeout for session stickiness to be equal to the timeout of the client session as defined by timeout in the session stanza of the configuration file.
SMS sessions and session limit policy Session limit policy

The SMS can enforce a session limit policy. This policy can either be on a per user basis, a per realm basis, or enforce session displacement for users. The configuration of the session limit policy occurs in the SMS client (for example, WebSEAL) and is sent to each SMS. During the SMS configuration, you can disable the session limit policy so that the SMS ignores the limits sent by the client. Disabling the session limit policy at the SMS causes enhanced performance in general operations. However, disabling the session limit policy reduces internal indexing, which reduces performance in administration operations such as session search and terminate.
Number of concurrent sessions

The number of concurrent sessions in the SMS environment dictates how much memory each SMS uses. This value also partially determines the required number of SMS servers. The number of authentications per second required, the session idle timeout, the maximum session lifetime, and the number of logouts determine the number of concurrent sessions.
Example
Consider an environment with four SMS clients and four SMS cluster members. Assume 50 authentications per second with an idle timeout of 30 minutes and a maximum session time of 1 hour. The calculations that follow assume that 80% of the sessions expire and the remaining 20% reach the maximum session lifetime. 50 auth/sec * 60 = 300 auth/minute 300 auth/min * 30 minutes = 9000 sessions created in 30 minutes After that time, 80% of the sessions become idle = 7200; 1800 remain. In the next 30 mins another 9000 are created, making a total of 10800 sessions. So at any one time, up to 11,000 sessions can be in the SMS.
Session cache size

The sum of the maximum number of sessions that can be held by each SMS client (for example, WebSEAL) determines the maximum concurrent sessions in the SMS. When the client session caches are full, the local cache drops sessions based on a Least Recently Used (LRU) algorithm. Sessions might be removed from the SMS if no other client instances hold a reference to the session. For example, consider an environment with a maximum of 10,000 sessions in the SMS. To accommodate this number of sessions, set the minimum cache size for each of the four clients to 2500. This setting is not adequate if two clients fail. In
37
this situation, the maximum number of sessions per client is 5000. In this case, set the cache size of each client to 5000 users.
Tuning the Java Virtual Machine

In most cases, you must increase the heap size of WebSphere Application Servers, including those servers acting as part of the catalog service. These servers can include application servers running the SMS application, node agents, or the deployment manager. An increase in the Java Virtual Machine (JVM) heap size is required if many concurrent sessions must be managed by the SMS. The JVM heap size dictates the maximum amount of memory that can be allocated to a WebSphere Application Server instance. In the SMS case, it defines the amount of memory allocated to the eXtreme Scale server, and therefore the session table size. NOTE: Servers acting as the catalog service do not maintain SMS session information but they require a larger heap size than the default 256Mb.
WebSphere Application Server Heap Size

In order to increase the heap size of a WebSphere Application Server perform the following steps: 1. Open the Integrated Solutions Console 2. On the left-hand side, expand the Servers heading and click Application servers. 3. Click the name of the WebSphere Application Server you want to modify. 4. Under Server Infrastructure, expand the Java and Process Management heading and click Process Definition. 5. Under Additional properties, select Java Virtual Machine. 6. In the Maximum Heap Size text box, specify the new maximum heap size. 7. Click OK. 8. Click Save. 9. Restart the application server for the changes to take effect.
WebSphere Application Server Deployment Manager Heap Size

In order to increase the heap size of the WebSphere Application Server Deployment manager perform the following steps: 1. Open the Integrated Solutions Console 2. On the left-hand side, expand the System Administration heading and click Deployment manager. 3. Under Server Infrastructure, expand the Java and Process Management heading and click Process Definition. 4. Under Additional properties, select Java Virtual Machine. 5. 6. 7. 8. In the Maximum Heap Size text box, specify the new maximum heap size. Click OK. Click Save. Restart the deployment manager for the changes to take effect.
38
WebSphere Application Server Node Agent Heap Size

In order to increase the heap size of the WebSphere Application Server Node agent perform the following steps: 1. Open the Integrated Solutions Console 2. On the left-hand side, expand the System Administration heading and click Deployment manager. 3. Click the name of the node agent you want to modify. 4. Under Server Infrastructure, expand the Java and Process Management heading and click Process Definition. 5. Under Additional properties, select Java Virtual Machine. 6. In the Maximum Heap Size text box, specify the new maximum heap size. 7. Click OK. 8. Click Save. 9. Restart the deployment manager for the changes to take effect.
32-bit and 64-bit considerations

There are several limitations on the heap size that you can allocate to a 32-bit JVM. Some of these limitations come from the underlying operating system. Other limitations are due to the amount of memory that can be addressed using a 32-bit pointer. Moving to a 64-bit platform permits larger memory addressing and heap sizes, but causes the additional overhead of larger memory pointers and an increased footprint. The overhead considerations are particularly relevant to an eXtreme Scale environment. Due to the scalable nature of eXtreme Scale and therefore the SMS, use additional 32-bit JVMs instead of 64-bit JVMs. Using 32-bit JVMs improves memory density compared to 64-bit JVMs. This structure also provides more fault tolerance in terms of the session data stored on each SMS instance and increases the number of servers able to process requests from SMS clients.
Configuring the Object Request Broker

To configure the Object Request Broker properties to suit your environment, see the "Orb properties file" section in the WebSphere eXtreme Scale Administration Guide in the WebSphere eXtreme Scale Version 7.0 information center: http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r0/index.jsp
Session Management Server High Availability Considerations

When deployed, the SMS is a critical Tivoli Access Manager component. Consequently, the SMS must have high availability. Otherwise, failure might cause the client to become unavailable for session operations. Availability improves if you run the SMS in a clustered environment consisting of at least two cluster members. If all cluster members become unavailable, the session data maintained by the SMS is lost and the SMS is no longer able to service any requests. In this case, the Web security clients (such as WebSEAL) cannot create new sessions. The availability of the SMS is determined by two separate components in the environment. The first component consists of the actual WebSphere Application Servers running an SMS instance and holding WebSphere eXtreme Scale containers. The second key component is the WebSphere eXtreme Scale catalog service
39
responsible for maintaining routing information for the SMS servers. It is important to consider the high availability of each component as part of an SMS deployment.
Hard failure detection

In a clustered environment, the SMS stores session data such that system operation is not affected by the loss of a single SMS server. You must tune the hard failure detection mechanism in the underlying WebSphere Application Server to optimize failure detection. Hard failure detection is a means of detecting a physical computer crash, network cable disconnect, or OS panic. WebSphere eXtreme Scale uses a heartbeat detection mechanism to detect hard failure events using the underlying WebSphere Application Server core group heartbeat functionality. Hard failure detection takes approximately 200 seconds in a default SMS configuration. This value is too large for the SMS to function correctly during a hard failure scenario. A hard failure must be detected in less than 20 seconds for the SMS to function as expected. Specify the heartbeat interval in seconds on WebSphere Application Server versions 6.0 through 6.1.0.12, and in milliseconds starting with version 6.1.0.13. You must also specify the number of missed heartbeats. This value indicates how many heartbeats can be missed before a peer JVM is considered failed. The hard failure detection time is approximately the product of the heartbeat interval and the number of missed heartbeats. Specify these properties using custom properties on the core group in the WebSphere administrative console. Consider network performance and reliability to tune these settings appropriately for the specific environment. When these settings are too aggressive, false failures are detected. However, if these settings are not aggressive enough, failures are not detected early enough for the system to recover in a suitable time frame. To update the core group settings for WebSphere Application Server Network Deployment Version 6.1: v Set IBM_CS_FD_PERIOD_MILLIS (WebSphere Application Server Network Deployment version 6.1.0.13 and later) v Set IBM_CS_FD_CONSECUTIVE_MISSED WebSphere Application Server Network Deployment version 7.0 provides the following two core group settings: v Heartbeat transmission period. v Heartbeat timeout period. These settings can be adjusted to increase or decrease failover detection. For further information about heartbeat detection in WebSphere Application Server, see "Core group heartbeat configuration" under the "Configuring failover detection" section in the WebSphere eXtreme Scale Administration Guide in the WebSphere eXtreme Scale Version 7.0 information center: http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r0/index.jsp
eXtreme Scale container JVMs

The eXtreme Scale container JVMs are the virtual machines that hold the SMS session data. The WebSphere Application Servers in the SMS cluster are also known as the eXtreme Scale Container JVMs.
40
Container failure
The SMS is designed such that when a container fails, any primaries held in that SMS server are promoted elsewhere in the SMS cluster. The SMS can withstand multiple container JVM failures before data loss occurs, provided at least one set of primaries for all maps remains available. The eXtreme Scale catalog service promotes and demotes containers according to the deployment parameters defined in the SMS. It is important however that container JVMs continue to maintain a connection to the catalog service. If a container JVM loses contact with the catalog service and then regains contact, the catalog service detects the failure. At this time, any containers held by the container JVM are dropped and placed on other servers. Under these conditions, the container JVM continues to act as an eXtreme Scale client, but you must manually restart the JVM to hold containers again. This behavior is designed to ensure consistency of the data across the cluster.
eXtreme Scale Catalog service

A catalog service is the grid of catalog servers you are using. You can run catalog servers inside WebSphere Application Server JVM processes or inside stand-alone JVM processes. These servers retain topology information for all the containers in your eXtreme Scale environment, which is the SMS deployment environment in this case. The catalog service controls balancing and routing for all clients and manages the promotion and demotion of containers from primaries to replicas. For eXtreme Scale to operate for the SMS, you must cluster the catalog servers into a grid for high availability. When the catalog service starts, it selects a master catalog server that is responsible for holding the master copy of all data in the catalog service. The master catalog server accepts Internet Inter-ORB Protocol (IIOP) heartbeats and handles system data changes in response to any catalog service or container changes. When clients contact any of the catalog servers, the routing table for the catalog server grid is propagated to the clients. This propagation occurs through the Common Object Request Broker Architecture (CORBA) service context. To ensure high availability, configure at least two catalog servers into a catalog service cluster. If your configuration has zones, you can configure one catalog server per zone. When an eXtreme Scale server and container contacts one of the catalog servers, the routing table for the catalog server grid is also propagated to the eXtreme Scale server and container. This propagation occurs through the CORBA service context. If the contacted catalog server is not currently the master catalog server, the request is automatically rerouted to the current master catalog server. The routing table for the catalog server is also updated. Note: A catalog server grid and the container server grid are different. The catalog server grid is for high availability of the eXtreme Scale system data. The container grid is meant for high availability, scalability, and workload management of the SMS application. Consequently, two different routing tables exist: v The routing table for the catalog server grid, and v The routing table for the server grid shards.
Running catalog servers inside WebSphere Application Server JVM processes

You can configure the WebSphere Application Server instances to run WebSphere eXtreme Scale catalog servers. You can configure the catalog service to run in any
41
process in the WebSphere cell. A single-server catalog service is acceptable for development environments. For a production environment, use a catalog service grid with multiple catalog servers. For WebSphere Application Server Network Deployment, the catalog service runs in the deployment manager process automatically. However, you can configure the catalog service to run in one or more application server processes. The WebSphere eXtreme Scale catalog service configuration is defined using a custom property called catalog.services.cluster in the WebSphere cell. For running the catalog service inside a WebSphere Application Server, use the following format for the value of this property:
<serverName>:<hostname>:<clientPort>:<peerPort>:<listenerPort> [,<serverName>:<hostname>:<clientPort>:<peerPort>:<listenerPort> ...]
where serverName Specifies the fully qualified name of the WebSphere process, such as the cellName, nodeName, and serverName of the server that hosts the catalog service. hostname Specifies the name of the hosting server. clientPort Specifies the port that is used for peer catalog grid communication. peerPort Specifies the port that is used for peer catalog grid communication and can be anything you choose in a WebSphere Application Server environment. listenerPort The listenerPort must match the BOOTSTRAP_ADDRESS value that is defined in the WebSphere server configuration. Example:
sms1Cell01\sms1CellManager01\dmgr:sms1.amtest.gc.au.ibm.com:6600:6601:9809, sms1Cell01\sms4Node02\catalogServer1:sms4.amtest.gc.au.ibm.com:6602:6603:2809
For more information, see "Starting the catalog service process in a WebSphere Application Server environment" in the WebSphere eXtreme Scale Administration Guide, which is located in the WebSphere eXtreme Scale Version 7.0 information center: http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r0/index.jsp
Running catalog servers inside stand-alone JVMs

Depending on the architecture of an SMS deployment, you can choose to run the catalog servers inside stand-alone JVMs rather than inside WebSphere Application Servers. You must define a WebSphere Application Server cell custom property called catalog.services.cluster so that the WebSphere eXtreme Scale container servers can contact the catalog service. For catalog servers running inside stand-alone JVMs, use the following format to specify the value of this property:
<serverName>:<hostname>:<clientPort>:<peerPort>[,<serverName>:<hostname>: <clientPort>:<peerPort>...]
42
where serverName Specifies a name to identify the process that you are launching. hostname Specifies the host name of the computer where the server is launched. clientPort Specifies the port that you are using for peer catalog grid communication. peerPort Specifies the port that you are using for peer catalog grid communication. Example:
cat1:sms-multicell01.vam.gc.au.ibm.com:6602:6603:2809,cat2 :sms-multicell02.vam.gc.au.ibm.com:6602:6603:2809
The catalog service can run in a single process or can include multiple catalog servers to form the catalog server grid. For high availability, a production environment requires a catalog server grid. Whether the catalog service is placed in a grid or a single process, you can start the service using the startOgServer script. For more information, see "Starting the catalog service in a stand-alone environment" in the IBM WebSphere eXtreme Scale Administration Guide, which is located in the WebSphere eXtreme Scale Version 7.0 information center: http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r0/index.jsp
Catalog service failure

The catalog service grid is an eXtreme Scale grid so it uses the core grouping mechanism in the same way as the container failure process. The primary difference is that the catalog service grid uses a peer election process to define the primary shard instead of the catalog service algorithm used for containers. Catalog service members must be contained in the same core group. However, the catalog service core group need not be the same as the core group where the SMS servers are located. The catalog service uses replication to make itself fault-tolerant. If a catalog service process fails, restart the service to restore the system to the desired level of availability. If all the processes that are hosting the catalog service fail, eXtreme Scale loses critical data. This failure results in a required restart of all the containers. The catalog service can run on many processes so this failure is an unlikely event. However, a failure is more likely to occur if you are running all the processes on a single box, in a single blade chassis, or from a single network switch. Try to remove common failure modes from boxes that are hosting the catalog service to reduce the possibility of failure.
Catalog service quorum behavior

Normally, the members of the catalog service have full connectivity. The catalog service grid is a static set of JVMs. WebSphere eXtreme Scale expects all members of the catalog service to be online at all times. The catalog service only responds to container events while the catalog service has quorum. If the catalog service loses quorum, it waits for quorum to be reestablished. When the catalog service does not have quorum, it ignores events such as failures from container servers.
43
The following message indicates that quorum is lost. Look for this message in your catalog service logs.
CWOBJ1254W: The catalog service is waiting for quorum.
WebSphere eXtreme Scale expects to lose quorum in the following situations: v Catalog service JVM member failure v Network brownout v Loss of connectivity between zones In terms of the SMS, lost quorum in the catalog service does not affect service. The Web security server environment continues to operate during quorum loss provided no container server loss occurs.
Quorum loss from JVM failure

A catalog server that fails due to a crash causes quorum to be lost. In this event, manually override quorum as quickly as possible. The failed catalog service cannot rejoin the grid until you manually override quorum. For further information about overriding quorum, see Overriding quorum on page 47.
Quorum loss from network brownout

WebSphere eXtreme Scale handles the possibility of brownouts. A brownout is temporary loss of connectivity between nodes. This loss of connectivity is generally transient and brownouts typically clear in a matter of seconds or minutes. WebSphere eXtreme Scale tries to maintain normal operation during a brownout period. However, WebSphere eXtreme Scale regards a brownout as a single failure event. The failure is expected to be fixed and then normal operation resumes with no WebSphere eXtreme Scale actions necessary. During a brownout, if quorum is lost in the catalog service and SMS servers are disconnected from one another, sessions can no longer be stored. After the brownout clears, normal operation resumes.
Catalog service JVM cycling

If you stop a catalog server by stopping the JVM that it is running in, then the quorum drops to one less server. This means that the remaining servers still have quorum. Restarting the catalog server restores quorum to the previous number.
Consequences of lost quorum

If a container JVM fails while quorum is lost in the catalog service, recovery does not take place until the brownout or blackout ends. To recover from a blackout, perform a manual override quorum command. WebSphere eXtreme Scale considers a quorum loss event and a container failure as a double failure, which is a rare event. Until quorum is restored and normal recovery can take place, applications such as the SMS might lose write access to data that was stored on the failed JVM. In the context of a Tivoli Access Manager Web security server environment, this double failure means that sessions cannot be stored in the SMS. Similarly, if you attempt to start a container during a quorum loss event, the container does not start. This means that if you try to start an SMS server during quorum loss, the SMS server does not start properly. Full client connectivity is allowed during quorum loss. If no container failures or connectivity issues happen during the quorum loss event, then clients can still
44
fully interact with the container servers. As a result, the SMS can store and access sessions during quorum loss provided no SMS servers fail, or become noncommunicable, at the same time. If a brownout occurs, then some clients might not have access to primary or replica copies of the data until the brownout clears. Under some brownout conditions, the SMS can continue to perform session operations, depending on the primaries available to the particular server at the time.
Quorum recovery
If quorum is lost and reestablished, a recovery protocol is executed by the catalog service. When the quorum loss event occurs, all liveness checking for core groups is suspended and failure reports are also ignored. When quorum returns, the catalog service performs a liveness check of all core groups to immediately determine their membership. Any shards previously hosted on container JVMs that reportedly failed are recovered. If primary shards were lost then surviving replicas are promoted to primaries. If replica shards were lost, then additional replicas are created on the survivors. For the SMS, this recovery process means that no session data is lost. However, a significant number of SMS server failures might cause data loss.
Failure scenarios
This section describes scenarios where significant failures lead to loss of service for the SMS and the Web security server environment. The following diagram illustrates an example SMS deployment.
45
WebSphere Application Server ND Cell SMS Cluster Deployment Manager SMS SMS Server 2 Server 1 DSess WebSphere Application Server Catalog Server 1 WebSphere Application Server Catalog Server 2
eXtreme Scale Grid View Session Data Session Index Data Clients Config Keys
Figure 10. Session Management Server Deployment
46
Multiple container loss

Multiple container failures might cause loss of data held in the SMS. Container failures can lead to a situation where the SMS cannot store sessions. The likelihood of losing enough containers to impact service is minimal due to the underlying replication and the placement of synchronous and asynchronous replicas that eXtreme Scale provides. An example of this failure is when both 'SMS Server 1' and 'SMS Server 2' fail. See Figure 10 on page 46. To mitigate the risk of multiple container failures causing service loss, add additional SMS servers to the cluster. During configuration, you can calculate the number of containers needed based on the size of the cluster. Additional servers in the environment result in the creation of more containers, thus reducing the risk of critical data loss.
Loss of all catalog servers

If all catalog servers fail, the SMS continues to function. However, the SMS has limited ability to cope with container failures. When the catalog service is restored after being offline, the SMS JVMs cannot hold containers. Consequently the SMS cannot store sessions. It is important that catalog servers are on separate hardware from container servers. This separation prevents the hardware failure of a specific computer being a single point of failure. An example of this failure is when both 'Catalog server 1' and 'Catalog server 2' fail. See Figure 10 on page 46. Note: The system can continue to operate in this mode. However, when the catalog service becomes available again, there is no guarantee that data is not lost or that any SMS servers hold primaries until they are restarted. Cluster the catalog service to reduce the risk of losing the entire catalog service.
Container & catalog server loss

While a container server and catalog server are both lost, the SMS cannot service requests. It is important that this failure is either mitigated or recovered from quickly to ensure continual service to the Tivoli Access Manager Web Security Servers. An example of this failure is when both 'SMS Server 1' and 'Catalog server 1' fail. See Figure 10 on page 46. To mitigate this risk, configure separate nodes for each SMS server and catalog service, and ensure that redundant links exist between nodes.
Recovery procedures
Manual intervention is required to recover from a brownout or a blackout where a catalog service member and a container JVM are lost. This process involves overriding quorum on one side of the brownout or blackout. After the brownout or blackout clears and service resumes, restart the SMS and catalog servers located on the other side of the brownout or blackout.
Overriding quorum
Quorum is an important concept in an eXtreme Scale environment. When quorum is established, the grid can detect and continue functioning after network brownouts.
47
To enable quorum within the catalog service cluster in a WebSphere Application Server environment: v Create a file objectGridServer.properties in the <WAS_HOME>\profiles\ <profile>\properties directory of each clustered catalog service member. v Specify the following entry in this file:
enableQuorum=true
To enable quorum in the catalog service cluster in a stand-alone JVM environment, you can do either of the following: v Pass the -quorum enabled flag on the startOgServer command. v Add the enableQuorum=true property in the property file passed in to the startOgServer command. All the catalog servers must have the same quorum setting. If a hard failure leads to the loss of a catalog service member and an SMS node, you must manually override quorum to reestablish service. If the loss is due to a network brownout, quorum is reestablished without any manual intervention when the brownout clears. You must manually intervene if the brownout or loss is permanent. You can use the xsadmin command-line tool to override quorum. This process enables the catalog service to promote eXtreme Scale replicas to primaries and enables the SMS to become fully functional again. The command to override quorum is as follows. On a catalog server that is not the Deployment Manager:
> xsadmin.sh -ch <cathost> -p <port> -overridequorum
where cathost The host of the catalog server where quorum is to be over-ridden. port The port of the catalog server (typically 9809 in a WebSphere Application Server Network Deployment environment).
On a catalog server that is the Deployment Manager:

> xsadmin.sh -dmgr -overridequorum
For more information about overriding quorum in a clustered catalog service, see "Catalog server quorums" in the WebSphere eXtreme Scale Product Overview, located in the WebSphere eXtreme Scale Version 7.0 information center: http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r0/index.jsp
48
Appendix A. SMS pdsmsadmin and pdadmin commands

The pdsmsadmin and pdadmin command line utilities can be installed as part of the Tivoli Access Manager package. Use these interfaces to manage access control lists, groups, servers, users, objects, and other resources in your secure domain. You can also automate certain management functions by writing API scripts that use the pdadmincommands, which include an optional delimiter to specify session management server instances.
Reading syntax statements

The reference documentation uses the following special characters to define syntax: [] ... | Identifies optional syntax. Options not enclosed in brackets are required. Indicates that you can specify multiple values for the previous option. Indicates mutually exclusive information. You can use the option to the left of the separator or the option to the right of the separator. You cannot use both options in a single use of the command. Delimits a set of mutually exclusive options when one of the options is required. If the options are optional, they are enclosed in brackets ([ ]). Indicates that the command line wraps to the next line. It is a continuation character.
{} \
The options for each command or utility are listed alphabetically in the Options section or Parameters section, respectively. When the order of the options or parameters must be used in a specific order, this order is shown in the syntax statements.
49
login
Logs user in to pdsmsadmin or pdadmin command line. If a password is not provided, you will be prompted for it.
Syntax
PDSMSADMIN login username [password] PDADMIN login -a username -p [password]
Options
user Specifies the user name. password Specifies the user password.
Return codes
0 1 The command completed successfully. The command failed. When a command fails, the pdsmsadmin command provides a description of the error and an error status code in hexadecimal format (for example, 0x14c012f2). Refer to the IBM Tivoli Access Manager for e-business: Error Message Reference. This reference provides a list of the Tivoli Access Manager error messages by decimal or hexadecimal codes.
Examples
The following example logs a user named user1 with a password of passw0rd in to the pdsmsadmin command line:
pdsmsadmin> login user1 passw0rd
See also
trace get
50
set instance
Sets the current instance, allowing you to swap from one instance to another to perform administrative tasks.
Syntax
PDSMSADMIN set instance instance PDADMIN Not available: the [.instance] delimiter can optionally be specified as part of pdadmin commands. If not specified, the first available instance is used.
Options
instance Specifies the name of the server instance to be set.
Return codes
Examples
The following example sets instance1 as the current instance:
pdsmsadmin> set instance instance1
See also
trace get
51
instances list
Lists all available instances.
Syntax
PDSMSADMIN instances list PDADMIN instances list
Options
NIL No parameters required.
Return codes
Examples
The following example lists all available instances:
pdsmsadmin> instances list
See also
trace get
52
server list
Lists all registered Tivoli Access Manager servers. Requires authentication (administrator ID and password) to use this command.
Syntax
PDSMSADMIN Not available. PDADMIN server list
Description
Lists all registered Tivoli Access Manager servers. The name of the server for all server commands, except for the server list command, must be entered in the exact format as it is displayed in the output of this command.
Options
None.
Return codes
0 1 The command completed successfully. The command failed. When a command fails, the pdsmsadmin or pdadmin command provides a description of the error and an error status code in hexadecimal format (for example, 0x14c012f2). Refer to the IBM Tivoli Access Manager for e-business: Error Message Reference. This reference provides a list of the Tivoli Access Manager error messages by decimal or hexadecimal codes.
Examples
The following example lists all registered servers if the Tivoli Access Manager component is the authorization server:
pdadmin> server list
Output is similar to:

ivacld-topserver ivacld-server2 ivacld-server3 ivacld-server4
53
key change
Forces the creation of a new session management key. You might want to forcibly create a new key when you suspect that the existing key was compromised.
Syntax
PDSMSADMIN key change PDADMIN server task server_namehost_name sms[.instance] key change
Options
server_namehost_name Specifies the name of the server or server instance. You must specify the server name in the exact format as it is shown in the output of the server list command. For example, if the configured name of a single WebSEAL server on host cruz.dallas.ibm.com is default, the server_name would be default-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server would be default-websealdcruz.dallas.ibm.com. If there are multiple configured server instances on the same machine, for example, the host cruz.dallas.ibm.com, and the configured name of the WebSEAL server instance is webseal2-webseald, the server_name would be webseal2-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server instance would be webseal2-webseald-cruz.dallas.ibm.com. The [.instance] delimiter is optional in pdadmin. If not specified, the first available instance is used.
Return codes
Notes
The pdadmin command is available only when the session management command line extensions are installed to a hosting authorization server.
Examples
The following example forcibly creates a new session management key for the abc.ibm.com server:
pdsmsadmin> key change pdadmin> server task default-webseald-abc.ibm.com key change
54
key change
See also
server list key show
55
key show
Lists detailed information about the current session management key.
Syntax
PDSMSADMIN key show PDADMIN server task server_namehost_name sms[.instance] key show
Options
Return codes
Notes
Examples
The following example returns detailed information about the current session management key for the abc.ibm.com server:
pdsmsadmin> key show pdadmin> server task default-webseald-abc.ibm.com sms key show
Output is similar to:
56
key show
ID: 1 Created: 2004-03-03-09:00:03 Expires: 2004-09-03-09:00:03
See also
server list key change
57
realm list
Lists all session management realms in the domain.
Syntax
PDSMSADMIN realm list PDADMIN server task server_namehost_name sms[.instance] realm list
Options
Return codes
Notes
Examples
The following example lists the realms for the abc.ibm.com server:
pdsmsadmin> realm list pdadmin> server task default-webseald-abc.ibm.com sms realm list
58
realm list
See also
server list realm show replica set list replica set show
59
realm show
Lists all replica sets in the specified session management realm.
Syntax
PDSMSADMIN realm show realm_name PDADMIN server task server_namehost_name sms[.instance] realm show realm_name
Options
realm_name Specifies the name of the realm. When you specify a realm, the output contains only those replica sets in that realm. server_namehost_name Specifies the name of the server or server instance. You must specify the server name in the exact format as it is shown in the output of the server list command. For example, if the configured name of a single WebSEAL server on host cruz.dallas.ibm.com is default, the server_name would be default-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server would be default-websealdcruz.dallas.ibm.com. If there are multiple configured server instances on the same machine, for example, the host cruz.dallas.ibm.com, and the configured name of the WebSEAL server instance is webseal2-webseald, the server_name would be webseal2-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server instance would be webseal2-webseald-cruz.dallas.ibm.com. The [.instance] delimiter is optional in pdadmin. If not specified, the first available instance is used.
Return codes
Notes
Examples
The following example returns the replica sets in the ibm.com realm of the abc.ibm.com server:
pdsmsadmin> realm show ibm.com
60
realm show
pdadmin> server task default-webseald-abc.ibm.com sms realm show ibm.com
See also
server list realm list replica set list replica set show
61
session refresh all_sessions

Refreshes the credential for sessions for a specific user.
Syntax
PDSMSADMIN session refresh all_sessions user_name realm realm_name PDADMIN server task server_namehost_name sms[.instance] session refresh all_sessions user_name realm realm_name
Options
realm realm_name Specifies that name of the realm. Only sessions that belong to the specified realm will have credentials refreshed. server_namehost_name Specifies the name of the server or server instance. You must specify the server name in the exact format as it is shown in the output of the server list command. For example, if the configured name of a single WebSEAL server on host cruz.dallas.ibm.com is default, the server_name would be default-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server would be default-websealdcruz.dallas.ibm.com. If there are multiple configured server instances on the same machine, for example, the host cruz.dallas.ibm.com, and the configured name of the WebSEAL server instance is webseal2-webseald, the server_name would be webseal2-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server instance would be webseal2-webseald-cruz.dallas.ibm.com. user_name Refreshes the credential for all sessions that are associated with the specified user. Examples of user names are dlucas, sec_master, and Mary Jones". [.instance] This delimiter is optional in pdadmin. If not specified, the first available instance is used.
Return codes
62
session refresh all_sessions
Notes
Examples
The following example refreshes all sessions for user johnq in the ibm.com realm:
pdsmsadmin> session refresh all_sessions johnq -realm ibm.com pdadmin> server task default-webseald-cruz sms session refresh all_sessions johnq -realm ibm.com
See also
session terminate session session terminate all_sessions
63
session refresh session

Refreshes the credential for a session.
Syntax
PDSMSADMIN session refresh session session_id realm realm_name PDADMIN server task server_namehost_name sms[.instance] session refresh session session_id realm realm_name
Options
realm realm_name Specifies that name of the realm. Only sessions that belong to the specified realm will have credentials refreshed. server_namehost_name Specifies the name of the server or server instance. You must specify the server name in the exact format as it is shown in the output of the server list command. For example, if the configured name of a single WebSEAL server on host cruz.dallas.ibm.com is default, the server_name would be default-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server would be default-websealdcruz.dallas.ibm.com. If there are multiple configured server instances on the same machine, for example, the host cruz.dallas.ibm.com, and the configured name of the WebSEAL server instance is webseal2-webseald, the server_name would be webseal2-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server instance would be webseal2-webseald-cruz.dallas.ibm.com. The [.instance] delimiter is optional in pdadmin. If not specified, the first available instance is used. session_id Specifies the identifier for the session to refresh.
Return codes
Notes
64
session refresh session
Examples
The following example refreshes session 678 in the ibm.com realm:
pdsmsadmin> session refresh session 678 -realm ibm.com pdadmin> server task default-webseald-cruz sms session refresh session 678 -realm ibm.com
See also
session terminate session session terminate all_sessions
65
replica set list

Lists all session management replica sets in the domain.
Syntax
PDSMSADMIN replica set list [realm realm_name] PDADMIN server task server_namehost_name sms[.instance] replica set list [realm realm_name]
Options
realm realm_name Indicates that the returned list of replica sets is limited to those replica sets in the specified realm. server_namehost_name Specifies the name of the server or server instance. You must specify the server name in the exact format as it is shown in the output of the server list command. For example, if the configured name of a single WebSEAL server on host cruz.dallas.ibm.com is default, the server_name would be default-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server would be default-websealdcruz.dallas.ibm.com. If there are multiple configured server instances on the same machine, for example, the host cruz.dallas.ibm.com, and the configured name of the WebSEAL server instance is webseal2-webseald, the server_name would be webseal2-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server instance would be webseal2-webseald-cruz.dallas.ibm.com. The [.instance] delimiter is optional in pdadmin. If not specified, the first available instance is used.
Return codes
Notes
Examples
The following example lists the replica sets in the ibm realm of the abc.ibm.com server:
66
replica set list

pdsmsadmin> replica set list -realm ibm pdadmin> server task default-webseald-abc.ibm.com sms replica set list -realm ibm
See also
server list realm list realm show replica set show
67
replica set show

Lists all session management replicas in the specified replica set with the time and date that each joined the realm.
Syntax
PDSMSADMIN replica set show replica_set_name PDADMIN server task server_namehost_name sms[.instance] replica set show replica_set_name
Options
replica_set_name Specifies the name of the replica set. server_namehost_name Specifies the name of the server or server instance. You must specify the server name in the exact format as it is shown in the output of the server list command. For example, if the configured name of a single WebSEAL server on host cruz.dallas.ibm.com is default, the server_name would be default-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server would be default-websealdcruz.dallas.ibm.com. If there are multiple configured server instances on the same machine, for example, the host cruz.dallas.ibm.com, and the configured name of the WebSEAL server instance is webseal2-webseald, the server_name would be webseal2-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server instance would be webseal2-webseald-cruz.dallas.ibm.com. The [.instance] delimiter is optional in pdadmin. If not specified, the first available instance is used.
Return codes
Notes
Examples
The following example returns details about the ibm.com replica set of the abc.ibm.com server:
68
replica set show

pdsmsadmin> replica set show ibm.com pdadmin> server task default-webseald-abc.ibm.com sms replica set show ibm.com
See also
server list realm list realm show replica set list
69
session list
Lists all session management sessions.
Syntax
PDSMSADMIN session list realm realm_name pattern maximum_return PDADMIN server task server_namehost_name sms[.instance] session list realm realm_name pattern maximum_return
Options
realm realm_name Specifies the name of the session management realm. server_namehost_name Specifies the name of the server or server instance. You must specify the server name in the exact format as it is shown in the output of the server list command. For example, if the configured name of a single WebSEAL server on host cruz.dallas.ibm.com is default, the server_name would be default-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server would be default-websealdcruz.dallas.ibm.com. If there are multiple configured server instances on the same machine, for example, the host cruz.dallas.ibm.com, and the configured name of the WebSEAL server instance is webseal2-webseald, the server_name would be webseal2-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server instance would be webseal2-webseald-cruz.dallas.ibm.com. maximum_return Specifies the maximum number of sessions to return. When there are more matches than designated by this option, the output contains the number of matches. pattern Specifies the pattern for returning user names. The pattern can include a combination of wild card and string constant characters. The pattern is case-sensitive. For example, you can specify *luca* as the pattern to find all users that contain the substring luca in the user name. [.instance] This delimiter is optional in pdadmin. If not specified, the first available instance is used.
Return codes
70
session list
Notes
Examples
The following example (entered as one line) lists the user sessions in the ibm.com realm of the abc.ibm.com server for users that contains the string ons and limits the number of matches to 100:
pdsmsadmin> session list -realm ibm.com *ons* 100 pdadmin> server task default-webseald-abc.ibm.com sms session list -realm ibm.com *ons* 100
See also
server list realm list realm show replica set show
71
session terminate all_sessions

Terminates all user sessions for a specific user.
Syntax
PDSMSADMIN session terminate all_sessions user_id realm realm_name PDADMIN server task server_namehost_name sms[.instance] session terminate all_sessions user_id realm realm_name
Options
realm realm_name Specifies that name of the session management realm. server_namehost_name Specifies the name of the server or server instance. You must specify the server name in the exact format as it is shown in the output of the server list command. For example, if the configured name of a single WebSEAL server on host cruz.dallas.ibm.com is default, the server_name would be default-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server would be default-websealdcruz.dallas.ibm.com. If there are multiple configured server instances on the same machine, for example, the host cruz.dallas.ibm.com, and the configured name of the WebSEAL server instance is webseal2-webseald, the server_name would be webseal2-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server instance would be webseal2-webseald-cruz.dallas.ibm.com. The [.instance] delimiter is optional in pdadmin. If not specified, the first available instance is used. user_id Specifies the name of the user. Examples of user names are dlucas, sec_master, and "Mary Jones".
Return codes
Notes
72
session terminate all_sessions
Examples
The following example terminates all sessions for the dlucas user in the ibm.com realm of the default-webseald-cruz WebSEAL server:
pdsmsadmin> session terminate all_sessions dlucas -realm ibm.com pdadmin> server task default-webseald-cruz sms session terminate \ all_sessions dlucas -realm ibm.com
See also
session refresh session session refresh all_sessions session terminate session
73
session terminate session

Terminates a user session using a session ID.
Syntax
PDSMSADMIN session terminate session session_id realm realm_name PDADMIN server task server_namehost_name sms[.instance] session terminate session session_id realm realm_name
Options
server_namehost_name Specifies the name of the server or server instance. You must specify the server name in the exact format as it is shown in the output of the server list command. For example, if the configured name of a single WebSEAL server on host cruz.dallas.ibm.com is default, the server_name would be default-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server would be default-websealdcruz.dallas.ibm.com. If there are multiple configured server instances on the same machine, for example, the host cruz.dallas.ibm.com, and the configured name of the WebSEAL server instance is webseal2-webseald, the server_name would be webseal2-webseald and the host_name would be cruz.dallas.ibm.com. For this example, the name of the server instance would be webseal2-webseald-cruz.dallas.ibm.com. The [.instance] delimiter is optional in pdadmin. If not specified, the first available instance is used. session_id Specifies the ID of a user session.
Return codes
Notes
Examples
The following example terminates session 678 in the ibm.com realm of the default-webseald-cruz WebSEAL server:
pdsmsadmin> session terminate session 678 -realm ibm.com
74
session terminate session

pdadmin> server task default-webseald-cruz sms session terminate \ session 678 -realm ibm.com
See also
session refresh all_sessions session terminate all_sessions
75
trace get
Displays the trace level for the session management server. The recommended way to do this in version 6.1 is with the ISC, using standard WebSphere tracing facilities, which provide more fine-grained detail.
Syntax
PDSMSADMIN trace get PDADMIN server task server_namehost_name sms[.instance] trace get
Options
Return codes
Notes
Examples
The following example returns the tracing level for the ivacld-cruz authorization server:
pdsmsadmin> trace get pdadmin> server task ivacld-cruz.dallas.ibm.com sms trace get
76
trace get
See also
trace set
77
trace set
Sets the trace level for the session management server. The recommended way to do this in version 6.1 is with the ISC, using standard WebSphere tracing facilities, which provide more fine-grained detail.
Syntax
PDSMSADMIN trace set level PDADMIN server task server_namehost_name sms[.instance] trace set level
Options
level Specifies the level of tracing. A valid setting is an integer between 0 and 3, with 3 being the most detailed level of trace.
Return codes
Notes
Examples
The following example sets the tracing level to 1 on the ivacld-cruz authorization server:
78
trace set
pdsmsadmin> trace set 1 pdadmin> server task ivacld-cruz.dallas.ibm.com sms trace set 1
See also
trace get
79
80
Appendix B. SMS utilities
81
pdsmsclicfg
Configures the command line administration utility for the session management server.
Syntax
pdsmsclicfg action config [rspfile response_file] [interactive {yes|no}] [tam_integration {yes|no}] [aznapi_app_config_file path_name] [webservice_location host:port[,host:port...]] [instances name1,name2] [-ssl_enable {yes|no}] [sslkeyfile path] [sslkeyfile_stash path] [sslkeyfile_label label] pdsmsclicfg action unconfig pdsmsclicfg action name pdsmsclicfg action version pdsmsclicfg action upgrade
Description
The pdsmsclicfg utility configures or unconfigures the session management server command line administration utility. A log of the configuration progress is written to the msg_pdsmsclicfg.log log file, which is located in the /var/pdsms/log directory on Linux and UNIX operating systems and in the installation_directory\ log directory on Windows operating systems. This utility can be run either interactively, where the user is prompted to provide configuration information, or silently, where the utility accepts input from a response file or the command line. If integration with Tivoli Access Manager is enabled during configuration, the program prompts the user to specify the path to the configuration file for an already configured aznapi application. The program prompts the user to specify the location of the Web service. The location of the Web service is defined by a host name and port that are separated by a semicolon. The user can specify multiple locations, when each location is separated by a comma. If this Web service uses a secure connection, the program prompts the user for the SSL options. You must also specify the session management server instance(s). The configuration information is saved to /opt/pdsms/etc/pdsmsclicfg.conf. The presence of this configuration file is used to determine the configuration status of the utility. The command line executable on Windows is pdsmsclicfg-cl.exe.
Parameters
action {config|unconfig|upgrade|name|version} Specifies the action to be performed that is one of the following values: config Configures the command line administration utility. unconfig Fully unconfigures the command line administration utility. No other parameters are required.
82
pdsmsclicfg
name Displays the translated "Session Management Command Line" name. No other options are required.
upgrade Performs a configuration upgrade from a previous version. version Displays the version number for the currently installed SMS CLI package. rspfile response_file Specifies the fully qualified path and file name of the response file to use during silent configuration. A response file can be used for configuration. There is no default response file name. The response file contains stanzas and parameter=value pairs. To use response files, see the procedures in the IBM Tivoli Access Manager for e-business: Installation Guide. interactive {yes|no} Indicates whether the configuration is interactive. The default value is yes. tam_integration {yes|no} Specifies whether integration with the Tivoli Access Manager administration framework is required. The default value is no. aznapi_app_config_file path_name Specifies the fully qualified name of the configuration file for the hosting authorization server. Only required if Tivoli Access Manager integration is enabled. webservice_location host:port Specifies the location of the session management server Administration Web service. The location is the name of the hosting server and the port on which the Web service resides. Multiple locations can be specified. When specifying multiple locations, separate the locations with commas. instances name1,name2 The session management server instances which are to be administered. The instance names should be separated by a comma. The default value is DSess. ssl_enable {yes|no} Indicates whether SSL communication with the Web server should be enabled. sslkeyfile path Specifies the fully qualified name of the SSL key file to use when communicating with the session management server Web service. Use this parameter only when the ssl_enable parameter is set to yes. sslkeyfile_label label Specifies the SSL key file label of the certificate to be used. Use this parameter only when the ssl_enable parameter is set to yes. sslkeyfile_stash path Specifies the fully qualified name of the stash file that contains the password for the SSL key file. Use this parameter only when the ssl_enable parameter is set to yes.
Availability
This utility is located in one of the following default installation directories: v On Linux and UNIX operating systems:
83
pdsmsclicfg
/opt/pdsms/bin
v On Windows operating systems:

c:\Program Files\Tivoli\PDSMS\bin
To invoke the command line under Windows, use pdsmsclicfg-cl.exe. The pdsmsclicfg command will invoke the wizard. When an installation directory other than the default is selected, this utility is located in the /bin directory under the installation directory (for example, installation_directory/bin).
Return codes
0 The utility completed successfully. non-zero The utility failed. When a utility fails, a description of the error and an error status code in hexadecimal format is provided (for example, 0x15c3a00c). Refer to the IBM Tivoli Access Manager for e-business: Error Message Reference. This reference provides a list of the Tivoli Access Manager error messages by decimal or hexadecimal codes.
84
smsbackup
Gathers information to help IBM Software Support in problem determination. Note: This utility is for use by support personnel.
Syntax
For local mode smsbackup local [was_home path] [list list] [path output] For remote mode smsbackup [was_home path] [wsadmin_options options] [list list] [path output]
Description
The smsbackup gathers information to help IBM Software Support in problem determination. It has two modes: Local mode Gathers information from the local system only. Does not require an operational WebSphere environment. To gather information about all members in the cluster, run the utility on each node in the cluster. Remote mode Gathers information about the entire environment. Requires an operational WebSphere environment. The utility is provided on Linux and UNIX operating systems as a shell script, smsbackup.sh. On Windows operating systems, it is provided as a batch script, smsbackup.bat. When running the utility in local mode, you need to copy the following files to each member in the cluster, maintaining directory structure: v /bin/smsbackup.sh v /bin/smsbackup.bat v /etc/smsbackup.lst v /lib/smscfg.jar v /nls/java/message.jar
Parameters
local Indicates that the utility runs in local mode. list list Specifies the .lst file that describes the information to gather. If not specified, the smsbackup.lst file in the sms_installation_directory/etc directory is used. path output Specifies the directory for the created JAR file. The JAR file contains the gathered information. was_home path Specifies the home directory of the WebSphere Application Server. This value must be set on the command line or in the WAS_HOME environment variable.
85
smsbackup
wsadmin_options options Specifies options to pass directory to the wsadmin utility. Use this parameter to pass non-default binding information before running the backup operation through the WebSphere cluster. Examples of non-default binding information include the user name, password, and so forth.
Availability
/opt/pdsms/bin

When an installation directory other than the default is selected, this utility is located in the /bin directory under the installation directory (for example, installation_directory/bin).
Return codes
86
smscfg
Deploys and configures the session management server.
Syntax
smscfg action {config|unconfig|deploy|undeploy|extract|upgrade|revert|} Configuration smscfg action config [interactive {yes|no}] [rsp_file file_name] [record file_name] [was_port port] [was_enable_security {yes|no}] [was_admin_id administrator_id] [was_admin_pwd password] [trust_store file_name] [trust_store_pwd password] [keyfile file_name] [key_pwd password] [instance instance_name] [enable_session_limit_policy {yes|no}] [session_realm realm:max_login=replica_set1_name,replica_set2_name,...] [session_realm_remove realm_name] [enable_tcd {yes|no}] [tcd fully_qualified_directory_name] [enable_tam_integration {yes|no}] [policysvr_host host_name] [policysvr_port port] [admin_id administrator_id] [admin_pwd password] [domain domain] [authzsvr host_name:port:rank] [cred_refresh_rule rule] [enable_last_login {yes|no}][enable_last_login_database {yes|no}] [last_login_table last_login_database_table_name] [last_login_max_entries max_number_memory_entries] [last_login_jsp_file file_name] [last_login_jsp server_jsp_name][enable_database_session_storage {yes|no}][enable_auditing {yes|no}][auditing_properties file_name][key_lifetime key_lifetime] [client_idle_timeout timeout] Configuration with response file smscfg action config rspfile file_name Configuration, interactive smscfg action config interactive Unconfiguration smscfg action unconfig [interactive {yes|no}] [rspfile file_name] [record file_name] [was_port port] [was_enable_security {yes|no}] [was_admin_id administrator_id] [was_admin_pwd password] [trust_store file_name] [trust_store_pwd password] [keyfile file_name] [key_pwd password] [instance instance_name] [admin_id administrator_id] [admin_pwd password] [remove_last_login_db {yes|no}] Unconfiguration, response file smscfg action unconfig rspfile file_name Unconfiguration, interactive smscfg action unconfig interactive Deployment smscfg action deploy [interactive {yes|no}] [rspfile file_name] [record file_name] [was_port port] [was_enable_security {yes|no}] [was_admin_id administrator_id] [was_admin_pwd password] [trust_store file_name] [trust_store_pwd password] [keyfile file_name] [key_pwd password] [instance instance_name] [enable_database_storage {yes|no}][database_name database_name][virtual_host host_name] [clustered {yes|no}] [was_node node_name] [was_server server_name] [was_cluster cluster_name] Undeployment smscfg action undeploy [interactive {yes|no}] [rspfile file_name]
87
smscfg
[record file_name] [was_port port] [was_enable_security {yes|no}] [was_admin_id administrator_id] [was_admin_pwd password] [trust_store file_name] [trust_store_pwd password] [keyfile file_name] [key_pwd password] [instance instance_name] Extract smscfg action extract [interactive {yes|no}] [rspfile file_name] [record file_name] [was_port port] [was_enable_security {yes|no}] [was_admin_id administrator_id] [was_admin_pwd password] [trust_store file_name] [trust_store_pwd password] [keyfile file_name] [key_pwd password] [instance instance_name] Upgrade smscfg action upgrade [interactive {yes|no}] [rspfile file_name] [record file_name] [was_port port] [was_enable_security {yes|no}] [was_admin_id administrator_id] [was_admin_pwd password] [trust_store file_name] [trust_store_pwd password] [keyfile file_name] [key_pwd password] [instance instance_name] Revert smscfg action revert [interactive {yes|no}] [rspfile file_name] [record file_name] [was_port port] [was_enable_security {yes|no}] [was_admin_id administrator_id] [was_admin_pwd password] [trust_store file_name] [trust_store_pwd password] [keyfile file_name] [key_pwd password] [instance instance_name] Utility help smscfg help option smscfg usage smscfg ?
Description
The smscfg utility deploys, configures or unconfigures session management server instances. It can also be used to extract the session management server configuration, or to install and remove fixpack upgrades. A log of the configuration progress is written to msg_smscfg.log log file that is located in the /var/pdsms/log directory on Linux and UNIX operating systems and in the installation_directory\log directory on Windows operating systems. This utility can be run either interactively, where the user is prompted to provide configuration information, or silently, where the utility accepts input from a response file.
Parameters
? Displays the syntax and an example for this utility. action {deploy|config|unconfig|undeploy|extract} Specifies the action to be performed that is one of the following values: deploy Deploys the session management server instance to a WebSphere Application Server. undeploy Removes a session management server instance from a WebSphere Application Server.
88
smscfg
config Configures or reconfigures a deployed session management server instance. unconfig Unconfigures a session management server instance. extract Extracts the configuration information from a session management server instance. upgrade Upgrades to a new session management server fixpack. revert Reverts to the previous session management server fixpack. admin_id administrator_id Specifies the Tivoli Access Manager administration ID. The default value is sec_master. This parameter is required when enable_tam_integration is set to yes. admin_pwd password Specifies the password for the Tivoli Access Manager administrator. This parameter is required when you specify the admin_id parameter. auditing_properties file_name Specifies the path to the properties file which contains the configuration of the auditing component. authzsvr host_name:port:rank Specifies the host name, port number, and rank of the Tivoli Access Manager authorization server. This optional parameter can be specified multiple times. A Tivoli Access Manager authorization server is required to use these session refresh capabilities or to use certificates that are issued by the Tivoli Access Manager policy server to authenticate session management clients. The default value is localhost:7136:1. client_idle_timeout timeout Specifies the client idle timeout in seconds after which a client is considered idle. A client is considered idle if it is not actively requesting updates from the session management server. This parameter is optional. clustered {yes|no} Whether the application will be deployed to a WebSphere cluster. The default value is no. cred_refresh_rule rule Specifies rules to preserve when a user's credential is refreshed. The default credential refresh rule set is preserve=tagvalue_*. database_name database Specifies the name of the of the WebSphere JDBC data source that the session management server uses to access the database that it uses to store its data. There is no default value. domain domain Specifies the name of the Tivoli Access Manager policy domain. This parameter is required when enable_tam_integration is set to yes. The default value is Default. enable_auditing {yes|no} Indicates whether or not auditing is required. The default value is no.
89
smscfg
enable_database_storage {yes|no} Indicates whether database storage is required. The parameter is only meaningful in the context of WebSphere Application Server single server deployments. If the application is deployed to a cluster, this parameter is redundant. The default value is no. Setting this parameter to no sets the database configuration to the WebSphere default resource reference, normally jdbc/DataSource. enable_database_session_storage {yes|no} Indicates whether storage of session data to a database is required. The default value is no. enable_last_login {yes|no} Indicates whether last login information is stored. When set to yes, you must specify the following parameters or accept their default values: v last_login_jsp_file v last_login_max_entries v last_login_table The default value is no (not to enable the recording of last login information). The enable_last_login field is only required if installing into a stand alone application server. When installing into a cluster this field is not required. enable_last_login_database {yes|no} Indicates whether last login information is stored to a database. The default value is no. enable_session_limit_policy {yes|no} Indicates whether to enable session limit and displacement policy. The default value is yes. enable_tam_integration {yes|no} Indicates whether to enable integration with Tivoli Access Manager or to change enablement. When set to yes, you must specify the following parameters or accept their default values, where applicable: v policysvr_host v policysvr_port v authzsvr v admin_id v admin_pwd v domain The default value is no. enable_tcd {yes|no} Indicates whether Tivoli Common Directory logging is required. When set to yes, you must specify the tcd parameter. The default value is no. help [options] Lists the name of the utility parameter and a short description. If one or more options are specified, it lists each parameter and a short description. instance instance_name Specifies the name of the instance to be administered. The default value is DSess. interactive {yes|no} Indicates whether the configuration is interactive. The default value is yes. key_lifetime lifecycle Specifies the lifetime in seconds of the key for the session management
90
smscfg
server. After the defined lifecycle completes, a new key is generated. If this value is set to zero, keys are not automatically generated. This parameter is optional. key_pwd password Specifies the password to access the server-side certificates. This parameter is required when you specify the keyfile parameter. Otherwise, this parameter is optional. keyfile file_name Specifies the fully qualified name for the key store when making a secure connection to WebSphere Application Server. The key store holds the server-side certificates. This parameter is required when you specify the was_admin_id parameter. Otherwise, this parameter is optional. last_login_jsp server_jsp_name The server-side path for the last login JSP file. This is an optional argument. last_login_jsp_file file_name Specifies the fully qualified name of the last login JSP file to use for recording last login information. This parameter is required when the enable_last_login parameter is set to yes. The default value is installation_directory/etc/lastLogin.jsp Note: Configuration of the lastLogin.jsp file can produce a long Web browser URL, which could exceed the limits imposed by some proxy servers. To avoid this, access the WebSphere ISC using a direct connection to the Internet. last_login_max_entries maximum_entries Specifies the maximum number of entries to be stored in the memory cache for recording last login information. This parameter is required when the enable_last_login parameter is set to yes. The default value is 0. The last_login_max_entries field is only required if installing into a stand alone application server. When installing into a cluster this field is not required. last_login_table table_name Specifies the name of the database table to use for recording last login information. This parameter is required when the enable_last_login parameter is set to yes. The default value is AMSMSUSERINFOTABLE. operations Lists each of the parameter names, one after another, without a description. policysvr_host host_name Specifies the host name of the Tivoli Access Manager policy server. This parameter is required when enable_tam_integration is set to yes. policysvr_port port Specifies the port of the Tivoli Access Manager policy server. This parameter is required when you specify the host parameter. record file_name Specifies the name of the response file to which configuration parameters will be recorded. remove_last_login_db {yes|no} Indicates whether the last login database should be removed. The default value is no.
91
smscfg
rspfile response_file Specifies the fully qualified path and file name of the response file to use during silent configuration. A response file can be used for configuration. There is no default response file name. The response file contains stanzas and parameter=value pairs. To use response files, see the procedures in the IBM Tivoli Access Manager for e-business: Installation Guide. session_realm [realm[:max_logins]=replica_set1, replica_set2,...] A session realm to add to the configuration. If the session realm name or any of the replica set names contain spaces, the entire argument must be specified within quotes. The max_logins parameter is used to specify the maximum number of concurrent logins which are permitted for the session realm. If the max_logins parameter is not supplied there will be an unlimited number of concurrent logins allowed for the session realm. Replica set names must be separated by commas. session_realm_remove realm=set_name[,...][;realm=set_name[,...]...] The name of a session realm which is to be removed. If the session realm name contain spaces, the entire argument must be specified within quotes. tcd path_name Specifies the fully qualified directory to be used for Tivoli Common Directory logging. This parameter is required when enable_tcd is set to yes. If the Tivoli common directory has already been configured on the target system, this option will be ignored. trust_store file_name Specifies the fully qualified name for the trust store when making a secure connection to WebSphere Application Server. The trust store holds the client-side certificates. This parameter is required when you specify the was_admin_id parameter. trust_store_pwd password Specifies the password to access the client-side certificates. This parameter is required when you specify the trust_store parameter. usage Displays the syntax and an example for this utility. virtual_host host_name Specifies the name of the WebSphere virtual host to which to deploy the session management server application. If not specified, the application is deployed on the default virtual host. was_admin_id administrator_id Specifies the name of the administrator to use when making a secure connection to WebSphere Application Server. In interactive mode, this parameter is optional unless you are making a secure connection. When you use this parameter, you must specify the was_admin_pwd parameter. When not making a secure connection, this parameter is optional. was_admin_pwd password Specifies the administrator's password to use when making a secure connection to WebSphere Application Server. was_cluster cluster_name Specifies the name of the WebSphere cluster to which to deploy the session management server application. This parameter is mutually exclusive with the was_server parameter.
92
smscfg
When using WebSphere Network Deployment and was_cluster is specified and there is only one cluster, the application is deployed to that cluster. When using WebSphere Network Deployment and was_cluster is specified and there is no cluster but there is only one server, the application is deployed to that server. was_enable_security {yes|no} Indicates whether the communication with the WebSphere server uses a secure connection. When set to yes, you must specify the following parameters: v was_admin_id v was_admin_pwd v trust_store v trust_store_pwd v keyfile v key_pwd The default value is no. was_node node_name Specifies the name of the WebSphere node. This parameter is optional. was_port port Specifies the simple object access protocol (SOAP) port to use on the WebSphere server. This parameter is always required unless the interactive parameter is set to yes. was_server server_name Specifies the name of the WebSphere server to which to deploy the session management server application. This parameter is mutually exclusive with the was_cluster parameter. When using WebSphere Application Server (a single server deployment) and was_server is not specified, the application is deployed to the server to which this configuration utility is connected.
Availability
/opt/pdsms/bin

Return codes
93
smsservicelevel
Lists the current service level of the session management server files on the local system. Note: This utility is for use by support personnel.
Syntax
smsservicelevel [directory [directory] ...] [file [file] ...]
Description
The smsservicelevel utility recursively scans the specified directory and returns to the standard output device the name and service level for session management server files that match Tivoli Access Manager conventions. The utility is provided on Linux and UNIX operating systems as a shell script, smsservicelevel.sh. On Windows operating systems, it is provided as a batch script, smsservicelevel.bat.
Parameters
directory Specifies the directories that the utility searches for service level information. files Specifies particular files that the utility searches.
Availability
/opt/pdsms/bin

Return codes
94
Appendix C. Support information

This section describes the following options for obtaining support for IBM products: v Searching knowledge bases v Obtaining fixes v Registering with IBM Software Support on page 96 v Receiving weekly software updates on page 96 v Contacting IBM Software Support on page 97
Searching knowledge bases

If you encounter a problem, you want it resolved quickly. You can search the available knowledge bases to determine whether the resolution to your problem was already encountered and is already documented.
Searching information centers

IBM provides extensive documentation in an information center that can be installed on your local computer or on an intranet server. You can use the search function of this information center to query conceptual information, instructions for completing tasks, reference information, and support documents.
Searching the Internet

If you cannot find an answer to your question in the information center, search the Internet for the latest, most complete information that might help you resolve your problem. To search multiple Internet resources for your product, perform the following steps: 1. 2. 3. 4. Expand the product folder in the navigation frame on the left. Expand Troubleshooting and support. Expand Searching knowledge bases. Click Web search.
From this topic, you can search a variety of resources, which includes the following resources: v IBM Technotes v v v v v IBM downloads IBM Redbooks IBM developerWorks Forums and news groups Google
Obtaining fixes
A product fix might be available to resolve your problem. To determine what fixes are available for your IBM software product, check the product support site by performing the following steps: 1. Go to the IBM Software Support site at the following Web address:
95
http://www.ibm.com/software/support 2. Under Products A - Z, click the letter with which your product starts to open a Software Product List. 3. Click your product name to open the product-specific support page. 4. Under Self help, follow the link to All Updates, where you will find a list of fixes, fix packs, and other service updates for your product. For tips on refining your search, click Search tips. 5. Click the name of a fix to read the description. 6. Optional, download the fix.
Registering with IBM Software Support

Before you can receive weekly e-mail updates about fixes and other news about IBM products, you need to register with IBM Software Support. To register with IBM Software Support, follow these steps: 1. Go to the IBM Software Support site at the following Web address: http://www.ibm.com/software/support 2. Click Register in the upper right-hand corner of the support page to establish your user ID and password. 3. Complete the form, and click Submit.
Receiving weekly software updates

After registering with IBM Software Support, you can receive weekly e-mail updates about fixes and other news about IBM products. To receive weekly notifications, follow these steps: 1. Go to the IBM Software Support site at the following Web address http://www.ibm.com/software/support 2. Click the My support link to open the Sign in page. 3. Provide your sign in information, and click Submit to open your support page. 4. Click the Edit profile tab. 5. For each product about which you want to receive updates, use the filters to choose your exact interests, and click Add products. 6. Repeat step 5 for each additional product. 7. After choosing all your products, click the Subscribe to email link. 8. For each product category, use the filters and choose which updates you want to receive, and click Update. 9. Repeat step 8 for each additional product category. For more information about the types of fixes that are available, see the IBM Software Support Handbook at the following Web address: http://techsupport.services.ibm.com/guides/handbook.html
96
Contacting IBM Software Support

IBM Software Support provides assistance with product defects. Before contacting IBM Software Support, the following criteria must be met: v Your company has an active IBM software maintenance contract. v You are authorized to submit problems to IBM Software Support. The type of software maintenance contract that you need depends on the type of product that you have. Product types are one of the following categories: v For IBM distributed software products (including, but not limited to, Tivoli, Lotus, and Rational products, as well as DB2 and WebSphere products that run on Windows, Linux, or UNIX operating systems), enroll in Passport Advantage in one of the following ways: Online Go to the IBM Software Passport Advantage site at the following Web address and click How to Enroll: http://www.lotus.com/services/passport.nsf/ WebDocs/Passport_Advantage_Home By phone For the phone number to call in your country, go to the IBM Software Support site at the following Web address and click the name of your geographic region: http://techsupport.services.ibm.com/guides/contacts.html v For IBM eServer software products (including, but not limited to, DB2 and WebSphere products that run in System z, pSeries, and iSeries environments), you can purchase a software maintenance agreement by working directly with an IBM sales representative or an IBM Business Partner. For more information about support for eServer software products, go to the IBM eServer Technical Support Advantage site at the following Web address: http://www.ibm.com/servers/eserver/techsupport.html If you are not sure what type of software maintenance contract you need, call 1-800-IBMSERV (1-800-426-7378) in the United States or, from other countries, go to the contacts page of the IBM Software Support Handbook at the following Web address and click the name of your geographic region for phone numbers of people who provide support for your location: http://techsupport.services.ibm.com/guides/contacts.html To 1. 2. 3. contact IBM Software support, follow these steps: Determining the business impact Describing problems and gathering information on page 98 Submitting problems on page 98
Determining the business impact

When you report a problem to IBM, you are asked to supply a severity level. Therefore, you need to understand and assess the business impact of the problem that you are reporting. Use the following severity criteria:
97
Severity 1 The problem has a critical business impact. You are unable to use the program, resulting in a critical impact on operations. This condition requires an immediate solution. Severity 2 The problem has a significant business impact. The program is usable, but it is severely limited. Severity 3 The problem has some business impact. The program is usable, but less significant features that are not critical are unavailable. Severity 4 The problem has minimal business impact. The problem causes little impact on operations, or a reasonable circumvention to the problem was implemented.
Describing problems and gathering information

When explaining a problem to IBM, be as specific as possible. Include all relevant background information so that IBM Software Support specialists can help you solve the problem efficiently. To save time, know the answers to these questions: v What software versions were you running when the problem occurred? v Do you have logs, traces, and messages that are related to the problem symptoms? IBM Software Support is likely to ask for this information. v Can you create the problem again? If so, what steps were performed to encounter the problem? v Was any change made to the system? For example, were there changes to the hardware, operating system, networking software, and so on. v Are you currently using a workaround for this problem? If so, please be prepared to explain it when you report the problem.
Submitting problems
You can submit your problem to IBM Software Support in one of two ways: Online Go to the Submit and track problems page on the IBM Software Support site at the following address, and provide your information into the appropriate problem submission tool: http://www.ibm.com/software/support/probsub.html By phone For the phone number to call in your country, go to the contacts page of the IBM Software Support Handbook at the following Web address and click the name of your geographic region: http://techsupport.services.ibm.com/guides/contacts.html If the problem you submit is for a software defect or for missing or inaccurate documentation, IBM Software Support creates an Authorized Program Analysis Report (APAR). The APAR describes the problem in detail. Whenever possible, IBM Software Support provides a workaround that you can implement until the APAR is resolved and a fix is delivered. IBM publishes resolved APARs on the IBM product support Web pages daily, so that other users who experience the same problem can benefit from the same resolution.
98
For more information about problem resolution, see Searching knowledge bases on page 95 and Obtaining fixes on page 95.
99
100
Appendix D. Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. However, it is the user responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: IBM World Trade Asia Corporation Licensing 2-31 Roppongi 3-chome, Minato-ku Tokyo 106, Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement might not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
101
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation 2Z4A/101 11400 Burnet Road Austin, TX 78758 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases payment of a fee. The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements, or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility, or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. This information is for planning purposes only. The information herein is subject to change before the products described become available. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not
102
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBMs application programming interfaces. Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows: (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. Copyright IBM Corp. _enter the year or years_. All rights reserved. If you are viewing this information in softcopy form, the photographs and color illustrations might not be displayed.
Trademarks
IBM, the IBM logo, AIX, DB2, IBMLink, Tivoli, Tivoli Enterprise Console, and TME are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Adobe, the Adobe logo, Acrobat, PostScript and all Adobe-based trademarks are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, other countries, or both. Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc., in the United States, other countries, or both and is used under license therefrom. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce. IT Infrastructure Library is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
Appendix D. Notices
103
UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, and service names may be trademarks or service marks of others.
104
Glossary
This glossary defines the technical terms and abbreviations that are used in Tivoli Access Manager. If you do not find the term or abbreviation for which you are looking, refer to the IBM Terminology Web site at the following Web address: http://www.ibm.com/ibm/terminology The following cross-references are used among terms: Contrast with Refers the reader to a term that has an opposed or substantively different meaning. See Refers the reader to a term that is the expanded form of an abbreviation or acronym or to a synonym or more preferred term.
ACL entry. Data in an access control list that specifies a set of permissions. ACL policy. Part of the security policy that contains ACL entries that control who can access which domain resources and perform which actions. See also authorization rule and protected object policy. action. An access control list (ACL) permission attribute. See also access control list. action group. A set of actions that are explicitly associated with a resource or set of resources. ADI. See access decision information. ADK. See application development kit administration service. An authorization API runtime plug-in that can be used to perform administration requests on a Tivoli Access Manager resource manager application. The administration service responds to remote requests from the pdadmin command to perform tasks, such as listing the objects under a particular node in the protected object tree. Customers may develop these services using the authorization ADK. application development kit (ADK). A set of tools, APIs, and documentation to assist with the development of software in a specific computer language or for a particular operating environment. attribute. A characteristic or trait of an entity that describes the entity. An attribute can have a type, which indicates the range of information given by the attribute, and a value, which is within a range. In XML, for example, an attribute consists of a name-value pair within a tagged element and modifies a feature of an element. attribute list. A linked list that contains extended information that is used to make authorization decisions. Attribute lists consist of a set of name-value pairs. audit event. A record of an operation in the audit log or change history; for example, an audit entry is created when a resource is modified. audit level. The types of user actions that are currently being audited for the entire system or for specific users on the system. Actions that can be audited include authority failures and restoring objects. A record of each action is written to the audit journal. audit trail. A chronological record of events that enables the user to examine and reconstruct a sequence
See also Refers the reader to a related term. Obsolete Indicates that the term should not be used and refers the reader to the preferred term.
A
access control. In computer security, the process of ensuring that only authorized users can access the resources of a computer system in authorized ways. access control list (ACL). In computer security, a list with an object that identifies all the subjects that can access the object and their access rights. For example, an access control list is a list that is associated with a file that identifies the users who can access the file and identifies the users' access rights to that file. access decision information (ADI). The data and attributes that are used by the authorization engine to evaluate a rule. Authorization API attributes are name-value pairs, form the basis of all ADI that can be referenced in a rule or presented to the authorization engine. access permission. The access privilege that applies to the entire object. account. Information about an identity. ACL. See access control list.
105
of events. Audit trails are useful for managing security and for recovering lost transactions. audit trail file. The file that contains the audit trail. authentication. In computer security, the process that verifies identity. Authentication is distinct from authorization; authorization is concerned with granting and denying access to resources. See also multi-factor authentication, network-based authentication, and step-up authentication. authorization. In computer security, the process that grants or denies access to resources. Security uses a two-step process: after authentication has verified the identity, authorization allows the resource or process access to various resources based on its identity. authorization API. The Tivoli Access Manager component that passes requests for authorization decisions from the resource manager to the authorization evaluator. See also authorization server and authorization service. authorization evaluator. The decision-making process that determines whether a client can access a protected resource based on the security policy. The evaluator makes its recommendation to the resource manager, which, in turn, responds accordingly. authorization rule. Part of the security policy that define conditions that are contained in authorization policy. An authorization rule is used to make access decisions based on attributes such as user, application, and environment context. See also ACL policy and protected object policy. authorization server. The Tivoli Access Manager component that runs the authorization service. See also authorization service. authorization service. A dynamic or shared library that can be loaded by the authorization API runtime client at initialization time to perform operations that extend a service interface in the Authorization API.
one are the only two values that can be returned; a value of zero represents false while a value of one represents true. business entitlement. The supplemental attribute of a user credential that describes the fine-grained conditions that can be used in the authorization process.
C
CA. See certificate authority. CDAS. Obsolete. See external authentication C API. CDMF. See cross domain mapping framework. certificate. In computer security, a digital document that binds a public key to the identity of the certificate owner, thereby enabling the certificate owner to be authenticated. A certificate is issued by a certificate authority. certificate authority (CA). An organization that issues certificates. A CA creates digital signatures and public-private key pairs. The CA guarantees the identity of the individual who is granted the unique certificate and guarantees the services that the owner is authorized to use, to issue new certificates, and to revoke certificates that belong to users and organizations who are no longer authorized to use the services. The role of the CA s to authenticate the entities (users and organizations) involved in electronic transactions. Because the CA guarantees that the two parties that are exchanging information are really who they claim to be, the CA is a critical component in data security and electronic commerce. CGI. See common gateway interface. cipher. A cryptographic algorithm that is used to encrypt data that is unreadable until it is converted into plain data (decrypted) with a predefined key. common gateway interface (CGI). An Internet standard for defining scripts that pass information from a Web server to an application program, through an HTTP request, and vice versa. A CGI script is a CGI program that is written in a scripting language, such as Perl. configuration. The manner in which the hardware and software of a system, subsystem, or network are organized and interconnected. connection. (1) In data communication, an association established between functional units for conveying information. (2) In TCP/IP, the path between two protocol applications that provides reliable data stream delivery service. In the Internet, a connection extends from a TCP application on one system to a TCP application on another system. (3) In system
B
BA. See basic authentication. basic authentication. An authentication method that verifies identity using a user name and password. bind. To relate an identifier to another object in a program; for example, to relate an identifier to a value, to an address, or to another identifier or to associate formal parameters to actual parameters. blade. A component that provides application-specific services and components. Boolean. A binary numbering system that is named after mathematician George Boole in which zero and
106
communication, a line over which data can be passed between two systems or between a system and a device. console log agent. A log agent that writes events to standard error or standard output. See also file log agent, pipe log agent, and remote log agent. container object. A structural designation that organizes the object space into distinct functional regions. cookie. Information that a server stores on a client machine and accesses during subsequent sessions. Cookies allow servers to remember specific information about clients. credentials. Detailed information, acquired during authentication, that describes the user, any group associations, and other security-related identity attributes. Credentials can be used to perform a multitude of services, such as authorization, auditing, and delegation. credentials modification service. An authorization API runtime plug-in which can be used to modify a Tivoli Access Manager credential. Credentials modification services developed externally by customers are limited to performing operation to add and remove from the credentials attribute list and only to those attributes that are considered modifiable. cross domain authentication service (CDAS). Obsolete. See external authentication C API. cross domain mapping framework (CDMF). A programming interface that allows a developer to customize the mapping of user identities and the handling of user attributes when WebSEAL e-Community SSO function are used.
digital signature. Information that is encrypted with a private key and is appended to a message to assure the recipient of the authenticity and integrity of the message. The digital signature proves that the message was signed by the entity that owns, or has access to, the private key or shared secret symmetric key. directory schema. The valid attribute types and object classes that can appear in a directory. The attribute types and object classes define the syntax of the attribute values, which attributes are required, and which attributes are optional. distinguished name (DN). (1) The name that uniquely identifies an entry in a directory. A distinguished name is made up of an attribute-value pairs, separated by commas. (2) A set of name-value pairs (such as cn=common name and c=country) that uniquely identifies an entry in a digital certificate. DMZ. See demilitarized zone. DN. See distinguished name. domain. (1) A logical grouping of resources in a network that share common administration and management. (2) A part of a network that is administered with a common protocol. See also domain name. domain administrator. The administrator for a domain who can assign any of the roles in that domain to subdomains. After assigning roles to subdomains, administrators in that subdomain can assign subdomain users these roles. domain name. In the Internet suite of protocols, the name of a host system. A domain name consists of a sequence of subnames that are separated by a delimiter character. For example, if austin.ibm.com is the fully qualified domain name (FQDN) of a host system, both austin.ibm.com and ibm.com are domain names. dynamic group. A group that is defined using a search expression. When an attribute is added to a directory entry that causes it to match the search expression, the entry automatically becomes a member of the group.
D
daemon. A system process that runs unattended to perform continuous or periodic system-wide functions, such as network control. See also service. data store. A storage area for data, such as a database system, directory, or file. delegate. A user who is authorized to work for another user. The authorization can be made by a user or by an administrator. demilitarized zone (DMZ). In network security, a computer or network that uses a firewall to be isolated from, and to serve as a neutral zone between, a trusted network (for example, a private intranet) and an untrusted network (for example, the Internet). One or more secure gateways usually control access to the DMZ from the trusted or the untrusted network.
E
EAS. See external authorization service. encryption. In computer security, the process of transforming data into a cipher. entitlement. A data structure that contains externalized security policy information. Entitlements contain policy data or capabilities that are formatted in a way that is understandable to a specific application. entitlement service. An authorization API runtime plug-in which can be used to return entitlements from
Glossary
107
an external source for a principal or set of conditions. Entitlements are normally application specific data that will be consumed by the resource manager application in some way or added to the principal's credentials for use further on in the authorization process. Customers may develop these services using the authorization ADK. entity. In object-oriented design, an item that can be treated as a unit and, often, as a member of a particular category or type. An entity can be concrete or abstract. event. Any significant change in the state of a system resource, network resource, or network application. An event can be generated for a problem, for the resolution to a problem, or for the successful completion of a task. event pool. A set of events recognized by an activity. Each activity has its own event pool. The event pool is initialized when the activity is created and is deleted when the activity is deleted. extended attribute. Additional information that the system or a program associates with an object. An extended attribute can be any format, such as text, a bitmap, or binary data. external authentication C API. A C API that enables you to write custom authentication modules that replace or extend the functionality of the builtin authentication process. The identity information is returned through the authentication module interface. Contrast with external authentication HTTP interface. external authentication HTTP interface. An interface that enables you to extend the functionality of the built-in authentication process to allow a remote service to handle the authentication process. The identity information in the HTTP response headers is used to generate user credentials. Contrast with external authentication C API. external authorization service (EAS). An authorization API runtime plug-in that can be used to make application- or environment-specific authorization decisions as part of the authorization decision chain. Customers can develop these services using the authorization ADK. Extensible Markup Language (XML). A standard meta-language for defining markup languages that is based on Standard Generalized Markup Language (SGML). Extensible Stylesheet Language (XSL). A language for specifying style sheets for XML documents. XSL Transformation (XSLT) is used with XSL to describe how an XML document is transformed into another document. See also Extensible Stylesheet Language Transformation.
Extensible Stylesheet Language Transformation (XSLT). An XML processing language that is used to convert an XML document into another document in XML, PDF, HTML, or other format. See also Extensible Stylesheet Language.
F
file log agent. A log agent that writes events to a file. See also console log agent, pipe log agent, and remote log agent. file transfer protocol (FTP). In the Internet suite of protocols, a protocol that can use Transmission Control Protocol (TCP) and Telnet services to transfer files between machines. FTP. See file transfer protocol
G
global sign-on (GSO). A flexible single sign-on solution that enables the user to provide alternative user names and passwords to the back-end Web application server. Through a single login, global sign-on grants users access to the computing resources they are authorized to use. Designed for large enterprises consisting of multiple systems and applications within heterogeneous, distributed computing environments, GSO eliminates the need for users to manage multiple user names and passwords. See also single sign-on. group. A named list of users by which access levels to corporate directories, databases, and servers are assigned. Two or more individual users who are categorized for the purpose of assigning database security settings; for example, administrators must assign individuals to groups before assigning roles. GSO. See global sign-on.
H
host. A computer that is connected to a network and provides an access point to that network. The host can be a client, a server, or both a client and a server simultaneously. HTTP. See hypertext transfer protocol. hypertext transfer protocol (HTTP). In the Internet suite of protocols, the protocol that is used to transfer and display documents.
I
inheritance. An object-oriented programming technique that allows the use of existing classes as a basis for creating other classes.
108
Internet protocol (IP). In the Internet suite of protocols, a connectionless protocol that routes data through a network or interconnected networks. IP acts as an intermediary between the higher protocol layers and the physical network. Internet suite of protocols. A set of protocols developed for use on the Internet and published through the Internet Engineering Task Force (IETF). interprocess communication (IPC). (1) The process by which programs communicate data to each other and synchronize their activities. Semaphores, signals, and internal message queues are common methods of interprocess communication. (2) A mechanism of an operating system that allows processes to communicate with each other within the same computer or over a network. IP. See Internet protocol. IPC. See interprocess communication.
the sender uses the public key to encrypt the message, and the recipient uses the private key to decrypt the message. When the key pair is used for signing, the signer uses the private key to encrypt a representation of the message, and the recipient uses the public key to decrypt the representation of the message for signature verification. Because the private key holds more of the encryption pattern than the public key, the key pair is called asymmetric. key ring. See key file. keystore file. A key file that contains both public keys stored as signer certificates and private keys stored in personal certificates. keytab file. See key table. key table. In the Kerberos protocol, a file that contains service principal names and secret keys. The secret keys should be known only to the services that use the key table file and the key distribution center (KDC). key-value pair. Information that is expressed as a paired set.
J
junction. A logical connection that is created to establish a path from one server to another.
L
LDAP. See lightweight directory access protocol. leaf node. A node that has no children before it in the directory tree. lightweight directory access protocol (LDAP). An open protocol that uses TCP/IP to provide access to directories that support an X.500 model and that does not incur the resource requirements of the more complex X.500 Directory Access Protocol (DAP). For example, LDAP can be used to locate people, organizations, and other resources in an Internet or intranet directory. lightweight third party authentication (LTPA). An authentication protocol that users cryptography to support security across a set of Web servers in a distributed environment. LTPA. See lightweight third party authentication.
K
KDC. See key distribution center. Kerberos. An authentication system that enables two parties to exchange private information over an otherwise open network. It works by assigning a unique key, called a ticket, to each user that logs on to the network. The ticket is then embedded in messages that are sent over the network. The receiver of a message uses the ticket to authenticate the sender. Kerberos ticket. A transparent application mechanism that transmits the identity of an initiating principal to its target. A simple ticket contains the identity, a session key, a timestamp, and other information that is sealed using a secret key. key. In computer security, a sequence of symbols that is used with a cryptographic algorithm for encrypting or decrypting data. See private key and public key. key database file (KDC). See key file. key distribution center. In the Kerberos protocol, the central server, which includes the authentication server and the ticket-granting server. The KDC is sometimes referred to as the Kerberos server. key file. In computer security, a file that contains public keys, private keys, trusted roots, and certificates. key pair. In computer security, a public key and a private key. When the key pair is used for encryption,
M
management domain. The default domain in which Tivoli Access Manager enforces security policies for authentication, authorization, and access control. This domain is created when the policy server is configured. See also domain. management interface. The interface that a domain administrator can use to manage security policy. In Tivoli Access Manager, an administrator can use Web Portal Manager or the pdadmin commands to apply security policy to resources.
Glossary
109
management server. Obsolete. See policy server. master server. In a network environment, the server that has permissions to run commands on all other machines in the environment. The master server is designed to manage the network, clients, and resource objects in the network database. Contrast with replica server metadata. Data that describes the characteristics of stored data. migration. The installation of a new version or release of a program to replace an earlier version or release. MPA. See multiplexing proxy agent. multi-factor authentication. A protected object policy (POP) that forces a user to authenticate using two or more levels of authentication. For example, the access control on a protected resource can require that the users authenticate with both user name/password and user name/token passcode. multiple tenancy server. A server that permits the hosting of multiple customers on a single server instead of multiple client machines. See also protected object policy. multiplexing proxy agent (MPA). A gateway that accommodates multiple client access. These gateways are sometimes known as Wireless Access Protocol (WAP) gateways when clients access a secure domain using a WAP. Gateways establish a single authenticated channel to the originating server and tunnel all client requests and responses through this channel.
user can manipulate as a single unit and perform a task. An object can appear as text, an icon, or both. (3) A named storage space that consists of a set of characteristics that describe the space and, in some cases, data. An object is anything that occupies space in storage, can be located in a library or directory, can be secured, and on which defined operations can be performed. Some examples of objects are programs, files, libraries, and stream files. object space. A virtual representation of the resources to be protected. See also namespace. object type. A categorization or group of object instances that share similar behavior and characteristics.
P
PAC. See privilege attribute certificate. PDCA. See Policy Director Certificate Authority permission. The ability to access a protected object, such as a file or directory. The number and meaning of permissions for an object are defined by the access control list (ACL). See also access control list. pipe log agent. A log agent that writes events as standard input to another program. See also console log agent, file log agent, and remote log agent. policy. A set of rules that are applied to managed resources. policy database. The database that contains the security policy information for all resources in the domain. Each domain has its own policy database. Policy Director Certificate Authority (PDCA). A trusted certificate that is created during the configuration of the policy server and that is used to sign all other Tivoli Access Manager certificates. A PDCA certificate is stored in the master policy database. policy enforcer. A component of a resource manager that directs requests to the authorization service for processing after authorization is granted. Traditional applications bundle the policy enforcer and the resource manager as one process. policy server. The Tivoli Access Manager component that maintains the master policy database, replicates this policy information throughout the secure domain, and updates database replicas whenever a change is made to the master policy database. The policy server also maintains location information about other Tivoli Access Manager and non-Tivoli Access Manager resource managers that are operating in the secure domain.
N
namespace. (1) In XML, a uniform resource identifier (URI) that provides a unique name to associate with all the elements and type definitions in a schema. (2) Space reserved by a file system to contain the names of its objects. network-based authentication. A protected object policy (POP) that controls access to objects based on the Internet protocol (IP) address of the user. See also protected object policy. notification thread. The synchronization mechanism that the policy server uses to inform all database replicas of a change to the master policy database.
O
object. (1) In object-oriented design or programming, a concrete realization (instance) of a class that consists of data and the operations associated with that data. An object contains the instance data that is defined by the class, but the class owns the operations that are associated with the data. (2) Any digital content that a
110
polling. The process by which databases are interrogated at regular intervals to determine if data needs to be transmitted. POP. See protected object policy. portal. A single point of access to diverse information and applications. Users can customize and personalize a portal. principal. (1) An entity that can communicate securely with another entity. (2) An authenticated user. A principal is identified by its associated security context, which defines its access rights. private key. In computer security, a key that is known only to its owner. Contrast with public key. privilege attribute certificate (PAC). A digital document that contains a principal's authentication and authorization attributes and a principal's capabilities. privilege attribute certificate service. An authorization API runtime client plug-in which translates a PAC of a predetermined format in to a Tivoli Access Manager credential, and vice-versa. These services could also be used to package or marshall a Tivoli Access Manager credential for transmission to other members of the secure domain. Customers may develop these services using the authorization ADK. See also privilege attribute certificate. protected object. The logical representation of an actual system resource that is used for applying ACLs and POPs and for authorizing user access. See also protected object policy and protected object space. protected object policy (POP). A type of security policy that imposes additional conditions on the operation permitted by the ACL policy to access a protected object. It is the responsibility of the resource manager to enforce the POP conditions. See also ACL policy, authorization rule, protected object, and protected object space. protected object space. The virtual object representation of actual system resources that is used for applying ACLs and POPs and for authorizing user access. See also protected object and protected object policy. proxy server. A server that receives requests intended for another server and that acts on behalf of a client to obtain the requested service. A proxy server is often used when the client and the server are incompatible for direct connection. For example, a client cannot meet the security authentication requirements of the server but should be permitted some services. public key. In computer security, a key that is made available to everyone. Contrast with private key.
Q
quality of protection. The level of data security, determined by a combination of authentication, integrity, and privacy conditions.
R
record. (1) The storage representation of a single row of a table or other data in a database. (2) A group of related data, words, or fields treated as a unit. registry. The datastore that contains access and configuration information for users, systems, and software. remote cache mode. An operational mode in which a resource manager uses the functions that are provided by the authorization API to communicate to the remote authorization server. remote log agent. A log agent that sends events to a remote server for recording. See also console log agent, file log agent, and pipe log agent. replica server. A server that contains a copy of the directory or directories of another server. Replicas back up master servers or other replica servers to enhance performance or response times and to ensure data integrity. Contrast with master server. resource. A hardware, software, or data entity that is managed. resource group. A group of resources that can include business objects such as contracts or a set of related commands. In access control policies, resource groups specify the resource to which the policy authorizes access. resource manager. (1) An application, program, or transaction that manages and controls access to shared resources, such as memory buffers and data sets. (2) Any server or application that uses the authorization API to process client requests for access to resources. resource object. The representation of an actual network resource, such as a service, file, and program. response file. An ASCII file that can be customized with the setup and configuration data that automates an installation. The setup and configuration data has to be entered during an interactive installation, but with the response file, the installation can proceed without user interaction. See also silent installation. role. A definition of the access permissions that a user or process has and the specific resources that the user or process can modify at those levels. Users and processes are limited in how they can access resources when that user or process does not have the appropriate role.
Glossary
111
role activation. The process of applying access permissions to a role. role assignment. The process of assigning a role to a user, such that the user has the appropriate access permissions for the object defined for that role. root container object. The top-level container object in the hierarchy or resource objects. root domain. Name servers that have authoritative control of all the top-level domains. routing file. An ASCII file that contains commands that control the configuration of messages. routing table. A collection of path information through which hosts or networks can communicate with each other. RSA. A public-key encryption technology that was developed by RSA Data Security, Inc., and used by GSKit. The acronym stands for Rivest, Shamir, and Adleman, the inventors of this encryption technique. RSA encryption. A system for public-key cryptography used for encryption and authentication. The security of the system depends on the difficulty of factoring the product of two large prime numbers. rule. A set of logical statements that enable a server to recognize relationships among events and to perform automated responses accordingly. rules evaluator. The component responsible for evaluating an authorization rule. run time. The time period during which a computer program is running. runtime environment. A subset of an application development kit (ADK) that contains the executable files and other supporting files that comprise the operational environment of the platform.
security context. The digitally signed token that identifies a principal, lists the roles and access rights for the principal, and contains information about when the token expires. security management. The software discipline that addresses how an organization can control access to mission critical applications and data. security policy. (1) A written document that defines the security controls that you institute for your computer systems. A security policy describes the risks that you intend to minimize and the actions that should be taken if someone breaches your security controls. (2) In Tivoli Access Manager, the combination of ACL policies, authorization rules, and protected object policies attached to objects to make them protected objects. See also ACL policy, authorization rule, and protected object policy. self-registration. The process by which a user can enter required data and become a registered user without the involvement of an administrator. service. Work performed by a server. A service can be a simple request for data to be sent or stored (as with file servers, HTTP servers, or e-mail servers), or it can be for more complex requests (as with print servers or process servers). See also daemon. session. A series of requests to a server or application that originate from the same user at the same browser. silent installation. An installation that does not send messages to the console but instead stores messages and errors in log files. Also, a silent installation can use response files for data input. See also response file. single sign-on (SSO). The mechanism that allows a user to logon once and access multiple applications through a single authorization challenge. Using SSO, a user does not need to log on to each application separately. See also global sign-on. SSL. See Secure Socket Layer. SSO. See single sign-on. stanza. A group of lines in an ASCII file that together have a common function or define a part of a system. Stanzas are usually separated by blank lines or colons, and each stanza has a name. stash file. The local copy of the master key file that resides in an encrypted format on the local disk. step-up authentication. A protected object policy (POP) that relies on a preconfigured hierarchy of authentication levels and enforces a specific level of authentication according to the policy set on a resource. The step-up authentication POP does not force the user to authenticate using multiple levels of authentication to access any given resource, but it requires the user to
S
scalability. The ability of hardware, software, or a distributed system to maintain performance levels as it increases in size and increases in the number of users who access resources. schema. The set of statements, expressed in a data definition language, that completely describes the structure of data that is stored in a database, directory, or file. Secure Sockets Layer (SSL). A security protocol that provides communication privacy. SSL enables client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, and message forgery.
112
authenticate at a level at least as high as that required by the policy protecting a resource. See also protected object policy. suffix. A distinguished name that identifies the top entry in a locally held directory hierarchy. Because of the relative naming scheme used in Lightweight Directory Access Protocol (LDAP), this suffix applies to every other entry within that directory hierarchy. A directory server can have multiple suffixes, each identifying a locally held directory hierarchy.
W
Web Portal Manager (WPM). A Web-based graphical application used to manage Tivoli Access Manager security policy in a secure domain. An alternative to the pdadmin command line interface, this GUI enables remote administrator access and enables administrators to create delegated user domains and assign delegate administrators to these domains. Web resource. Any one of the resources that are created during the development of a Web application; for example, Web projects, HTML pages, JSP files, servlets, custom tag libraries, and archive files. WebSEAL. A high performance, multi-threaded Web server that applies a security policy to a protected object space. WebSEAL can provide single sign-on solutions and incorporate back-end Web application server resources into its security policy. Web session. See session. WPM. See Web Portal Manager.
T
ticket. See Kerberos ticket. token. A sequence of bits (symbol of authority) that is passed successively along a transmission medium from one device to another to indicate the device that is temporarily in control of the transmission medium. Each device can acquire and use the token to control the medium. trusted root. In the Secure Sockets Layer (SSL), the public key and associated distinguished name of a certificate authority (CA). See also Secure Socket Layer.
X
XML. See Extensible Markup Language. XML transform. A standard that uses XSL stylesheets to transform XML documents into other XML documents or fragments or to transform XML documents into HTML documents. XSL. See Extensible Stylesheet Language. XSL stylesheet. Code that describes how an XML document should be rendered (displayed or printed). XSLT. See Extensible Stylesheet Language Transformation.
U
uniform resource identifier (URI). The character string used to identify an abstract or physical resource on the Internet. A URI typically describes how to access the resource, the computer that contains the resource, and the name of the resource. The most common form of URI is the Web page address, which is a particular subset or URI called uniform resource locator (URL). See also uniform resource locator. uniform resource locator (URL). A character string that represent resources on a computer or in a network, such as the Internet. The URL includes the abbreviated name of the protocol used to access the information resource and the information used by the protocol to locate the resource. URI. See uniform resource identifier. URL. See uniform resource locator. user. Any person, organization, process, device, program, protocol, or system that uses a service provided by others. user registry. See registry.
V
virtual hosting. The capability of a Web server that allows it to appear as more than one host to the Internet.
Glossary
113
114
Index A
accessibility ix administration session management server architecture session management server auditing configuration files 20 authentication 11 credential refresh 32 authorization 11, 12 configuring 11 server 6 1 4 configuring (continued) SSL 9 WebSEAL 14 consistency 3 conventions typeface x credential refresh setting rules 32 customer support contacting 97 obtaining fixes 95 receiving updates from 96 registering with 96 searching information centers 95 searching knowledge bases 95 searching the Internet 95 submitting problems 98
B
books see publications v, viii
D
data storage type 20 deploying considerations 6 ISC 18 session management server directory names, notation xi domain cookies 14
C
certificates 10 configuring 9 client idle timeout 20 cluster 4 name 20 command line extensions configuring 23 considerations 23 commands common tasks 27 key change 30 key show 30 policy get 28 policy set 28 realm list 29 realm show 29 replica set list 29 replica set show 29 server commands 49 sms session list 27 sms terminate all_sessions 28 sms terminate session 28 common problems reporting describing problem 98 determining business impact 97 gathering information 98 submitting problems 98 configuration utility running 23 configure smscfg utility 87 configuring 23 authorization 11 certificates 9 instances 24 Plug-in for Web Servers 14 secure communications 10 session management server 17, 19, 20 Copyright IBM Corp. 2005, 2010
18, 24
E
education see Tivoli technical training ix environment variables, notation xi External Authentication Interface (EAI) 14
F
failover 3 features session management server fixes, obtaining 95 fixpacks installing 18 2
G
GSKit ikeyman 9
I
information centers, searching 95 installing fixpacks 18 session management server 17 instance listing 52 setting 51
115
instances configuring 24 multiple 3 interactive configuration 19 interface 11 Internet, searching 95 introduction session management server ISC deploying 24
O
online publications accessing viii ordering publications ix
P
1 path names, notation xi pdadmin 6, 23 commands 49 pdsmsadmin 6, 12 commands 49 configuring 23 pdsmsclicfg -action config 23 -action unconfig 24 configure 82 Plug-in for Web Servers 4 configuring 14 policy enforcement 3 policy get command 28 policy set command 28 publications v accessing online viii ordering ix
J
J2EE 9, 11
K
key change command 30 key lifetime configuration 20 key show command 30 keys creating, session management server 54 displaying details, session management server generating, new 30 managing 30 knowledge bases information centers 95 searching 95 the Internet 95
56
R
realm list command 29 realm show command 29 realms 4 displaying details, session management server limiting 4 listing, session management server 58 replica sets managing 29 replica set 4 replica set list command 29 replica set show command 29 replica sets displaying 29 displaying details, session management server listing 29 listing, session management server 66 monitoring activity 29 rspfile response file 19 60
L
last login parameters 20 last login activity database creating 32 overview 31 schema 31 security data 31 LDAP 11, 13 Lightweight Third Party Authentication (LTPA) limit session realms 4 list servers 53 logging 3
11
68
M
managing realms and replica sets 29 manuals see publications v, viii
S
security 12 configuring 9 considerations 9 server commands instances list 52 login 50 server list 53 server task sms key change 54 server task sms key show 56 server task sms realm list 58 server task sms realm show 60 server task sms refresh all_sessions 62 server task sms refresh session 64 server task sms replica set list 66 server task sms replica set show 68
N
notation environment variables path names xi typeface xi xi
116
server commands (continued) server task sms session list 70 server task sms trace get 76 server task sms trace set 78 server task terminate all_sessions 72 server task terminate session 74 set instance 51 server list command 53 server task commands instances list 52 login 50 refresh session 64 set instance 51 terminate all_sessions 72 terminate session 74 trace get 76 trace set 78 server task session commands refresh all sessions 62 server task sms key command change 54 show 56 server task sms realm command list 58 show 60 server task sms replica command set list 66 set show 68 server task sms session command list 70 session management server administration options 1 architecture 4 configuring 17 requirements 20 smscfg 19 creating keys 54 deploying 18 additional instances 24 displaying details, keys 56 displaying details, replica sets 68 displaying replica sets in realms 60 features 2 installing overview 17 introduction 1 listing realms 58 listing replica sets 66 listing sessions 70 refreshing credentials 62, 64 single sign-on (SSO) 14 unconfiguring 24 session realms listing replica sets displaying 29 monitoring activity 29 sessions concurrent getting policy 28 setting policy 28 listing, session management server 70 user ending 28 searching 27 single sign-on (SSO) 14 sms session list command 27
sms terminate all_sessions command sms terminate session command 28 sms-administrator 12 sms-client 11 sms-delegate 12 smsbackup utility 85 smscfg -action config 24 -action deploy ISC 18 -action unconfig 24 configuration utilty running 23 smscfg utility 87 smsservicelevel utility 94 software updates, receiving 96 SSL 9, 10 considerations 23 statistics 3, 30 support See customer support svrsslcfg 9 syntax, reading 49
28
T
Tivoli Access Manager integration 23 enabling 20 Plug-in for Web Servers 4 WebSEAL 4 WebSphere 4 Tivoli Common Directory (TCD) logging 20 Tivoli Information Center viii Tivoli Performance Viewer 30 Tivoli technical training ix Tivoli user groups x trace level displaying 76 setting 78 training, Tivoli technical ix Trust Association Interceptor (TAI) typeface conventions x
U
unconfiguring session management server user groups, Tivoli x user sessions terminating 74 terminating all 72 utilities pdsmsclicfg 82 smsbackup 85 smscfg 87 smsservicelevel 94 24
V
variables, notation for xi
Index
117
W
WebSEAL 4 configuring 14 WebSphere 4, 9, 10, 13 performance pages 30
118
Printed in USA
SC23-6509-01

Am611 Sms Admin

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Am611 Sms Admin

Cargado por

Copyright:

Formatos disponibles

Tivoli Access Manager for e-business

Shared Session Management Administration Guide

Tivoli Access Manager for e-business

Shared Session Management Administration Guide

Chapter 3. Using the session management server . . . . . . . . . 27

Chapter 4. Session management server best practices. . . . . . . . . . . . 35

Appendix A. SMS pdsmsadmin and pdadmin commands . . . . . . . . . 49

Appendix C. Support information . . . 95

Appendix D. Notices . . . . . . . . 101

Appendix B. SMS utilities. . . . . . . 81

Glossary . . . . . . . . . . . . . 105 Index . . . . . . . . . . . . . . . 115

Shared Session Management Administration Guide

About this publication

IBM Tivoli Access Manager for e-business library

Shared Session Management Administration Guide

Related products and publications

IBM Global Security Kit

IBM Tivoli Directory Server

About this publication

IBM Tivoli Directory Integrator

IBM DB2 Universal Database

IBM WebSphere Application Server

Accessing terminology online

Accessing publications online

Shared Session Management Administration Guide

Tivoli technical training

About this publication

Tivoli user groups

Conventions used in this publication

Shared Session Management Administration Guide

Operating system-dependent variables and paths

About this publication

Shared Session Management Administration Guide

Session management server administration options

Copyright IBM Corp. 2005, 2010

Figure 1. Integrated Solutions Console session management server extension menu

Session management server features

Shared Session Management Administration Guide

Session information consistency

Cluster-wide login policy enforcement

Session information management

Support for multiple instances

Limited session realms

Session management server architecture

Replica set WebSphere Application Server

IBM HTTP Server

WebSphere Web server plug-in

Session Management Server

Figure 2. Simple session management server architecture.

Shared Session Management Administration Guide

Junctioned servers Replica set

Load balancer Browser

WebSphere Application Server Session management server

Figure 3. A typical session management server architecture with WebSEAL

A.tivoli.com replica set

Load balancer Browser

WebSphere Application Server Session management server

Tivoli Access Manager communications Policy database

Tivoli.com session realm

Browser B.tivoli.com replica set

Session Management Server

WebSEAL replica 1 Junctioned servers WebSEAL replica 2

Shared Session Management Administration Guide