Protecting Tivoli Integrated Portal with Tivoli Access Manager for e-business
This chapter describes the value of using a high-performance, multi-threaded reverse proxy (Tivoli Access Manager WebSEAL component) to “front-end” the Tivoli Integrated Portal interface. This integrated solution provides an authentication and authorization framework to allow controlled access to the Tivoli Integrated Portal. This solution is extremely valuable in cases where access to the Tivoli Integrated Portal is required outside of an organization over the Internet.
This chapter contains the following topics:
10.1 Scenario overview and products involved
The Tivoli Access Manager extended Trust Association Interceptor (referred to as eTAI in this chapter) establishes “trust” in WebSphere Application Server, performs user authentication, and inserts credentials information into the HTTP request.
|
Trust associations: WebSphere Application Server supports single sign-on (SSO) with perimeter authentication services through trust associations. When trust associations are enabled, WebSphere Application Server does not need to authenticate a user if a request arrives through a trusted source that has already performed the authentication.
|
The Tivoli Integrated Portal with eTAI plug-in provides validation of trust with the perimeter authentication service and extraction of credential information from the request. A user that is accessing the Tivoli Integrated Portal leveraging the extended Trust Association Interceptor with WebSEAL goes through the flow shown in Figure 10-1.
Figure 10-1 Tivoli Integrated Portal and WebSEAL integration flow
The figure shows the following steps:
1. The user login request is intercepted by WebSEAL (possibly through other proxies) and is prompted to authenticate.
2. WebSEAL authenticates the user and acquires credentials for the user from the user registry.
3. WebSEAL augments the request with an additional HTTP header (iv-creds) that contains the user's credentials. The password contained in the header is changed so it matches a configured SSO user. This request is sent to WebSphere Application Server.
4. Tivoli Integrated Portal receives the request and calls a TAI method (isTargetInterceptor) to determine whether the request is from a perimeter authentication service that has already authenticated the user.
5. Tivoli Integrated Portal calls a TAI method (negotiateValidateandEstablishTrust) to establish trust with the perimeter authentication server. This method establishes trust with WebSEAL by checking that the BA header contains the correct password for the configured SSO user. Trust between WebSEAL and Tivoli Integrated Portal cannot be established using mutually authenticated SSL sessions and can only be established by verifying the SSO password. No checking of certificates is performed by the TAI.
6. Tivoli Integrated Portal then retrieves the credentials. The iv-creds header is extracted from the request and used to retrieve the short name of the WebSEAL authenticated user, and credential object containing user and group information. Tivoli Integrated Portal then returns the authenticated user information and WebSphere Application Server has valid credentials that it can use for making authorization decisions in the usual J2EE manner.
The important points to note here are as follows:
•WebSEAL must insert the iv-creds header into the request.
•The new TAI can be configured to authenticate trust using either the Tivoli Access Manager Authorization Server or the WebSphere Application Server user registry directly.
•The credential object is inserted into the Subject by the TAI, which means that WebSphere Application Server does not have to perform any additional user registry searches as part of the authentication process.
•The user information that is extracted from the iv-creds header can have the dn format mapped from the initial format into the required format of the WebSphere Application Server user registry.
10.2 Benefits
In this section, we discuss the key benefits of protecting the Tivoli Integrated Portal with the IBM Tivoli Access Manager WebSEAL solution.
•Value of IBM Tivoli Access Manager for WebSEAL
•Value of Tivoli Integrated Portal
•Value to Tivoli Integrated Portal and WebSEAL Integrated Solution
10.2.1 Value of Tivoli Access Manager WebSEAL
IBM Tivoli Access Manager WebSEAL is the resource manager responsible for managing and protecting web-based information and resources. WebSEAL is a high performance, multi-threaded web server that applies fine-grained security policy to the Tivoli Access Manager protected web object space. WebSEAL can provide single sign-on solutions and incorporate back-end web application server resources into its security policy. WebSEAL normally acts as a reverse web proxy by receiving HTTP/HTTPS requests from a browser and delivering content from its own web server or from junctioned back-end web application servers.
Requests passing through WebSEAL are evaluated by the Tivoli Access Manager authorization service to determine whether the user is authorized to access the requested resource. WebSEAL provides the following features:
•Supports multiple authentication methods
•Accepts HTTP and HTTPS requests
•Integrates and protects back-end server resources through WebSEAL junction technology
•Manages fine-grained access control for the local and back-end server web space
•Supports resources including URLs, URL-based regular expressions, CGI programs, HTML files, Java servlets, and Java class files.
•Performs as a reverse web proxy
•Centrally manages user access and enforces Web SSO to the Tivoli Integrated Portal, and also to the Tivoli Common Reporting and other web applications across the enterprise.
WebSEAL appears as a web server to clients and appears as a web browser to the junctioned back-end servers it is protecting.
10.2.2 Value of Tivoli Integrated Portal
Web-based products built on the Tivoli Integrated Portal Infrastructure share a common user interface where you can launch applications and share information. Tivoli Integrated Portal helps the interaction and secure passing of data between Tivoli products through a common portal. You can launch from one application to another and within the same dashboard view to research different aspects of your managed enterprise. Tivoli Integrated Portal provides the following features:
•Services to support a console for individual products and for integrating multiple products.
•Views that span server instances, such as the Tivoli Netcool/OMNIbus ObjectServer and Tivoli Enterprise Portal Server
•A web-based user interface with inter-view messaging between products such that the data in, for example, a single tabulated report, can be gathered from multiple products.
•A common task navigator for multiple products that makes for convenient selection by the task and not necessarily by the product you need to use to perform that task.
•An integration point for Netcool products. Products that in previous versions were running on the Netcool GUI Foundation (NGF) now use Tivoli Integrated Portal, enabling greater interoperability among products that are built on this converged platform or are compatible with it.
10.2.3 Value to Tivoli Integrated Portal and WebSEAL Integrated Solution
Starting with Tivoli Integrated Portal 2.1, Tivoli Integrated Portal is a J2EE application running in embedded WebSphere Application Server so it can take advantage of and benefit from many of the functions that WebSEAL, provides other web applications. In this case, Tivoli Access Manager WebSEAL is used as a reverse proxy intercepting any incoming HTTP or HTTPS requests and ensuring that users are authenticated and authorized for the request to continue onto the necessary Tivoli Integrated Portal server. In addition, WebSEAL allows for single sign-on of the authenticated user where the credential is passed from WebSEAL to the downstream Tivoli Integrated Portal Server which ensures that the user does not need to reauthenticate at any time.
10.3 Integrating a Tivoli Integrated Portal environment with IBM Tivoli Access Manager WebSEAL
In this section, we discuss the steps required to integrate Tivoli Integrated Portal and IBM Tivoli Access Manager WebSEAL:
10.3.1 Configuring for integration: Tivoli Integrated Portal
The following key configuration steps are performed in the Tivoli Integrated Portal for this integration:
1. Enable Trust Association in the Tivoli Integrated Portal Console; click Security → Secure administration, applications, and infrastructure. See Figure 10-2.
2. Click Web Security → Trust Association.
Figure 10-2 Enabling Trust Association
3. Enable trust association must be selected. If it is not already selected, select it and click Apply.
4. Save the configuration changes.
5. Add the extended trust association interceptor by starting at the Trust association page and click Interceptors. See Figure 10-3.
Figure 10-3 Interceptors
6. If com.ibm.sec.authn.tai.TAMETai class is not defined, click New. On the following window enter com.ibm.sec.authn.tai.TAMETai into the Interceptor class name field, and click Apply.
7. Save the configuration changes.
8. Next add custom properties to TAMETai by starting at the Interceptors page.
9. Select the com.ibm.sec.authn.tai.TAMETai Interceptor class.
10. Go to the Custom properties page.
Figure 10-4 Custom Properties
12. For each required property that is not defined, click New and then enter information in the required Name and Value fields. Click Apply. See Figure 10-5.
Figure 10-5 Define the properties
The results are in the Custom property definition as shown in Figure 10-6.
Figure 10-6 Custom property definition
13. If the custom property already exists but does not contain the correct Name, Value, or Description, select that property, change what is necessary, and click Apply.
14. Repeat for all required properties that are listed in the table in Figure 10-7 on page 299.
Figure 10-7 WebSEAL
15. Save the configuration changes.
16. Restart the Tivoli Integrated Portal Server.
10.3.2 Configuring for integration: Tivoli Access Manager WebSEAL
The key configuration steps in this section are performed in the Tivoli Access Manager WebSEAL for this integration.
For the eTAI to be able to accept requests from WebSEAL, several tasks must be performed on the WebSEAL server to ensure that an eTAI-targeted HTTP request is sent:
•Creating the junction with the required parameters
•Creating a trusted single sign on user
•Setting the dummy password in the configuration file
Perform the following steps:
1. Create the junction with the required parameters. The following two parameters are required by the eTAI:
-b supply Ensures that WebSEAL inserts a basic authentication header in the HTTP request. The eTAI requires the dummy password in the BA header; the user name is not used. The header is used as part of the trust establishment, which is separate from the credentials originating from the client.
-c iv-creds Ensures that WebSEAL passes the logged-in users credential in an iv-creds header in the HTTP request. The eTAI requires that this header exists or it will not handle the request. Other headers can also be passed such as iv-user but the iv-creds header must also be passed.
The following command creates the junction:
server task "webseal_instance_name" create -b supply -c iv-creds -t tcp -h "websphere_hostname" -p "websphere_app_port_number" "junction_name"
2. To create a trusted single sign on user the eTAI requires a user to exist in the user registry that will be used to authenticate trust. This user and its password become the central part of establishing trust between WebSEAL and Tivoli Integrated Portal.
The value of the following custom property will be set to this user and the dummy password that is sent by WebSEAL in the inserted BA header will be set to this user’s password.
com.ibm.websphere.security.webseal.loginId
If the following custom property is not set to true, this user must be created in the Tivoli Access Manager user registry.
com.ibm.websphere.security.webseal.useWebSphereUserRegistry
Creating a user can be done by using the pdadmin utility, as shown the following example:
user create sso cn=sso,o=ibm,c=au sso sso ssopwd
user modify ssouser account-valid yes
3. WebSEAL provides a mechanism for specifying the password that is passed in the basic authentication header of the HTTP request. This is done by setting the dummy password in the WebSEAL instance configuration file and using the –b supply junction parameter. The configuration file to update is located in your <webseal_home>/etc directory and has the following name:
webseald-<instancename.conf>
4. Open this file, search for basicauth-dummy-passwd, and set the value of this property to be the password of the trusted single sign on user.
The scenario is now customized.
10.4 Summary
Figure 10-8 shows the quick summary of this integration.
Figure 10-8 Quick summary
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.