Before you begin
Before you perform this task, it is assumed that you already have a custom user registry implemented and working in WebSphere Application Server Version 4. The custom registry in WebSphere Application Server Version 4 is based on the CustomRegistry interface. For WebSphere Application Server Version 5, the interface is called the UserRegistry interface.The WebSphere Application Server Version 4 - based custom registry works the same as in WebSphere Application Server Version 5 with one exception.
In WebSphere Application Server Version 4, if you had display names for users the EJB method getCallerPrincipal( ) and the servlet methods getUserPrincipal( ) and getRemoteUser( ) returned the display names. This behavior has changed in WebSphere Application Server Version 5. By default, these methods now return the security name instead of the display name. However, if you need the display names to return, set the WAS_UseDisplayName property to true. See the getUserDisplayName method description or the Javadoc, for more information.
In Version 5, a case insensitive authorization can occur when using the custom registry. This authorization is new in Version 5 and in effect only on the authorization check. This function is useful in cases where your custom registry returns inconsistent (in terms of case) results for user and group unique IDs.
Note: Setting this flag does not have any effect on the user names or passwords. Only the unique IDs returned from the registry are changed to lower-case before comparing them with the information in the authorization table, which is also converted to lowercase during run time.
Before proceeding, look at the new UserRegistry interface. See Developing custom user registries for a description of each of these methods in detail and the changes from Version 4.
Why and when to perform this task
The following steps go through in detail all the changes required to move your WebSphere Application Server Version 4 custom user registry to the Version 5 custom user registry. The steps are very simple and involve minimal code changes. The sample implementation file is used as an example when describing some of the steps.Steps for this task
public class FileRegistrySample implements CustomRegistry to public class FileRegistrySample implements UserRegistry
public String mapCertificate(X509Certificate cert) to public String mapCertificate(X509Certificate[]cert)Having a certificate chain gives you the flexibility to act on the chain instead of one certificate. If you are only interested in the first certificate just take the first certificate in the chain before processing. In Version 5, the mapCertificate method is called to map the user in a certificate to a valid user in the registry, when certificates are used for authentication by the Web or the Java clients (transport layer certificates, Identity Assertion certificates). In Version 4, this was only called by Web clients since the Common Secure Interoperability Version 2 (CSIv2) protocol was not supported.
public List getUsers(String pattern) to public Result getUsers(String pattern, int limit)In your implementation, construct the Result object from the list of the users obtained from the registry (whose number is limited to the value of the limit parameter) and call the setHasMore() method on the Result object if the total number of users in the registry exceeds the limit value.
public List getUsersForGroup(String groupName) throws CustomRegistryException, EntryNotFoundException {to
public Result getUsersForGroup(String groupSecurityName, int limit) throws NotImplementedException, EntryNotFoundException, CustomRegistryException {In Version 5, this method is not called directly by the WebSphere Application Server Security component. However, other components of the WebSphere Application Server like the process choreographer use this method when staff assignments are modeled using groups. Since this already is implemented in WebSphere Application Server Version 4, it is recommended that you change the implementation similar to the getUsers method as explained in step 5.
public List getGroups(String pattern)to
public Result getGroups(String pattern, int limit)
In your implementation, construct the Result object from the list of the groups obtained from the registry (whose number is limited to the value of the limit parameter) and call the setHasMore() method on the Result object if the total number of groups in the registry exceeds the limit value.
public com.ibm.websphere.security.cred.WSCredential createCredential(String userSecurityName) throws CustomRegistryException, NotImplementedException, EntryNotFoundException { return null; }
The first and second lines of the previous code example normally appear on one line. However, it extended beyond the width of the page.
%install_root%\java\bin\javac -classpath %WAS_HOME%\lib\wssec.jar; %WAS_HOME%\lib\sas.jar FileRegistrySample.javaType the previous lines as one continuous line.
To
build the Version 4 custom registry in Version 5 and Version 5.0.1, only the wssec.jar file
is required.
To build the Version 4 custom registry
in Version 5.0.2, only the sas.jar file is required.
Results
Migrates a Version 4 custom registry to the Version 5 custom registry.Example
What to do next
If you are enabling security, make sure you complete the remaining steps. Once completed, save the configuration and restart all the servers. Try accessing some J2EE resources to verify that the custom registry migration was successful.