Actividades y servicios culturales

In this section, we discuss the common configuration needs for preparing and implementing security integration for Tivoli products. The discussion is divided into these topics:

򐂰 4.2.1, “IBM Tivoli Directory Server implementation” on page 54

򐂰 4.2.2, “Security setup considerations” on page 54

򐂰 4.2.3, “Setting up LDAP authentication for federated repositories” on page 55

򐂰 4.2.4, “Setting up single sign-on on multiple WebSphere cells” on page 55

4.2.1 IBM Tivoli Directory Server implementation

In our environment, we install IBM Tivoli Directory Server using the Middleware Installer from Tivoli Process Automation Engine. We install IBM Tivoli Directory Server on a separate server than the IBM Service Management product to simulate a common need from enterprises to install a stand-alone corporate directory server for all products.

You can obtain the documentation for IBM Tivoli Directory Server at this Web site:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?toc=/c om.ibm.IBMDS.doc/toc.xml

You can obtain the middleware installer documentation at this Web site:

http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/topic/com.ibm.c cmdb.doc_7.1.1/install/c_ccmdb_ccmdbcmiddlewareoverview.html

4.2.2 Security setup considerations

In this section, we discuss the procedure to enable LDAP authentication for WebSphere Application Server with federated repositories. This procedure is similar for any WebSphere Application Server V6.1-based product, even the embedded WebSphere server. However, certain products keep their own custom authentication to participate in the overall authentication, such as:

򐂰 IBM Tivoli Netcool/OMNIbus authentication for Netcool products

򐂰 Tivoli Enterprise Monitoring Server-based authentication for IBM Tivoli Monitoring

When you further evaluate how the products activate security, you see subtle differences in how the products configure security:

򐂰 Products have a preset realm name, such as ISMRealm or TIPrealm. Other products use the default realm name, such as DefaultWIMFileBasedRealm. In our environment, we use a custom realm called itsorealm to ensure that we modify and synchronize these realms. The realm information is critical for the SSO implementation.

Note: Apart from IBM Tivoli Directory Server, you can use another

implementation of LDAP, such as Microsoft® Active Directory®, or you can use the z/OS® Security Server. Your choice depends on the overall security strategy of your enterprise.

򐂰 A product’s security configuration might leave the default file-based authentication or remove the file authentication entry. This file-based authentication must not contain any user information, because a user entry must not reside in more than one repository.

򐂰 Products might use a specific basic entry mapping for the repository. This basic entry mapping allows a user to be custom-defined in the managing application. For example, IBM Tivoli Monitoring uses an entry mapping of o=ITMSSOEntry for the base suffix that we provide.

Non-WebSphere-based processes can also use federated repositories or LDAP for authentication by using individual authentication to LDAP or by using the external authentication services facility.

4.2.3 Setting up LDAP authentication for federated repositories

The following steps activate LDAP authentication for federated repositories. We discuss steps in detail for each individual product in other sections. These steps provide an overview:

1. Activate global security in WebSphere. You can activate or deactivate global security using the administration console or the wsadmin interface.

2. Modify the federated repositories setting to add an LDAP repository that points to the LDAP server with the appropriate credential.

3. Modify the suffix list for the federated repository to add the appropriate suffix and its mapping for the authentication.

4. Verify the object creation suffix for the creation interface so that new users and groups can be created using the security administrative interface.

5. Verify the object class and field identifier to use to identify users and groups.

6. Save the modification and restart WebSphere.

4.2.4 Setting up single sign-on on multiple WebSphere cells

Setting up single sign-on requires the following tasks:

1. Single sign-on requires setting LDAP authentication as discussed in 4.2.3,

“Setting up LDAP authentication for federated repositories” on page 55.

Note: In case you experience a problem after enabling the security and you cannot get into WebSphere, you can disable security by editing the security.xml file under the profiles/config/cells/<cellname> directory.

Stop the Java process and restart WebSphere.

2. You must set the realm for the federated repositories to the same realm for all participating servers. We decide in our environment to use the realm called itsorealm.

3. All servers participating in single sign-on must enable SSO and ensure that the domain name is the same. The LTPA cookie is passed as a session cookie at the Web browser. You can set the session cookie to be active only for a certain domain.

4. Servers participating in SSO must encrypt and decrypt the token using the same key. This key must be exported from one of the participants, and then, the exported key must be imported to all of the SSO participants.

5. WebSphere has a facility to automatically generate the SSO key. You must disable this facility. Otherwise, every time that the key is regenerated, it must be exported and then imported again.