WAS v8.5 > Secure applications > Authenticate users

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 user repository is configured as the active user registry. Decide if you want a different user registry.

Before configuring the user registry or repository, decide which user registry or repository to use. We can configure one Active default registry for the Cell.

WAS provides implementations that support multiple types of registries and repositories including...

• local operating system registry
• stand-alone LDAP registry
• stand-alone custom registry
• federated repositories

With WAS, 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.

With WAS, a user registry or repository is used for:

• Authenticating a user using basic authentication, identity assertion, or client certificates
• Retrieving information about users and groups to perform security-related administrative functions, such as mapping users and groups to security roles

WAS provides plug-ins to custom registries not available through the security configuration panels of the WAS.

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 the applications.

WAS supports the following types of user registries:

• Federated repository
• Local operating system
• Standalone LDAP registry
• Stand-alone custom registry

Configuring a transparent LDAP server under the local operating system registry and having authentication of users take place through that local operating system using LDAP is unsupported.

The UserRegistry interface is used to implement both the custom registry and the federated repository options for the user account repository. The interface is very helpful in situations where the current user and group information exists in some other formats, for example, a database, and cannot move to local operating system or LDAP registries. In such a case, we can implement the UserRegistry interface so that WAS can use the existing registry for all the security-related operations. The process of implementing a custom registry is a software implementation effort, and it is expected the implementation does not depend on WAS resource management for its operation. For example, we cannot use an Application Server data source configuration; generally you must invoke database connections and dictate their behavior directly in your code.

WAS has implemented a user registry proxy using the UserRegistry interface. However, the return values are little 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. Use an SPI for this parsing function.

// Retrieve the default InitialContext 
javax.naming.InitialContext ctx = new javax.naming.InitialContext();

// Retrieve the local UserRegistry object.
com.ibm.websphere.security.UserRegistry reg = (com.ibm.websphere.security.UserRegistry) ctx.lookup("UserRegistry");

// Retrieve the uniqueID based on the userName 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);

// Retrieve the security name from the user registry based on the uniqueID
String securityName = reg.getUserSecurityName(uid);

After the applications are assigned users and groups, to change the user registries...

1. Delete all the users and groups, including any RunAs role, from the applications
2. Reassign them after changing the registry through the dmgr console or using wsadmin.sh.

The following wsadmin command removes all of the users and groups from any application:

$AdminApp deleteUserAndGroupEntries yourAppName

Back up the application before performing this task.

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 you 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.

See updateAccess IDs in the Commands for the AdminApp object.

WAS supports a variety of user registries and repositories on different operating systems. During the user authentication process, you might use non-alphanumeric characters in the 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.

For example, 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.

For example, the following characters are not supported in a user name value:

• ˋ
• :
• "
• /
• A space character

Complete one of the following steps to configure the user registry:

• Configure local operating system registries
  
• Configure LDAP user registries
  
• Configure stand-alone custom registries.
• Manage the realm in a federated repository configuration
  

1. If you are enabling security, verify you complete the remaining steps. 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 WASs.

2. For any changes in user registry panels to be effective, you must 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, verify 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 verify the process can start later.

   If the server or servers start without any problems, the setup is correct.

Subtopics

• Stand-alone custom registries
  A stand-alone custom registry is a customer-implemented registry that implements the UserRegistry Java interface, as provided by the product. A custom-implemented registry can support virtually any type of an account repository from a relational database, flat file, and so on. The custom user registry provides considerable flexibility in adapting product security to various environments where some form of a registry or repository other than federated repositories, stand-alone LDAP registry or local operating system registry already exists in the operational environment.
• Configure local operating system registries
  Use these steps to configure local operating system registries.
• Configure LDAP user registries
  To access a user registry using the LDAP, you must know a valid user name (ID) and password, the server host and port of the registry server, the base distinguished name (DN) and, if necessary, the bind DN and the bind password. Choose any valid user in the user registry that is searchable. We can use any user ID that has the administrative role to log in.
• Configure stand-alone custom registries
  Use the following information to configure stand-alone custom registries through the dmgr console.
• Manage the realm in a federated repository configuration
  Follow this topic to manage the realm in a federated repository configuration.
• Local operating system registries
  With the registry implementation for the local operating system, the authentication mechanism can use the user accounts database of the local operating system.
• Standalone LDAP registries
  A Standalone LDAP registry performs authentication using an LDAP binding.
• Federated repositories
  Federated repositories enable you to use multiple repositories with WAS. These repositories, which can be file-based repositories, LDAP repositories, or a sub-tree of an LDAP repository, are defined and theoretically combined under a single realm. All of the user repositories configured under the federated repository functionality are invisible to WAS.
• Configure local operating system registries
  Use these steps to configure local operating system registries.
• Configure LDAP user registries
  To access a user registry using the LDAP, you must know a valid user name (ID) and password, the server host and port of the registry server, the base distinguished name (DN) and, if necessary, the bind DN and the bind password. Choose any valid user in the user registry that is searchable. We can use any user ID that has the administrative role to log in.
• Configure stand-alone custom registries
  Use the following information to configure stand-alone custom registries through the dmgr console.
• Manage the realm in a federated repository configuration
  Follow this topic to manage the realm in a federated repository configuration.
• Standalone LDAP registries
  A Standalone LDAP registry performs authentication using an LDAP binding.

Related

Authenticate users
Enable security

Reference:

Commands for the AdminApp object using wsadmin.sh

+

Search Tips   |   Advanced Search