9.5 Tivoli products for security

The following Tivoli products are not part of the WebSphere Everyplace Access product; they are optional components of a solution and they are widely used to implement security.

9.5.1 Tivoli Access Manager and Single Sign-On

From the user's perspective, Single Sign-On (SSO) is the ability to move between applications without being prompted for a user ID and password (or certificate) when moving from one application or datasource to another during the same user session. The solution that provides authentication, authorization and SSO is the Tivoli Access Manager.

There are a number of commonly encountered business requirements that justify the use of an authentication and authorization solution like Tivoli Access Manager:

Different back-end and Web content hosting systems require users to authenticate multiple times, which generates a negative user experience. In order to improve customer satisfaction, a method for single-user authentication has to be implemented.
Web security policies must be consistently applied across the business. Without a common security infrastructure, Web content and application security policies tend to be applied differently by various parts of the business.
The costs of Web security management must be predictable.
Threats of inadvertent security compromises or hacker attacks represent significant risks to business operations and company goodwill.

Access Manager's base functions are provided through a set of core components and various management components.

Core components

Access Manager is fundamentally based on two components:

An user registry that is based on a LDAP directory and provides:
- A database of the user identities
- A representation of groups in Access Manager (roles) that may be associated with users
An Authorization Service, consisting of an authorization database and an authorization engine. This is the foundation and it is responsible for permitting or denying access to protected objects (resources) based on the user's credentials and the access controls placed on the objects.

The authorization database is a special database containing a virtual representation of the resources that it protects and the definition of the security mechanisms. Some of these security mechanisms are:
- Access control list (ACL) policy templates - ACLs are special Access Manager objects that define policies identifying user types that can be considered for access, and specify permitted operations. In the Access Manager model, ACLs are defined separately from and then attached to one or more protected objects. Access Manager uses an inheritance model in which an ACL attached to a protected object applies to all other objects below it in the tree until another ACL is encountered.
- Protected object policy (POP) templates - A POP specifies additional conditions governing the access to the protected object, such as privacy, integrity, auditing, and time-of-day access. POPs are attached to protected objects in the same manner as ACLs.

Figure 9-4: Relationship between protected objects, ACLs and POPs

Management components

The Access Manager environment requires certain basic capabilities for administrative control of its functions. Management facilities are provided through the following base components:

The Policy Server, which supports the management of the authorization database and its distribution to Authorization Services. The purpose of the Policy Server is to maintain the master authorization database that contains the protected object space with the access control information (ACLs and POPs).
The pdadmin utility, which provides a command line capability for performing administrative functions, such as adding users or groups.
The Web Portal Manager, which provides a Web browser based capability for performing most of the same functions provided by the pdadmin utility.

WebSEAL

WebSEAL is a high-performance, multi-threaded reverse proxy, front-ending back-end Web service that applies a security policy to a protected object space. WebSEAL can provide Single Sign-On and incorporate back-end Web application server resources into its security policy. Being implemented on an HTTP server foundation, it listens to the typical HTTP and HTTPS ports.

In order to apply a security policy to any resource located in a back-end server, it has to be defined in WebSEAL a junction with this resource.

For example, suppose a junction on the WebSEAL host www.server1.com is defined such that a request for any URL specifying the path /content/xyz is to be proxied to the back-end Web server w3.server2.com. /content/xyz is the junction point and from the perspective of the browser, the request is processed by www.server1.com. To support this, WebSEAL performs various transformations of the response sent to the browser to assure that the back-end server names are not exposed (this is called virtualization of the back-end Web server and improves security).

Figure 9-5 on page 213 shows the components of the Tivoli Access Manager, the relationship between them and Single Sign-On solutions.

Figure 9-5: Tivoli Access Manager and Single Sign-On architecture

User authentication mechanisms

WebSEAL supports a number of client authentication mechanisms to protect access to a Web environment. WebSEAL can communicate with the clients with both encrypted (SSL) and unencrypted (TCP) protocols. The supported encryption types are SSL V1, SSL V2, SSL V3, and TLS V1. It also supports SSL hardware acceleration that can minimize the CPU impact of SSL and improve the overall performance of the system. Some of these mechanisms are:
- Basic authentication with user ID/password - Basic authentication (BA) is part of the HTTP standard and defines a standardized way in which user ID/password information is passed to a Web server.
- Forms-based login with user ID/password - The alternative to using basic authentication is the forms-based login. Rather than sending a basic authentication challenge in response to a client request, WebSEAL responds with a sign-in form in HTML format.
  
  Another benefit to using the forms-based login process is that you can enforce a time-based logout for authenticated sessions. The time values can be customized in the WebSEAL configuration files.
