|< Day Day Up >|| |
The following sections describe the security considerations and choices made in the secure portal implementation of WebSphere Portal and Tivoli Access Manager for e-business.
The SSL protocol has become a standard for providing secure network connections between applications. The current version of SSL is version 3.0. Its successor security protocol is now called TLS. The current version of TLS is 1.0 and it is backward-compatible with SSL 3.0. In our solution, we will use SSL/TLS technology to secure the following types of network connections:
HTTP which is frequently denoted as HTTPS when used with SSL/TLS.
LDAP which is frequently denoted as LDAPS when used with SSL/TLS.
Communication between Tivoli Access Manager for e-business components such as the Access Manager runtime environment connecting to a remote policy server.
SSL/TLS provides the following capabilities for network connection security:
Data integrity using message authentication codes
Authentication of the server application and, optionally, the client application as well
Some SSL/TLS issues to consider are:
Performance of the network connection may decrease because of the computationally-intensive calculations required for SSL/TLS
More complex installation and configuration if an application is not enabled for SSL/TLS by default
As previously mentioned, WebSphere Portal can integrate with an external security manager product. An external security manager will provide more features than the stand-alone security for WebSphere Portal. The following sections examine the security functions affected by integrating WebSphere Portal with Tivoli Access Manager for e-business.
Tivoli Access Manager for e-business is software that specializes in security services, particularly for Web applications. It can provide the following benefits to the secure portal:
Centralized security management - With Tivoli Access Manager for e-business as part of the security infrastructure in a heterogeneous environment, you can combine the security management of the secure portal with the security management of other applications. Security policies of the e-business can be administered from a central location and enforced on a more consistent basis.
WebSEAL - Acting as a front-end Web server proxy, WebSEAL improves security by not directly exposing the back-end servers to clients. WebSEAL adds a security proxy layer to the secure portal.
SSO - Tivoli Access Manager for e-business has comprehensive SSO features and integrates with a variety of applications.
If you are already using Tivoli Access Manager for e-business for your security infrastructure, WebSphere Portal can integrate with it.
Some Tivoli Access Manager for e-business issues to consider are:
Performance of the secure portal may decrease because of the added software components involved in executing authentication and authorization decisions
More complex installation and configuration of the secure portal
Authentication is the process of verifying the identity of a user. For WebSphere Portal, a user is identified by supplying a user name and password for login. These values are verified against the user registry, which is an LDAP server in this implementation of the secure portal. WebSphere Portal relies on the underlying WebSphere Application Server for these authentication services.
Use of WebSphere Portal's stand-alone authentication function is sufficient for some customers. However, in our solution, we will be using Tivoli Access Manager for e-business to perform authentication for WebSphere Portal.
Tivoli Access Manager for e-business offers the following enhancements for authentication:
User account disable or enable
User account expiration date
Login failure policy such as user lockout after three attempts
Password policy such as minimum length or maximum age
User access based on time of day or day of week
When you configure WebSphere Portal to use authentication from an external security manager, you are utilizing the WebSphere Application Server's capabilities for external authentication services and SSO.
Due to its extensible security model, WebSphere Application Server can be configured to use an external authentication system. WebSphere Application server externalizes its authentication service to Tivoli Access Manager for e-business by specifically integrating with the WebSEAL component.
Acting as a front-end Web server proxy, WebSEAL will challenge for the user identity when a Web browser client wants to enter the secure domain. The user identity is verified against the user registry and if it is valid, the user is allowed to enter the secure domain to attempt to access resources on the back-end servers.
The junction between WebSEAL and a back-end WebSphere Application Server can be configured for SSO so that Tivoli Access Manager for e-business will pass the user identity and/or user credentials to WebSphere Application Server (and thereby to WebSphere Portal also). Thus, a user will not be asked to authenticate multiple times when accessing applications in the secure domain.
There are two methods of SSO that can be used in the junction between WebSEAL and WebSphere Application Server:
Lightweight Third Party Authentication (LTPA)
Trust Association Interceptor (TAI)
Lightweight Third Party Authentication is intended for distributed, multiple application servers and machine environments. LTPA is able to support security in a distributed environment through the use of cryptography involving LTPA keys. This allows LTPA to encrypt and digitally sign and securely transmit authentication-related data and later decrypt and verify the signature.
A token, the transient cookie LtpaToken, is generated by the authenticating server. For the secure portal, the authenticating server is WebSEAL. The cookie is encrypted using LTPA keys which must be shared among all SSO-participating servers. The cookie contains user authentication information, the network domain in which it is valid for SSO, and an expiry time.
The Trust Association Interceptor feature is another way to achieve SSO by establishing trust between WebSphere Application Server and a third-party proxy that provides authentication services. Rather than relying on a pre-defined token as in the case of LTPA, TAI defines an application programming interface (API) which allows WebSphere Application Server to use any available method to validate an input stream.
A TAI is a Java class which implements the com.ibm.WebSphere.security.TrustAssociationInterceptor interface. Each implementation of a TAI is specific to the characteristics of the proxy being used.
The WebSEAL TAI, running on the WebSphere Application Server, validates the HTTP requests received by WebSphere Application Server from WebSEAL. After successful validation of the WebSEAL requests, the interceptor returns the real client's user ID in the HTTP Basic Authentication (BA) IV_USER header. The WebSphere Application Server security runtime then maps the client's user ID to a valid LTPA credential that is used internally for authorization purposes.
Further comparison between and information on these two SSO technologies can be found in the IBM WebSphere V5.0 Security WebSphere Handbook Series (SG24-6573) redbook.
The decision to use LTPA or TAI at the junction between WebSEAL and a back-end server is ultimately dependent on the customer's configuration. For example, some products, such as Lotus Domino, currently do not support TAI. In our solution, we will implement the junction with TAI in order to keep from having a copy of the LTPA keys on the WebSEAL machine in the insecure environment.
If you plan to extend your secure Portal with the Portal Extend offering which includes Lotus Domino, then you need to configure the junction using LTPA. For more information, refer to Securing your collaborative portal using WebSEAL, TIPS0331.
|< Day Day Up >|| |