+

Search Tips   |   Advanced Search

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.

WAS security provides an implementation that uses various local operating system-based registries and various stand-alone LDAP-based registries. However, situations can exist where the user and group data resides in other repositories or custom user registries, such as a database, and moving this information to either a local operating system registry or a stand-alone LDAP registry implementation might not be feasible. For these situations, WAS security provides a service provider interface (SPI) that we can implement to interact with the current registry. The custom registry feature supports any user registry that is not implemented by WebSphere Application Server.

The SPI is the UserRegistry interface. The UserRegistry interface is a collection of methods required for authorization purposes. These methods authenticate individual users using either a password or certificates and collect information about the user, which are called privilege attributes. This interface also includes methods that obtain user and group information so that they can be given access to resources. When implementing the methods in the interface, decide how to map the information that is manipulated by the UserRegistry interface to the information in the registry.

This interface has a set of methods to implement for the product security to interact with the registries for all security-related tasks. The local operating system and LDAP registry implementations provided also implement this interface. Custom user registries are sometimes called the pluggable user registries or custom registries for short. Your custom user registry implementation is expected to be thread-safe.

Build a custom registry is a software implementation effort. The implementation does not depend on other WebSphere Application Server resources, for example, data sources, for its operation.

Make sure that the implementation of the custom registry does not depend on any WebSphere Application Server components such as data sources, enterprise beans, and so on. Do not have this dependency because security is initialized and enabled prior to most of the other WebSphere Application Server components during startup. If the previous implementation used these components, make a change that eliminates the dependency.

The methods in the UserRegistry interface operate on the following information for users:

User security name

(dist)(zos) The user name is similar to the user name in the local operating system registries.

(iseries) The user name is similar to the user profile in the operating system registry.

This name is used to log in when prompted by a secured application. By default, the EJB getCallerPrincipal method and the getRemoteUser and getUserPrincipal servlet methods return this name. The user security name is also referred to as userSecurityName, userName, or user name.

WAS_UseDisplayName

This is a custom property of User Registries. This property defines the returning value of the getCallerPrincipal(), getUserPrincipal(), and RemoteUser() methods. The following shows acceptable values for WAS_UseDisplayName:

  • false This is default. Security Name is returned.

  • true The display name is returned. This setting requires that the custom property com.ibm.websphere.security.useLoggedSecurityName be set to true.

Unique user ID

This ID represents a unique identifier for the user, which is required by the UserRegistry interface. The unique ID is similar to the system ID (SID) in Windows systems, the Unique ID (UID) in Linux and UNIX systems, and the distinguished name (DN) in Lightweight Directory Authentication Protocol (LDAP). This ID is also referred to as uniqueUserId. The unique ID is used to make the authorization decisions for protected resources.

Display user name

(zos)(dist) This name is an optional string that describes a user. The implementation can use display names for informational purposes only; these names are not required to exist or to be unique. The user interface can use the display name to present more information about the user.

(iseries) The display name is the text description for the user profile.

Group security name

This name, which represents the security group, is also referred to as groupSecurityName, groupName, and group name.

Unique group ID

The unique ID is the identifier for a group. This name is also referred to as uniqueGroupId ID.

Display group name

The display name is an optional string that describes a group.

The topic on UserRegistry interface describes each of the methods in the interface that need implementing. An explanation of each of the methods and their usage in the sample and any changes from the Version 4 interface are provided. The Related references section provides links to all other custom user registries documentation, including a file-based registry sample. The Sample provided is very simple and is intended to familiarize you with this feature. Do not use this sample in an actual production environment.


Related concepts

  • LTPA>
  • Standalone Lightweight Directory Access Protocol registries
  • Local operating system registries

  • Develop the UserRegistry interface for using custom registries
  • UserRegistry.java files
  • FileRegistrySample.java file
  • Security custom properties
  • Stand-alone custom registry settings
  • Servlet security methods