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.
Before configuring the user registry or repository, decide which user registry or repository to use. You can configure one Active default registry for the Cell.
WebSphere Application Server provides implementations that support multiple types of registries and repositories including the local operating system registry, a standalone Lightweight Directory Access Protocol (LDAP) registry, a standalone custom registry, and federated repositories.
With WebSphere Application Server, a user registry
or a repository, such as a federated repository, authenticates a user
and retrieves information about users and groups to perform security-related
functions including authentication and authorization.
WebSphere Application Server is designed
with the capability to support multiple operating systems or operating
environment-based user registries, such as the z/OS® SAF
registry, and most of the major Lightweight Directory Access Protocol
(LDAP)-based registries. You can use the custom LDAP feature to support
any LDAP server by setting up the correct configuration information,
such as user and group filters. However, support is not extended to
these custom LDAP servers because there are many possibilities that
cannot be tested.
Configuring the correct registry
or repository is a prerequisite to assigning users and groups to roles
for applications. By default, when a user registry or repository is
not configured, the local operating system SAF-based user registry
is used. If your choice of user registry or repository is not the
local operating system, you must first configure the user registry
or repository. Configuring the user registry or repository is normally
done as part of enabling administrative security, restarting the servers,
and then assigning users and groups to roles for all of your applications.
In addition to local operating system, LDAP, and Federated repository registries, WebSphere Application Server also provides a plug-in to support any registry by using the custom registry feature. The custom registry feature enables you to configure any user registry that is not made available through the security configuration panels of the WebSphere Application Server.
Configuring the correct registry or repository
is a prerequisite to assigning users and groups to roles for applications.
When a user registry or repository is not configured, the local operating
system registry is used by default. If your choice of user registry
is not the local operating system registry, you need to first configure
the registry or repository, which is normally done as part of enabling
security, restart the servers, and then assign users and groups to
roles for all your applications.
// 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 that is 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);You can use a Service Provider Interface (SPI) for this parsing function.
$AdminApp deleteUserAndGroupEntries yourAppNamewhere 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:
By default, an application does not contain access IDs in the bindings file. These IDs are generated when the applications start. However, if you migrated an existing application from an earlier release, or if you used the wsadmin script to add access IDs for the applications to improve performance, you 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.
For a comprehensive list of the non-alphanumeric characters that are not supported, see the IBM AIX operating system documentation.
Complete one of the following steps to configure your user registry:
If the server or servers start without any problems, the setup is correct.
In this information ...Subtopics
Related reference
| IBM Redbooks, demos, education, and more(Index) |