Chapter 4. Security integration
4.1 Background security concepts
In this section, we discuss background security concepts that are important for you to understand before you begin to configure security for Tivoli products. We discuss these concepts:
4.1.1, “Lightweight Directory Access Protocol” on page 46
4.1.2, “WebSphere federated repositories” on page 48
4.1.3, “External authentication” on page 50
4.1.4, “Single sign-on” on page 51
4.1.1 Lightweight Directory Access Protocol
Lightweight Directory Access Protocol (LDAP) is an open industry standard that defines a common method for accessing and updating information in a directory.
The integration of various Tivoli products starts with sharing a common user repository. Having various components with separate technologies requires an integration point that is external to the products. We use the LDAP directory for coordinating security authentication issues.
A directory is a listing of information about objects arranged in a certain order that gives details about each object. Directories allow users or applications to find resources that have the characteristics needed for a particular task.
A directory contains a collection of objects organized in a tree structure. The LDAP naming model defines how entries are identified and organized. Entries are organized in a tree-like structure called the Directory Information Tree (DIT).
Entries are arranged within the directory tree based on their distinguished name (DN). A DN is a unique name that unambiguously identifies a single entry. DNs are made up of a sequence of relative distinguished names (RDNs). Each RDN®
in a DN corresponds to a branch in the directory tree leading from the root of the directory tree to the directory entry. A DN is composed of a sequence of RDNs separated by commas, such as cn=vbudi,ou=users,ou=SWG,o=IBM,c=US.
You can define your directory tree based on your organizational needs as shown in Figure 4-1 on page 47. Each RDN uses a qualifier that is used to signify a type of entity. This list shows several common qualifiers:
c country
The leaf nodes in the LDAP tree can have a set of attributes that further qualifies and defines the entity.
Figure 4-1 LDAP tree
In Figure 4-1, the tree starts with the node c=US. The main storage branch resides under ou=SWG,o=IBM,c=US. The main storage branch on which all processing (inserts, queries, and removals) is performed is typically called the suffix.
In IBM Tivoli Directory Server, users and groups are typically defined under ou=users and ou=groups nodes as shown in Figure 4-1. The leaf user node has the following important attributes:
uid User identifier
userPassword Binary field to hold the password
objectclass Separate supported objectclass for this user (typical object classes are inetOrgPerson, person, ePerson, and so on)
The leaf group node has the following important attributes:
objectclass Separate supported objectclass for this group entity members User members of the group
c = U S
LDAP is an TCP/IP-based application. It listens to the port 389 for plain communication and port 636 for Secure Sockets Layer (SSL) communication.
Use SSL for LDAP processing, because the LDAP traffic contains sensitive information. In our environment, we use non-SSL communication. However, in typical client environments, use SSL communication.
IBM Tivoli Directory Server implements the Internet Engineering Task Force (IETF) LDAP V3 specifications. It also includes enhancements that have been added by IBM in functional and performance areas. This version uses IBM DB2 Universal Database as the data storage to provide individual LDAP operational transaction integrity, high performance operation, and online backup and restore capability. IBM Tivoli Directory Server interoperates with the IETF LDAP
V3-based clients.
IBM Tivoli Directory Server has three base components:
IBM DB2 Universal Database is the data storage to provide individual LDAP operational transaction integrity, high performance operation, and online backup and restore capability.
The server executable is named ibmslapd.
Tools to administer and configure the directory. These tools rely on the directory administration daemon (ibmdiradm), which runs on each server machine and also enables remote management.
Using IBM Tivoli Directory Server, the initial authentication for the LDAP
connection uses a user ID in the bindDN field. The bindDN that is typically used is cn=root. For more information about LDAP, refer to Understanding LDAP - Design and Implementation, SG24-4986.
4.1.2 WebSphere federated repositories
WebSphere federated repositories is the latest addition to the authentication mechanism in WebSphere V6.1. Federated repositories is also known by several other names, such as WebSphere Identity Manager and Virtual Member
Manager.
Prior to WebSphere V6.1, user authentication is supported through one of the following repositories:
Local operating system
An LDAP directory
Custom user registry
Federated repositories allows users to be authenticated through one or more repositories. It not only allows read-only access, but it also allows the creation of users and groups to one of the defined repositories. The supported repositories for federated repositories include the following repositories:
File-based repository (this is the default)
Local operating system
An LDAP directory
Federated repositories provides the ability to map entries from multiple individual user repositories into a single virtual repository. A federated repository consists of a single named realm that consists of a set of independent user repositories.
Each repository can be an entire external repository or, in the case of LDAP, a subtree within that repository. The root of each repository is mapped to a base entry within the federated repository, which is basically a starting point within the hierarchical namespace of the virtual realm.
Note the following considerations for federated repositories:
You can only configure one user repository to be the target for creating users/groups from the administration console. By default, this one user repository is the file repository, but you can change the repository.
The username (for example, LDAP uid) must be unique across the various repositories. For example, users cannot have the same uid in separate LDAP directories, even under separate organizational structures.
If any repositories in the federation are down, you cannot authenticate (even as an admin), regardless of which repository your particular ID is stored in.
The federated repositories component always checks all repositories before letting an authentication succeed.
Although federated repositories has the capability to support multiple realms, WebSphere Application Server only supports a single realm at this time. This single realm support is defined at the cell level and is shared by all
applications.
The configuration file for federated repositories is stored in the WebSphere configuration. Federated repositories is activated when the current authentication method in the security.xml file under the profiles/<profile
name>/config/cells/<cellname> directory refers to the Wim repository. The settings of the federated repositories are stored in the wimconfig.xml file in the profiles/<profilename>/config/cells/<cellname>/wim/config directory.
Note: Even though you cannot configure a custom user registry in federated repositories using the administration console or the wsadmin command-line tool, certain Tivoli products introduce a custom user registry that participates in federated repositories.
Figure 4-2 describes the authentication mechanism for WebSphere to verify access for users.
Figure 4-2 Federated repositories authentication
Figure 4-2 shows the authentication process in WebSphere:
1. When a protected resource is accessed, WebSphere asks for a credential (user ID and password).
2. When there is no credential, WebSphere prompts for the user ID and password. The user ID is validated against the currently selected
authentication mechanism. Typically, the mechanism includes a verification to a user registry. When the user ID and password combination is valid, the credential is verified.
3. If there is an existing credential (such as a prior login or through an
Lightweight Third Party Authentication (LTPA) token), the credential is used to verify access.
4. The user ID and the group to which it belongs are checked against the protection role of the resource. If the user or any group to which it belongs has access to the role, the access is granted; otherwise, the access is denied.
Setting up LDAP as an authentication provider requires that the LDAP is used as the repository. We explain how to set up LDAP for inclusion in the federated repositories. Although the federated repositories allows the users to be defined on several repositories, the same user ID must not appear on separate
repositories.
4.1.3 External authentication
The external authentication mechanism uses the authentication client that connects to an authentication service inside a WebSphere cell. The components
request
Services. Figure 4-3 demonstrates the concept of the external authentication service.
Figure 4-3 External authentication
Figure 4-3 shows these concepts:
The external authentication provides a secure communication between the authentication service and the authentication client.
The authentication service resides in a WebSphere Application Server as an Enterprise Application. For IBM Service Management products, this
application is called authnsvc_ctges.ear. This authentication service interacts with Virtual Member Manager to authenticate, accept, or reject a user.
The authentication client accesses the authentication server using a Web Services SOAP call. The authentication server then provides an
authentication token. The authentication client acts as an extension of the local security mechanism for the client environment (such as Apache Tomcat for IBM Tivoli Application Dependency Discovery Manager).
4.1.4 Single sign-on
Single sign-on (SSO) is a mechanism that allows applications that reside on separate servers to cross-authenticate the user. Authenticated users on one application do not need to re-authenticate when accessing the other application.
Because Tivoli products use Web-based interfaces, SSO becomes a critical usability challenge as operators traverse multiple application servers to use
Note: Although external authentication can generate the LTPA token, IBM Tivoli Application Dependency Discovery Manager currently does not utilize this feature. Thus, you cannot launch with single sign-on from IBM Tivoli Application Dependency Discovery Manager.
separate products. Signing on multiple times using the same user ID and password pair is cumbersome and error-prone.
The most common mechanism to provide a single sign-on is to use the LTPA token. The LTPA token is a Web browser session cookie that contains an encrypted user ID and authentication information. Application servers that share the encryption information and use the same authentication can decrypt the information and use the existing authentication information. Figure 4-4 illustrates the LTPA token mechanism.
Figure 4-4 Single sign-on with LTPA
Figure 4-4 shows these processes:
1. The user authenticates on server1 with the user’s user ID and password by using a Web browser.
2. Application server server1 generates an LTPA token as a session cookie to the Web browser. This token is in an encrypted message.
3. All further requests to server1 are authenticated based on the LTPA token.
4. When the same user tries to access server2, while server2 shares the same TCP/IP domain as server1, the browser retains the LTPA token.
5. Upon receiving the LTPA token, server2 tries to decrypt the token based on its LTPA key pair.
6. When the token can be decrypted successfully and the user is authorized to access the resource in server2, the user obtains access to the resource in server2 without needing to log in.
TCP/IP domain
userID and password 2 authenticate
3 Reply and send LTPA token
4 New request with token
5 Validate token 6 Request granted
The following requirements apply for two application servers to allow SSO using an LTPA token:
They must use the same LDAP server for authentication information. The LTPA token can only be verified through the LDAP server.
They must reside in the same TCP/IP domain; otherwise, the LTPA token cookie is not sent to the server. In our sample environment, all servers have the same domain of itso.ral.ibm.com.
They must have synchronized time, because the LTPA token contains an expiration time stamp; this synchronization can be achieved using Network Time Protocol (NTP). We do not discuss NTP implementation in this IBM book.
They must share the LTPA encryption key to be able to decrypt the token.
You must enable LTPA authentication on both servers.
Regarding single sign-on, the LTPA token allows automatic login by preserving authentication information in a cookie. However, this capability does not provide the facility to perform an integrated sign-off. As an illustration, log in to Tivoli Integrated Portal to work with IBM Tivoli Netcool/OMNIbus, and then, open Tivoli Enterprise Portal to see the monitoring situation. Your LTPA token allows you to automatically log in to Tivoli Enterprise Portal. You then have a session with both Tivoli Integrated Portal and Tivoli Enterprise Portal. Assume you log out of the Tivoli Enterprise Portal session, but then, you decide that you must log back in.
When you log back in, you get a separate LTPA token. At this state, when you open Tivoli Integrated Portal, you present the new LTPA token; however, Tivoli Integrated Portal already has your user ID in session (with the previous token).
Therefore, Tivoli Integrated Portal does not allow you to log in because of the other session. You can mitigate the sign-off problem by using a session timeout for inactive sessions, or you can sign off explicitly from the application using a new browser window before re-invoking single sign-on.