Security options

The security model in IBM® WebSphere® Application Server and IBM WebSphere Portal affects the planning and implementation of security in a cluster. Security is enabled by default for the WebSphere Application Server 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 WebSphere Portal is replaced with the security settings of the deployment manager cell when it joins that cell. If you remove the node from the deployment manager cell, the original security settings are reinstated.

Default security settings

The default security that is enabled on the deployment manager profiles and WebSphere Portal profiles installation is the Virtual Member Manager (VMM) federated security with a single file-based repository configured. If you plan to add the standalone node into a deployment manager cell, there is no need to modify this default security setting on a WebSphere Portal node when the purpose of that node is to join a deployment manager cell and run as part of a cluster. During federation, the standalone environment security settings are replaced with the deployment manager security settings. The original standalone environment security settings are preserved and will revert back to the original settings if you remove the node from the cluster.

Note: If administrative security is disabled during installation of the deployment manager or is disabled after the deployment manager is installed, it must be enabled prior to executing the security configuration tasks on the WebSphere Portal cluster members.

WebSphere Portal also supports the option of installing into a managed profile of an existing cell. In this case, WebSphere Portal will inherit the security settings of the existing cell. Certain security options, such as standalone LDAP or custom user registry, will collect information during the installation to allow WebSphere Portal to adapt to the existing security settings.

Security options for a cluster

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, and the default file-based repository can be used. Additionally there is an option to use standalone LDAP security instead of the VMM federated security approach.

WebSphere Portal provides a number of security tasks, which can be used to modify the WebSphere Application Server security settings and make the required updates to the WebSphere Portal configuration in a single step. As soon as a WebSphere Portal node is federated into a deployment manager cell, all executed WebSphere Portal security tasks will update the security configuration on the deployment manager cell. Run security tasks after federating the WebSphere Portal node because the Deployment Manager cell does not contain the configuration resources required to run the security tasks.

The tasks under “Setting up a clustered production environment” recommend configuring security before configuring your additional nodes. If you configure your security after configuring your additional nodes or if you need to update your security configuration after you created your clustered environment, you will need to run an additional task to update the security settings on the secondary nodes; see "Configuring security after cluster creation" for information.

Note: It is not recommended to use the file-based repository in a production environment. The reason is that updates are only possible through the WebSphere Integrated Solutions Console, not through portal user management. These updates are sent to each node in the cell using deployment manager file synchronization. This can be time consuming for large volumes of users and groups. Also, synchronization does not occur at the same time for all nodes in a cell, so there are time windows when the nodes in the cell have differing security definitions. Another reason the file-based repository is not recommended in a production environment is that the Users and Groups portlet is not available. You must remove the file-based repository and replace it with a stand-alone LDAP user registry or a federated LDAP user registry to have access to the Users and Groups portlet.