- Authentication with X.509 client certificates - In response to a certificate request from WebSEAL, as part of the SSL V3 tunnel negotiation, the browser prompts the user to select a certificate from the local certificate store or smartcard .
- Authentication with RSA SecurID token - Access Manager supports authentication of clients using user name /token pass code information from an RSA SecurID token authenticator (TAR), a physical device that stores and dynamically generates a piece of authentication data (a token).
- Authentication integration with WebSphere Everyplace Connection Manager- Access Manager provides an authentication mechanism for clients using a Wireless Gateway as WebSphere Everyplace Connection Manager; it can receive from it an "authenticated ID" and does not need to re-authenticate the user.
WebSEAL authentication with junctioned servers and delegation mechanisms

WebSEAL can authenticate itself to a junctioned server using either server certificates, forms-based authentication, or HTTP basic authentication. When using an SSL communication channel for this junction, WebSEAL and the junctioned server can also mutually authenticate one another. This is very important in order to establish the trust relationships between WebSEAL and back-end application servers.

WebSEAL can communicate with the back-end servers with both encrypted (SSL) and unencrypted (TCP) protocols. The supported encryption types are SSL V1, SSL V2, SSL V3, and TLS V1. It also supports SSL hardware acceleration that can minimize the CPU impact of SSL and improve the overall performance of the system.

After a user has been authenticated by WebSEAL and an authorization decision has been made, WebSEAL has to forward the user's request to a back-end Web application server. The mechanisms to forward that information and also provide a Single Sign-On solution are:
- WebSEAL junctions
  
  WebSEAL performs authentication while the back-end server handles its own authorization needs. It is recommended that you use a shared user registry to eliminate duplication of data.
  
  WebSEAL is configured to talk to a Web or application server behind it with a smart junction, which is a portion of a request URL that directs WebSEAL to forward the remainder of the URL path to the back-end Web or application server. A smart junction:
  - Allows the integration of multiple servers (WebSEAL or third-party) into one unified Web space.
  - Extends Access Manager security to third-party Web servers. WebSEAL provides authentication and authorization checking and enforcement services.
  - Allows growth of Web clusters with load balancing and fault-tolerant HTTP and HTTPS junctions.
  - Provides both TCP and SSL connections to back-end servers.
  Smart junctions can be configured to let WebSEAL modify the request header contents and basic authentication credentials before passing the request to a subsequent Web server. That is, WebSEAL can determine how the user ID and password are forwarded on.
- Web Trust Association Interceptor (TAI)
  
  This Single Sign-On method is supported by WebSphere and implies that WebSphere's security application recognizes and processes HTTP requests received from WebSEAL. WebSphere and WebSEAL engage in a contract in which the former will give its full trust to the latter, which means that WebSEAL will apply its authentication policies on every Web request that is dispatched to WebSphere.
  
  This trust is validated by the interceptors that reside in the WebSphere environment for every request received. The method of validation is agreed upon by WebSEAL and the interceptor.
  
  For detailed information on these options, refer to the IBM Redbook Enterprise Business Portals with IBM Tivoli Access Manager , SG24-6556-00.
- LTPA authentication
  
  This is a token-based lightweight third-party authentication mechanism (LTPA) that is supported by WebSphere Application Server and Lotus Domino.
  
  Considering an environment without WebSEAL, the token is created by WebSphere Application Server when a user authenticates, and is stored in a cookie that is passed back to the browser with the HTTP response. On subsequent accesses by the user, the token is extracted from the cookie and used to authenticate the user. In this way, the user enters their user ID and password only once, and the LTPA token identifies them after that. The drawbacks of this approach are twofold:
  - LTPA is supported only by WebSphere Application Server and Domino, and has not received industry-wide acceptance. Kerberos is a more widely used third-party authentication mechanism.
  - The user's credentials (in the form of the token) are passed all the way back to the browser and then back to the server with each request. This creates some vulnerability considering that the cookie is stored in the user machine and particularly if SSL is not used between the browser and Web server.
  With WebSEAL, the token never passes to the browser, avoiding a potential security vulnerability.
  
  When a user makes a request for a WebSphere resource, the user must first authenticate to WebSEAL. After successful authentication, WebSEAL generates an LTPA cookie on behalf of the user. The LTPA cookie, which serves as an authentication token for WebSphere, contains the user identity, key and token data, buffer length, and expiration information. This information is encrypted using a password-protected secret key shared between WebSEAL and the WebSphere server.
  
  WebSEAL inserts the cookie in the HTTP header of the request that is sent across the junction to WebSphere. The back-end WebSphere server receives the request, decrypts the cookie, and authenticates the user based on the identity information supplied in the cookie.
  
  To improve performance, WebSEAL can store the LTPA cookie in a cache and use the cached LTPA cookie for subsequent requests during the same user session. It can be configured with lifetime timeout and idle (inactivity) timeout values for the cached cookie.
  
  The trust association interceptor mechanism (TAI) is preferred to LTPA, because LTPA support is currently limited to WebSphere Application Server and Domino, and the TAI is faster considering that a token does not have to be encrypted and decrypted each time.
