+

Search Tips   |   Advanced Search

Standalone Lightweight Directory Access Protocol registries

A Standalone Lightweight Directory Access Protocol (LDAP) registry performs authentication using an LDAP binding.

WAS security provides and supports the implementation of most major LDAP directory servers, which can act as the repository for user and group information. These LDAP servers are called by the product processes for authenticating a user and other security-related tasks. For example, the servers are used to retrieve user or group information. This support is provided by using different user and group filters to obtain the user and group information. These filters have default values we can modify to fit the needs. The custom LDAP feature enables you to use any other LDAP server, which is not in the product-supported list of LDAP servers, for its user registry using the appropriate filters.

The initial profile creation configures WebSphere Application Server to use a federated repositories security registry option with the file-based registry. This security registry configuration can be changed to use other options, including the stand-alone LDAP registry. Instead of changing from the federated repositories option to the stand-alone LDAP registry option under the User account repository configuration, consider employing the federated repositories option, which provides for LDAP configuration. Federated repositories provide a wide range of capabilities, including the ability to have one or multiple user registries. It supports federating one or more LDAPs in addition to file-based and custom registries. It also has improved failover capabilities, and a robust set of member (user and group) management capabilities. Federated repositories is required when we are using the new member management capabilities in WebSphere Portal 6.1 and higher, and Process Server 6.1 and higher. The use of federated repositories is required for following LDAP referrals, which is a common requirement in some LDAP server environments (such as Microsoft Active Directory).

IBM recommends that you migrate from stand-alone LDAP registries to federated repositories. If we move to WebSphere Portal 6.1 and higher, and or WebSphere Process Server 6.1 and higher, you should migrate to federated repositories prior to these upgrades. For more information about federated repositories and its capabilities, read the Federated repositories topic. For more information about how to migrate to federated repositories, read the Migrating a stand-alone LDAP repository to a federated repositories LDAP repository configuration topic.

To use LDAP as the user registry, we need to know an administrative user name defined in the registry, the server host and port, the base distinguished name (DN) and, if necessary, the bind DN and the bind password. We can choose any valid user in the registry that is searchable and have administrative privileges. In some LDAP servers, the administrative users are not searchable and cannot be used, for example, cn=root in SecureWay. This user is referred to as WAS security server ID, server ID, or server user ID in the documentation. Being a server ID means a user has special privileges when calling some protected internal methods. Normally, this ID and password are used to log into the console after security is turned on. We can use other users to log in if those users are part of the administrative roles.

When security is enabled in the product, the primary administrative user name and password are authenticated with the registry during the product startup. If authentication fails, the server does not start. It is important to choose an ID and password that do not expire or change often. If the product server user ID or password need to change in the registry, verify the changes are performed when all the product servers are up and running.

When the changes are done in the registry, use the steps described in Configure Lightweight Directory Access Protocol user registries. Change the ID, password, and other configuration information, save, stop, and restart all the servers so that the new ID or password is used by the product. If any problems occur starting the product when security is enabled, disable security before the server can start up. To avoid these problems, make sure that any changes in this panel are validated in the Global security panel. When the server is up, we can change the ID, password, and other configuration information and then enable security.

We can use the custom LDAP feature to support any LDAP server by setting up the correct configuration. However, support is not extended to these custom LDAP servers because many configuration possibilities exist.

The users and groups and security role mapping information is used by the configured authorization engine to perform access control decisions.

(zos) If we are configuring an LDAP registry as the active registry, we can configure one of the following authorization mechanisms:

(zos) SAF authorization, which is the use of SAF EJBROLE profiles to assign SAF users and groups to roles, can be used as an authorization mechanism for all user registries. If SAF authorization is selected on the console:


Subtopics


Related concepts

  • Federated repositories


    Related tasks

  • Select a registry or repository
  • Use specific directory servers as the LDAP server
  • Configure Lightweight Directory Access Protocol user registries
  • Migrate a stand-alone LDAP repository to a federated repositories LDAP repository configuration

  • Standalone LDAP registry settings
  • Security: Resources for learning