Cluster security
Security is enabled by default for the WAS deployment manager. WebSphere Portal will NOT attempt to change the security settings in the deployment manager cell whenever a node is federated. This means that any existing security configuration of a stand-alone portal is lost when it joins a deployment manager cell and picks up the security settings of the cell.
The default security that will be enabled on the installation of deployment manager profiles and portal profiles is the Virtual Member Manager (VMM) federated security with a single file-based repository configured. Since security settings are not carried over from a stand-alone node into a deployment manager cell, there is no need to modify this default security setting on a portal node when the purpose of that node is to join a deployment manager cell and run as part of a cluster. Any updates to the default security should be done in the deployment manager cell.
There are many security options that can be used in a cluster. All of the VMM federated security options, including...
- multiple LDAP repositories
- database repositories
- default file-based repository
...can be used.
Production clustered environments will not want to rely solely on the file-based repository that is enabled by default...
- The contents of the file-based repository are sent to each node in the cell using deployment manager file synchronization, so this is not the ideal implementation for a large volume of users and groups
- Synchronization does not occur at the same time for all nodes in a cell, so there will be time windows where the nodes in the cell do not have identical security definitions.
After federating a portal node, execute security tasks on the deployment manager.
When setting up a cluster, there are two scenarios that must be considered
- When the default VMM file-based repository security is used at both the portal nodes and the deployment manager until after the portal cluster is completely set up.
Prior to federating the first portal node into the cell, the required group for portal administrators must be defined in the deployment manager’s security repository. Once the cluster has been set up, modify the security settings of the cell. Although it is possible to modify security in the cell using the WAS administrative interfaces, you should use the portal security tasks to change cell security in order to ensure that the security configuration settings for WAS and portal are identical.
- When the existing deployment manager cell has already modified its default security setting prior to the first portal node joining the cell.
WebSphere Portal supports the capability of using two different sets of administrative user ID and password credentials when federating a portal node into a cell...
- One set for the portal node authentication
- One set for deployment manager authentication
This means that it is not necessary to define a common administrative user ID before portal joins the cell. If the deployment manager cell is using federated VMM with additional repositories, portal will pick up this configuration dynamically from the deployment manager when it joins the cell. If the deployment manager cell is using standalone LDAP security, however, then it is necessary to configure the LDAP values into the portal property files before federation to enable portal to dynamically adapt to the existing standalone LDAP security settings of the cell. As with the first scenario, once the cluster has been set up then security changes to the deployment manager cell security settings can be made using the portal security tasks, and additional portal nodes may be added to the cell following the same procedures.
Parent topic
Cluster guidelines and limitations