WAS v8.5 > Secure applications > Authenticate users

Select a registry or repository

User registries contain information on users related to authentication and authorization. Administrative security is enabled by default, using the file-based federated user repository. We can configure one active default registry for the Cell.

Types of registries...

• Local operating system registry
• Stand-alone LDAP registry
• Stand-alone custom registry
• federated repositories

The local operating system registry is used by default.

User registries are used for

• Authenticating a user using basic authentication, identity assertion, or client certificates
• Map users and groups to security roles

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.

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.

On AIX, the following characters are not supported in a user name value: ˋ # = \ : " / ? ' A space character. On HP-UX, the following characters are not supported in a user name value: ˋ : " / A space character

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.

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 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);

Subtopics

1. Stand-alone custom registries
2. Configure local operating system registries
3. Configure LDAP user registries
4. Configure stand-alone custom registries
5. Manage the realm in a federated repository configuration
6. Local operating system registries
7. Standalone LDAP registries
8. Federated repositories

Related
Authenticate users
Enable security
Commands for the AdminApp object using wsadmin.sh

+

Search Tips   |   Advanced Search