|< Day Day Up >|| |
The requirements analysis outlined in 2.1, "Requirements analysis" on page 14 is one of the inputs taken into consideration by solution design. Other inputs typically are the system context and business rules. The system context is the relationship of the system being built to external/existing systems. Business rules are the general business policies that may exist in a company. For example, all marketing users must belong to a special authorization group. These are not so relevant in this instance.
We have now discussed the needs and requirements that are driving the secure portal design. The next step is to detail the solution that we have developed to fulfill those requirements. The architecture overview diagram shown next is intended to provide a clear conceptional understanding of the secure portal IT system. It is presented firstly from the functional view, describing key concepts and subsystems, and then from the operational view.
This functional view diagram shows the main subsystems and connections involved in the secure portal.
Figure 2-2: Secure portal functional view
If you plan to extend your secure Portal with the Portal Extend offering which includes Lotus Domino, then you need to configure the WebSEAL junction using LTPA. For more information, refer to Securing your collaborative portal using WebSEAL, TIPS0331.
Here we outline the key concepts and subsystem's responsibilities in the overall solution.
All requests and responses are directed through the authentication proxy. It is responsible for managing the authentication process. It uses the Directory Server to access the user registry for user ID and password information. In our system, we have chosen Tivoli Access Manager's reverse proxy, WebSEAL. A reverse proxy is a component which is generally used to perform URL mapping and manage user sessions in order to protect the Web site's structure from the outside world, but it can also be used for authentication. In this solution, we will use authentication based on Trust Association Interceptors; refer to "Trust association interceptor" on page 25.
This subsystem provides the authentication information from the user registry and the user profile information from the user repository. It is possible for the user registry and user repository to be separate datastores, hence the different naming. Information is accessed and updated through Lightweight Directory Access Protocol (LDAP). This is an open industry standard for directory servers. In our system, we use the IBM Directory Server and the LDAP communication has been encrypted using SSL.
This is a database which contains user account information, typically a user ID and password.
This is a database which contains user profile information, for example a name or an address.
This is responsible for the security management of the system. In this case, it is Tivoli Access Manager Policy Server and Authorization Server. The policy server maintains the master policy store with authorization and access control data. The authorization server offloads the authorization decisions from the policy server when requests are made.
A repository of groups and access control lists (ACLs). This is used by the authorization server for access control for portal resources.
This is the Java application server responsible for J2EE services, one part of which is Security Services, which creates the client authentication tokens. In this case, WebSphere Application Server creates a Lightweight Third-Party Authentication (LTPA) token. The user ID is encrypted in the LTPA token and can be used for authentication by servers that trust the issuer of the token, typically in an SSO scenario. LTPA is an IBM technology.
The portal engine is responsible for the execution and rendering of the portal. We are using WebSphere Portal Server. The WebSphere Portal Server uses the JAAS API to determine the access rights on a resource that has been externalized to Tivoli Access Manager.
The Trust Association Interceptor is responsible for establishing trust between the application server and the authentication proxy. It validates the request and provides the user ID to the application server obtained from the authentication proxy. The WebSEAL Trust Authentication Interceptor is the default with WebSphere Application Server although it is possible to add other vendor versions.
This is defined as SSL authentication by both the client and server. This ensures that only certified clients have access to the server. In our solution, we want only requests from the authentication proxy and the Web server to be served by the application server.
Typically, in a production environment, we would have the following environment:
Internet -> firewall -> DMZ -> firewall -> security node -> application node
We simply show the following in the diagram below:
The Internet, where both the customer and the security administrator will access the system.
The external network is to represent a company's external network. We have chosen to define this location with a direct connection to the Internet but outside the company's internal network, protected by a firewall. This is due to the removal of DMZs and firewalls in the definition of the secure portal. Although we have chosen to remove the DMZ so as not to have to address firewall configuration issues, there is nothing to prevent it from being deployed inside the firewall or spanning the firewall as long as the firewall is properly configured. The system will include two physical nodes, security and application. For further information on a production environment, including the security and application node, refer to Enterprise Business Portals II with IBM Tivoli Access Manager, SG24-6885.
This describes the secure portal IT system from the operational or infrastructure view.
Figure 2-3: Secure portal operational view
This represents a physical node that is responsible for providing the following security services.
Access management services
This node's chief role is to fulfill the non-functional security requirements. This includes central access management; therefore, the user data is located here.
This represents the physical node that is responsible for providing application services, such as generation of the user's portal. Application-specific user and business data is held here.
This section presents a simple step-by-step technical walkthrough for a user accessing the secure portal. It covers both authentication and authorization and the aim is to provide a clear picture of the activities and communications taking place.
The request is received by the authentication proxy.
The authentication proxy determines that this is a secure resource and therefore challenges the user for authentication. This can be HTTP authentication or form-based logon for WebSEAL.
The client responds with their user ID and password.
The authentication proxy authenticates the user ID and password against the user registry. Once authenticated, WebSEAL creates a cookie for the client to use for future identification.
The authentication proxy then places the user credential information into the HTTP header and forwards the request to the application server.
The application server captures the request and calls the Trust Association Interceptor to obtain the user's credentials.
The application server then performs a lookup of the user in the user registry. If this is successful, the application server creates an LTPA token to identify the client.
The request is then passed to the Portal Server and the output returned through authentication proxy to the user.
Also in the default installation, the cookies set by WebSphere are transformed by WebSEAL as coming from the reverse proxy and passed out to the client.
The prerequisite is that authentication has already taken place and the necessary user credentials exist for the client.
The request is received by authentication proxy.
The authentication proxy forwards the user credentials stored in the client's cookie to the application server.
The user is already authenticated so the request is forwarded by the application server to the portal server.
The portal server then checks the authority rights for the requested resource. If the resource's access control has been externalized then WebSphere Portal Server uses the Tivoli Access Manager JAAS API to retrieve the permissions.
The portal server uses the JAAS API to query the authorization server for the users/user groups membership for a particular portal role for that resource.
For more information on roles, please refer to Appendix A, "Access Control Model in WebSphere Portal V5" on page 249. For example, if the marketing page has the role editor, then portal would query TAM to see if the current user belongs to the users/groups that have that editor role.
The permission level is then deduced and a successful/unsuccessful output is returned as appropriate.
|< Day Day Up >|| |