WebSphere Process Server plays an integral part of the multiple-tier enterprise computing framework. WebSphere Process Server adopts the open architecture paradigm and provides many plug-in points to integrate with enterprise software components to provide end-to-end security. WebSphere Process Server plug-in points are based either on SCA or standard J2EE specifications wherever applicable. The WebSphere Process Server development team is actively involved in various standards bodies to externalize and to standardize plug-in interfaces.
In the following example, several typical multiple-tier enterprise network configurations are discussed. In each case, various WebSphere Process Server plug-in points are used to integrate with other business components. The discussion starts with a basic multiple-tier enterprise network configuration:
Terminology
A list of terms used in this discussion follows:
Protocol firewall
A firewall that prevents unauthorized access from the Internet to the demilitarized zone. The role of this node is to provide the Internet traffic access only on certain ports and to block other IP ports.
Firewalls can be used to create demilitarized zones, which serve as machines that are isolated from both the public Internet and other machines in the configuration. This isolation improves portal security, especially for sensitive back-end resources such as databases.
Domain firewall
A firewall that prevents unauthorized access from the demilitarized zone to an internal network. The role of this firewall is to allow the flow of the network traffic that is originating from the demilitarized zone and not from the Internet.
User-registry
A user-registry is a data store that normally contains information about a user. The information can contain user IDs, passwords, certificates, access groups, and so forth. In the context of WebSphere Process Server, the user-registry will provide information about the users and their rights in the application. The user-registry supplies the information to the security services like authentication and authorization service.
Enterprise information system
A system that represents existing enterprise applications and business data in back-end databases.
The Web server plug-in
WebSphere Process Server provides the infrastructure to run application logic and to communicate with the internal back-end systems and database that Web applications and enterprise beans can access. WebSphere Process Server has a built-in HyperText Transport Protocol SSL (HTTPS) server that can accept client requests. A typical configuration, however, places WebSphere Process Server behind the domain firewall for better protection. A WebSphere Process Server plug-in to the Web server configuration can redirect Web requests to WebSphere Process Server. WebSphere Process Server provides plug-ins for many popular Web servers.
You can configure WebSphere Process Server and the Web server plug-in to communicate through Secure Sockets Layer (SSL) channels. You can configure a WebSphere Process Server HTTP server to open communication channels with a restricted set of Web server plug-ins only.
You can configure the HTTP server to require client certificate authentication with self-signed certificates and to trust only the signer certificate.
For instructions on how to generate self-signed certificates and how to set up secure communications channels between an HTTP server and the WebSphere Process Server plug-in, refer to Configuring the Web server plug-in for Secure Sockets Layer and Configuring IBM HTTP Server for Secure Sockets Layer mutual authentication in the WebSphere Application Server Information Center.
The WebSphere Process Server plug-in routes HTTP requests according to the virtual host and port configuration and URL pattern matching. Client authentication and finer-grained access control are handled by WebSphere Process Server behind the firewall.
Tivoli WebSEAL
In cases where the Web server can contain sensitive data and direct access is not required, the following configuration uses Tivoli WebSEAL to shield a Web server from unauthorized requests. WebSEAL is a reverse proxy security server (RPSS) that uses Tivoli Access Manager to perform coarse-grained access control to filter out unauthorized requests before they reach the domain firewall. WebSEAL uses Tivoli Access Manager to perform access control. In addition, WebSEAL can be configured to handle the authentication process on behalf of the WebsSphere Application Server.
User registry implementations
WebSphere Process Server supports various user registry implementations through the pluggable user registry interface.
For Windows and AIX, WebSphere Process Server ships a Local OS user registry implementation for several platforms and Lightweight Directory Access Protocol (LDAP).
WebSphere Process Server also supports users in developing their own custom registry and plug-in through the pluggable user registry interface. When integrated with a third-party security provider, WebSphere Process Server can share the user registry with the third-party security provider. In the particular example of integrating with WebSEAL, you can configure WebSphere Process Server to use the Lightweight Directory Access Protocol (LDAP) user registry, which can be shared with WebSEAL and Tivoli Access Manager. Moreover, you can configure WebSphere Process Server to use the Lightweight Third Party Authentication (LTPA) mechanism, which supports the trust association interceptor plug-in point.
Basically, the RPSS performs authentication and adds proper authentication data into the request header and then redirects the request to Web server. A trust relationship is formed between an RPSS and WebSphere Process Server, and the RPSS can assert client identity to WebSphere Process Server to achieve single signon (SSO) between RPSS and WebSphere Process Server. When the request is forwarded, WebSphere Process Server uses the TAI plug-in for the particular RPSS server to evaluate the trust relationship and to extract the authenticated client identity. WebSphere Process Server maps the client identity to a WebSphere Process Server security credential. For instructions on setting up a trust association interceptor, refer to Trust associations, Configuring trust association interceptors in the WebSphere Application Server Information Center.
When configured to use the LDAP user registry, WebSphere Process Server uses LDAP to perform authentication. The client ID and password are passed from WebSphere Process Server to the LDAP server. You can configure WebSphere Process Server to set up an SSL connection to LDAP so that passwords are not visible. To set up an SSL connection from WebSphere Process Server to the LDAP server, refer to Configuring Secure Sockets Layer for the Lightweight Directory Access Protocol client in the WebSphere Application Server Information Center.
J2EE Connector Architecture (J2CA)
WebSphere Process Server supports the J2EE Connector Architecture. J2CA or JCA can be used to abbreviate J2EE Connector Architecture, but this documentation uses J2CA. The connector architecture defines a standard interface for WebSphere Process Server to connect to heterogeneous enterprise information systems (EIS). Examples of EIS include database systems, transaction processing, such as CICS, and messaging such as Message Queue (MQ).
The EIS implementation of environments, servers and monitors can perform authentication and access control to protect resources and business data. Resource adapters authenticate EIS. The authentication data can be provided either by application code or by WebSphere Process Server. WebSphere Process Server provides a principal mapping plug-in point. A principal mapping module plug-in maps the authenticated client principal to a password credential, that is, user ID and password, for the EIS security domain. WebSphere Process Server ships a default principal mapping module, which maps any authenticated client principal to a configured pair of user IDs and passwords.
You can configure each connector to use a different set of IDs and passwords. For a description on how to configure J2CA principal mapping user IDs and passwords, refer to Managing J2EE Connector Architecture authentication data entries in the WebSphere Application Server Information Center.
Mapping modules
A principal mapping module is a special purpose Java Authentication and Authorization Service (JAAS) login module. You can develop your own principal mapping module to fit your particular business application environment. For detailed steps on developing and configuring a custom principal mapping module, refer to the articles: Developing your own J2C principal mapping module, and Configuring application logins for Java Authentication and Authorization Service in the WebSphere Application Server Information Center.
Last updated:
Copyright IBM Corporation 2005.
This information center is powered by Eclipse technology (http://www.eclipse.org)