2.3 Design guidelines

< Day Day Up >

The following are guidelines to consider and decisions to make when designing a secure portal.

2.3.1 Centralized or local control

If your enterprise has multiple applications requiring security management then it is best to choose an external security management. This will consolidate the user registry and access control in one centralized system. Otherwise, a stand-alone WebSphere Portal security system will suffice. If an external security manager is chosen then a further decision must be made regarding whether to delegate authentication only or both authentication and authorization. Delegation of authorization only is not possible.

Using external authentication allows WebSphere Portal to become part of a larger Single Sign-On enterprise-wide system. Delegating both authentication and authorization centralizes the access management and can be a strong business driver for a company.

WebSphere Portal Server can integrate with Tivoli Access Manager and Netegrity SiteMinder.

2.3.2 User registry

For the user registry, there is a choice between using Directory Server or a custom registry. When using an external security manager, it is more or less implied that a Directory Server will be used. However, in a stand-alone secure WebSphere Portal, either can be chosen. Choosing LDAP would allow for easier integration to an external security manager at a later stage.

2.3.3 Encryption

There are a number of communication flows in the secure portal. Using a Secure Socket Layer (SSL) protocol ensures that these transmissions are confidential, even though the connections will be slower and the system more complex to set up.

2.3.4 Network infrastructure

Although infrastructure is not a focus for the secure portal, it is of vital importance in a real world scenario. A typical decision to be made is whether to use a reverse proxy to protect the portal server from the outside world. This would typically sit in a Demilitarized Zone (DMZ) in front of the portal. This extra protection would then influence where you choose to use SSL. Another example is to have the external security manager in its own DMZ.

2.3.5 Access management

Thought should be given to how fine grained the access management rules are required to be, for example at page or portlet level. Having too many resource objects can be complicated to manage and an overhead in the authorization lookup. A general rule would be to place shared or enterprise resources under central management and leave fine grained control in the portal. Also, the user registry structure design needs to take into consideration any planned integration at an enterprise-wide level. Lastly, intelligent password policies should be implemented, encompassing common user and password formats, retry limits and password update rules.

2.3.6 Product choices

At a certain point in the design cycle, a decision has to be made regarding which products to choose to implement the services required. This can be at a high level, for example, deciding which portal server to use, but there are also choices to be made after the prime software packages have been selected. In the secure portal solution, there are a number of alternatives available, for instance the database used for WebSphere Portal Server. In the secure portal, we have chosen the default Cloudscape database. This is a standards-based Java database providing complex SQL and JDBC but it is unable to deploy in a clustered environment. Cloudscape is appropriate for proof of concepts and development environments but for a production environment, a more robust database such as DB2® or Oracle should be considered. There is also a choice of an LDAP server with both WebSphere Portal Server and Tivoli Access Manager supporting Lotus Domino Directory, Active Directory and Novell eDirectory.

2.3.7 Future needs

Naturally, in planning an IT system, it is necessary to document any future requirements for which the secure portal may play a role or provide a building block. The most obvious example is for Single Sign-On. SSO allows a single user to log on to multiple applications and can come in many variants, for example a simple Web Single Sign-On solution where a browser can access multiple applications deployed on the same application server, or extended SSO with credential propagation (mapping and transformation of the user ID and password) to a back-end solution. The secure portal could also be used to form a central authorization service to control both front-end and back-end applications.

In the secure portal, the user registry and user repository are stored in an open industry standard LDAP server. This enables this user information to be potentially shared across multiple applications that support this standard. In the WebSphere Portal context, we principally think about collaboration products such as Sametime and Quickplace. Collaborative solutions allow chat, e-mail, and shared teamrooms to be exchanged between users. These utilize user data.

< Day Day Up >