With the registry implementation for the local operating system, the WebSphere® Application Server authentication mechanism can use the user accounts database of the local operating system.
If you want to use the local operating system
registry to represent the principals who access your WebSphere Application
Server resources, you do not have to complete any special user registry
setup steps. The local operating system registry is used for authentication
and authorization of users who access WebSphere Application
Server resources, but not for WebSphere Application Server
users who access operating system resources. WebSphere Application
Server does not run under the operating system user profile of Application
Server users. Instead, WebSphere Application Server
runs under the operating system profile that is configured by the
Application Server administrator.
If you want to authorize a user for any WebSphere Application Server resource,
a user profile for that user must exist in the operating system. Use
the Create User Profile (CRTUSRPRF) command to create new user IDs
that can be used by WebSphere Application Server
Lightweight
Directory Access Protocol (LDAP) is a centralized registry. Most local
operating system registries are not centralized registries.
WebSphere Application Server provides implementations
for the Windows local accounts registry
and domain registry, as well as implementations for the Linux,
Solaris, and AIX® user accounts registries. Windows Active
Directory is supported through the LDAP user registry implementation
discussed later.
Do
not use a local operating system 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.
The Windows domain
registry and Network Information Services (NIS) are exceptions. Both
the Windows domain registry and Network Information
Services (NIS) are centralized registries. The Windows domain
registry is supported by WebSphere Application Server;
however, NIS is not supported.
As
mentioned previously, the access IDs taken from the user registry
are used during authorization checks. 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 not currently supported when
using the local operating system user registry. However, Java client certificate authentication does
function with a local operating user registry. Java client
certificate authentication maps the first attribute of the certificate
domain name to the user ID in the user registry.
CWSCJ0337E: The mapCertificate method is not supported
The error is intended for web client certificates; however, it also displays for Java client certificates. Ignore this error for Java client certificates. A local operating system
registry is a centralized registry within a sysplex.
WebSphere Application
Server uses the System Authorization Facility (SAF) interfaces. SAF
interfaces are defined by MVS™ to enable applications to use
system authorization services or registries to control access to resources
such as data sets and MVS commands. SAF allows security
authorization requests to be processed directly through the Resource
Access Control Facility (RACF®) or a third party z/OS security
provider. You must provide a mapping from a user registry identity
to a SAF user ID unless you select local operating system as the user
registry. For more information, see Custom System Authorization Facility mapping modules.
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 to simplify administration
of certificates, conserve storage space in the RACF database,
maintain accountability, or maintain access control granularity.
The user that is running the WebSphere Application Server process requires enough operating system privilege to call the Windows systems application programming interface (API) for authenticating and obtaining user and group information from the Windows operating system. This user logs into the machine, or if running as a service, is the Log On As user. Depending on the machine and whether the machine is a stand-alone machine or a machine that is part of a domain or is the domain controller, the access requirements vary.
The user is a domain user and not a local user, which implies that when a machine is part of a domain, only a domain user can start the server.
When WebSphere Application Server is started, the security run-time initialization process dynamically attempts to determine if the local machine is a member of a Windows domain. If the machine is part of a domain then by default both the local registry users or groups and the domain registry users or groups can be used for authentication and authorization purposes with the domain registry taking precedence. The list of users and groups that is presented during the security role mapping includes users and groups from both the local user registry and the domain user registry. The users and groups can be distinguished by the associated host names.
WebSphere Application Server does not support trusted domains.
If the machine is not a member of a Windows system domain, the user registry local to that machine is used.
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 that is associated with the role. To avoid this problem, map security roles to domain users instead of local users.
Only a centralized repository can be used if more than one node is involved. This usage implies that only the domain user registry can be used because the user and group unique IDs (SIDs) differ on various nodes, as previously mentioned.
If you want to access users and groups from either the local or the domain user registry, instead of both, set the com.ibm.websphere.registry.UseRegistry property. This property can be set to either local or domain. When this property is set to local (case insensitive) only the local user registry is used. When this property is set to domain, (case insensitive) only the domain user registry is used.
For WebSphere Application Server local operating system registry to work on the Linux and Solaris platforms, a shadow password file must exist. The shadow password file is named shadow and is located in the /etc directory. If the shadow password file does not exist, an error occurs after enabling administrative security and configuring the registry as local operating system.
To create the shadow file, run the pwconv command (with no parameters). This command creates an /etc/shadow file from the /etc/passwd file. After creating the shadow file, you can enable local operating system security successfully.