Single sign-on to WebSphere Portal Server

In order to provide Single Sign-On, the WebSphere Portal Server trust of WebSEAL is maintained through the junction between WebSEAL and the Web server. There are essentially two options for achieving Single Sign-On, and each handles trust of the requester differently. The two options are:
- Running WebSphere Portal Server in Trust Association mode (TAI), which allows WebSEAL to act as a front-end authentication server while WebSphere Portal Server applies its own authorization policy onto the resulting credentials that WebSEAL passes to it.
- Passing mapped usernames and passwords to WebSphere Portal Server, with which the target Web server can do its own authentication and add its own authorization policy.
With both options, both aspects of trust are maintained.

WebSphere Portal Server contains applications called portlets. Although WebSEAL can provide access control to these portlets, the portlets themselves often need to make further access control decisions, finer-grained than those controlled by WebSEAL. For example, these finer-grained access control decisions can help personalize the requesting user's Web browser screens. So, for flows coming through WebSEAL, to enable fine-grained processing, WebSEAL can be configured to pass user information, group information, or Access Manager credential information to the target portlets.

In conclusion, Access Manager and WebSphere Portal Server are based on different security models. The options below help Access Manager and WebSphere Portal Server users choose between one of the security models, or a mix:
- Access Manager as an end-to-end solution. You can choose to use Access Manager to manage access to all WebSphere Portal Server resources. Though this has the advantage of using a single security model, the disadvantage is that authorization cannot be as granular as in WebSphere Portal Server. Developers have to code to enforce fine-grained authorization on portal resources.
- Access Manager and WebSphere Portal Server for providing security solution. You can choose to have Access Manager and WebSphere security coexist. This has the advantage of no coding to enforce fine-grained authorization on portal resources. The disadvantages are redundant effort in defining ACLs, and maintaining and administering two security solutions.
Programmatic integration
- Java Authentication and Authorization Service (JAAS)
  
  The IBM Tivoli Access Manager (Tivoli Access Manager) authorization Java classes provide an implementation of Java security code that is fully compliant with the Java 2 security model and the Java Authentication and Authorization Service (JAAS).
  
  The Java 2 security architecture is policy-based, and allows for fine-grained access control. When code is loaded, it is assigned permissions based on the security policy currently in effect. Each permission specifies a permitted access to a particular resource, such as read access to a specified file, or connect access to a specified host and port.
  
  With the Java 2 and JAAS support delivered in Tivoli Access Manager, Java applications can invoke the Tivoli Access Manager-supplied JAAS LoginModule to acquire authentication/authorization credentials from Access Manager.
  
  This offers Java application developers the following advantages:
  - The security of Java applications is managed using the same consistent model as the rest of the enterprise.
  - Java developers do not need to learn anything additional beyond Java 2 and JAAS.
  - Updates to security policy involve Tivoli Access Manager-based administrator actions, rather than any code updates.
- Authorization Application Programming interface (aznAPI)
  
  The Access Manager aznAPI provides a standard programming and management model for integrating authorization requests and decisions with applications. Use of the aznAPI allows applications to utilize fined-grained access control for application-controlled resources.
  
  Application-specific resources may be individually defined, added to the protected object space and maintained in the authorization database in the same manner that WebSEAL defines their respective resources. ACLs and POPs may be attached to these application objects, and aznAPI calls may then be used to access the Access Manager Authorization Service to obtain authorization decisions.
  
  Access Manager provides a C version of the API and a Java version of the API, although the Java version is really a wrapper for the original C code.