Configuring a Custom User Registry with Liberty 

Overview

The custom user registry from Traditional WebSphere can be easily converted to work in Liberty for a proof-of-concept project.  Then it can be further updated to a Liberty feature that works just like the built-in Liberty features. 

In Liberty, a custom user registry can be configured in two ways:
(1) Configure Custom User Registry as a Liberty feature. 
(2) Configure Custom User Registry using bells-1.0 feature  (Basic Extensions using Liberty Libraries 1.0) 

The first approach "Liberty feature" requires the user to create or update the custom user registry as OSGi feature.  This user feature allows the user to pass the configuration properties for the user registry using the server.xml just like other Liberty features.  

The second approach using bells-1.0 feature offers an alternative way to implementing the OSGi feature.  When a custom user registry jar file is already available, the bell feature allows it to work in Liberty with minimal updates in the jar itself.   This approach helps to get the custom user registry deployed quickly and to speed up proof-of-concept-type projects. This is similar to how you might have implemented a Custom User Registry in traditional WebSphere Application Server. 

Configuring Custom User Registry as a Liberty feature

• Users can create a Custom User Registry as a Liberty feature by following the steps in Developing a custom user registry in Liberty.


• A Liberty feature consists of a feature manifest file and OSGi bundles. 


• The user feature can be configured in server.xml as a feature such as 

<featureManager>
        <feature>usr:myUserRegistry-1.0</feature>
</featureManager>

Configure Custom User Registry using bells-1.0 feature  

To update Traditional WebSphere's Custom User Registry to use with Liberty: 

• Create a file named "META-INF/services/com.ibm.websphere.security.UserRegistry"  


• In the file, add the user registry class name.  For example "com.ibm.ws.samples.cur.FileRegistrySample" so Liberty knows the class name. 


• Add the above file to the jar 

To configure the updated jar with Liberty

• Add "bells-1.0" feature in the featureManager section. 


• Add "Library" to tell Liberty the Custom User Registry jar location.  Place the jar in the specified location in the "Library"


• Add "bell" configuration to point to the library reference above. 


• (Optional) For the test purpose, add an application configuration with user/password information. 


• All configuration options for bells-1.0 can be found here. 

<!-- Custom User Registry configuration using bells-1.0 feature --> 

<featureManager>
        <feature>bells-1.0</feature>
</featureManager>

<library id="bellsCurLib" name="bellsCurLib">
<file name="${server.config.dir}/resources/sharedLib/bellsCur.jar"></file>
</library>

<bell libraryRef="bellsCurLib"></bell>

<application type="war" id="basicauth" location="${server.config.dir}/apps/basicauth.war">
<application-bnd>
<security-role name="Manager">
<user name="user1"/>
<group name="group3"/>
</security-role>
</application-bnd>
</application>

This git repository includes a simple maven project that creates a custom user registry deployable to Liberty. The user registry used here is from the Traditional WebSphere's sample custom user registry used since WebSphere v6.1.   The git repository includes a Dockerfile and a basicauth sample application to see how the user registry works with the latest Liberty containers.  The developers going with this approach using bells-1.0 feature can use the environment variables to pass information from server.xml to the custom user registry.  

Thanks to the awesome Liberty users Bjørn-Willy Arntzen , Paul Dubs and Guillermo González de Agüero for their contribution to this topic here.  Also to our doc team (David Mueller and Richard Walls)