Select a registry or repository
Information about users and groups reside in a user registry. In WebSphere Application Server, a user registry authenticates a user and retrieves information about users and groups to perform security-related functions, including authentication and authorization. During profile creation, either during installation or post-installation, administrative security is enabled by default. The file-based federated local operating system registry is configured as the active user registry default. We can configure only one active default registry for a cell.
WAS supports the following types of user registries:
UserRegistry interface
The UserRegistry interface is used to implement both the custom registry and the federated repository options for the user account repository. The interface is helpful in situations where the user and group information exists in other formats, for example, a database, and cannot be moved to the local operating system or LDAP registries. The interface allows WAS to use the existing registry for all the security-related operations. The process of implementing a custom registry of this kind is a software implementation effort, and it is expected that the implementation does not depend on WAS resource management for its operation. For example, we cannot use an application server data source configuration; generally we must invoke database connections and dictate their behavior directly in your code.
WAS has implemented a user registry proxy that can be used with the the UserRegistry interface. However, the return values are slightly different from the interface. For example, getUniqueUserId returns the uniqueID with the realm name wrapped. We cannot use the return value to pass to getUserSecurityName, as shown in the following example:
// Retrieves the default InitialContext for this server.
javax.naming.InitialContext ctx = new javax.naming.InitialContext();
// Retrieves the local UserRegistry object.
com.ibm.websphere.security.UserRegistry reg = (com.ibm.websphere.security.UserRegistry) ctx.lookup("UserRegistry");
// Retrieves the registry uniqueID based on the userName specified in the NameCallback.
String uniqueid = reg.getUniqueUserId(userName);
// Strip the realm name and get real uniqueID
String uid = com.ibm.wsspi.security.token.WSSecurityPropagationHelper.getUserFromUniqueID (uniqueID);
// Retrieves the security name from the user registry based on the uniqueID.
String securityName = reg.getUserSecurityName(uid);We can use a Service Provider Interface (SPI) for this parsing function.
After the applications are assigned users and groups and we need to change the user registries, delete all the users and groups, including any RunAs role, from the applications, and reassign them after changing the registry through the administrative console or using wsadmin.sh. The following wsadmin command, which uses Jacl, removes all of the users and groups from any application:
$AdminApp deleteUserAndGroupEntries yourAppName
...where yourAppName is the name of the application. Backing up the old application is advised before performing this operation. However, if both of the following conditions are true, you might be able to switch the registries without having to delete the users and groups information:
- All of the user and group names, including the password for the RunAs role users, in all of the applications match in both user registries.
- The application bindings file does not contain the access IDs which are unique for each user registry even for the same user or group name.
By default, an application does not contain access IDs in the bindings file. These IDs are generated when the applications start. However, if we migrated an existing application from an earlier release, or if we used the wsadmin script to add access IDs for the applications to improve performance, we have to remove the existing user and group information and add the information after configuring the new user registry.
For more information on updating access IDs, see updateAccess IDs in the Commands for the AdminApp object article.
Supported characters
WAS supports a variety of user registries and repositories on different operating systems. During the user authentication process, we might use non-alphanumeric characters in your user name or password. Restrictions on the use of these non-alphanumeric characters depends on both the underlying operating system and the user registry type. For more information on which non-alphanumeric characters are not supported, see your operating system and user registry or repository documentation.
The following characters are not supported in a user name value:
- ˋ
- #
- =
- \
- :
- "
- ,
- /
- ?
- '
- A space character
For a comprehensive list of the non-alphanumeric characters that are not supported, see the IBM AIX operating system documentation.
(HPUX) For example, the following characters are not supported in a user name value:
- ˋ
- :
- "
- /
- A space character
Complete one of the following steps to configure your user registry:
Tasks
- Configure local operating system registries
- Configure LDAP user registries
- Configure stand-alone custom registries.
- Manage the realm in a federated repository configuration
What to do next
- If we are enabling security verify the user account repository on the Global security panel is set to the appropriate registry or repository. As the final step, validate the user ID and the password by clicking Apply on the Global security panel. Save, stop and start all WAS.
- For any changes in user registry panels to be effective, validate the changes by clicking Apply on the Global security panel. After validation, save the configuration and stop and start all WASs, including the cells, nodes and all of the application servers. To avoid inconsistencies between the WAS processes, make sure any changes to the registry or repository are done when all of the processes are running. If any of the processes are down, force synchronization to make sure that the process can start later. If the server or servers start without any problems, the setup is correct.
Related:
Standalone LDAP registries
Authenticating users Enable security Commands for the AdminApp object