With the local operating system, or Local OS, user registry implementation, the WebSphere authentication mechanism can use the user accounts database of the local operating system.
WebSphere Application Server for z/OS uses the System Authorization Facility (SAF) interfaces. SAF interfaces are defined by MVS to enable applications to use system authorization services or user registries to control access to resources such as data sets and MVS commands. SAF either processes security authorization requests directly or works with RACF, or other security products, to process the requests.
A Local OS user registry is not a centralized user registry like LDAP, but it is a centralized registry within a sysplex.
Do not use a Local OS user registry in a WebSphere Application Server environment, where application servers are dispersed across more than one machine because each machine has its own user registry.
Because these IDs are typically unique identifiers, they vary from machine to machine, even if the exact users and passwords exist on each machine.
Web client certificate authentication is supported when using the local operating system user registry. Digital certificates can be mapped to MVS identities by both Web and Java clients when you select Local OS. A certificate name filter can be used to simplify the mapping. If you are using RACF as the security server, the RACDCERT MAP command creates a resource profile that maps multiple user identities to a digital certificate in order to simplify administration of certificates, conserve storage space in the RACF database, maintain accountability, or maintain access control granularity.
Using both the domain registry and the local registry
When the machine hosting the WebSphere Application Server process is a member of a domain, both the local and the domain registries are used by default. The following section describes more on this topic and recommends some best practices to avoid undesirable consequences.
In general, if the local and the domain registries do not contain common users or groups, it is simpler to administer and it eliminates undesirable side effects. So if possible, give users and groups access to unique security roles (including the server ID and administrative roles). In this situation, select the users and groups from either the local registry or the domain registry to map to the roles.
In cases where the same users or groups exist in both the local registry and the domain registry, it is recommended that at least the server ID and the users and groups that are mapped to the administrative roles be unique in the registries (exist only on the domain).
If a common set of users exists, set a different password to make sure that the appropriate user is authenticated.
When a machine is part of a domain, the domain user registry takes precedence over the local user registry. For example, when a user logs into the system, the domain registry tries to authenticate the user first. If the authentication fails the local registry is used. When a user or a group is mapped to a role, the user and group information is first obtained from the domain registry. In case of failure, the local registry is tried. However, when a fully qualified user or a group name (one that has a domain or host name attached to it) is mapped to a role, then only that registry is used to get the information. Use the administrative console or scripts to get the fully qualified user and group names and is the recommended way to map users and groups to roles.
Note: A user Bob on one machine (the local registry, for example) is not the same as the user Bob on another machine (say the domain registry) because the uniqueID of Bob (the security identifier [SID], in this case) is different in different registries.
The machine MyMachine is part of the domain MyDomain. MyMachine contains the following users and groups:
Here are some scenarios that assume the previous set of users and groups.
Authorizing with the domain user registry first can cause problems if a user exists in both the domain and local user registries with the same password. Role-based authorization can fail in this situation because the user is first authenticated within the domain user registry. This authentication produces a unique domain security ID that is used in WebSphere Application Server during the authorization check. However, the local user registry is used for role assignment. The domain security ID does not match the unique security ID associated with the role. To avoid this problem, map security roles to domain users instead of local users.
Using either the local or the domain registry. If you want to access users and groups from either the local registry or the domain registry, instead of both, set the property com.ibm.websphere.registry.UseRegistry. This property can be set to either local or domain. When this property is set to local (case insensitive) only the local registry is used. When this property is set to domain (case insensitive) only the domain registry is used. Set this property by clicking Custom Properties in the Security > User Registries > Local OS panel in the administrative console or by using scripts. When the property is set, the privilege requirement for the user who is running the product process does not change. For example, if this property is set to local, the user running the process requires the same privilege, as if the property was not set.
Note:
When the com.ibm.websphere.registry.UseRegistry property is set, the privilege requirement for the user running the WebSphere Application Server process does not change, which means if this property is set to local the user running the process requires the same privilege as if the property was not set.
Remote registries
By default, the registry is local to all of the product processes. The performance is higher, (no need for remote calls) and the registry also increases availability. Any process failing does not effect other processes. When using LocalOS as the registry, every product process must run with privilege access. If this process is not practical in some situations, you can use a remote registry from the node (or in very rare situations from the cell). Using a remote registry affects performance and creates a single point of failure. Use remote registries only in rare situations.
The node and the cell processes are meant for manipulating configuration information and using them to host the registry for all the application servers creates traffic and can cause problems. Using a node agent (instead of the cell) to host the remote registry is preferable because since the cell process is not designed to be highly available. Also, using a node to host the remote registry indicates that only the application servers in that node are using it. Because the Node Agent does not contain any application code, giving it the access required, privilege is not a concern.
You can set up a remote registry by setting the WAS_UseRemoteRegistry property in the Global Security panel using the Custom Properties link at the bottom of the administrative console panel. Use either the Cell or the Node (case insensitive) value. If the value is Cell, the cell registry is used by all of the product processes including the node agent and all of the application servers. If the cell process is down for any reason, restart all of the processes after the cell is restarted. If the node agent registry needs is used for the remote registry, set the value, WAS_UseRemoteRegistry, to node. In this case, all the application server processes use the node agent registry. In this case, if the node agent fails and does not start automatically, then depending on that node agent, you might need to restart all the application servers, after the node agent is started.