How to Create a Web Services Resource for IdM

Posted on May 13, 2007. Filed under: SUN IdM |

Some of the customers are (mostly they could not explain why) insist on allowing access to their resources, even to simple DB tables, through Web Services only. Due to IdM does not have any Web Services resource adapter, we, conventionally, have two options to implement such an adapter:

Developing a Custom Adapter from Scratch : Although this is the most effective way, it takes very long time and a great amount of development effort.
Using the Shell Script Adapter : At this technique, we create executable Web Services clients to communicate from command line. Then, we create shell scripts to run these executables and communicate with them through standard input/output for data exchange. In addition to extra application loading costs, this method has several potential problems such as character encoding, misinterpretation caused by special characters.

Instead, we developed a tricky solution using the Scripted JDBC Adapter which has several pros over classic approaches as follows:

Rapid development
Easy to test and maintenance
Much more fast and efficient than using the Shell Script Adapter

Implementation

Create and compile Web Services client code in Java. No matter which framework you prefer, I used Axis 1.4 at the following example. I strongly recommend you to use SoapUI toolkit for WS evaluation, testing, and code generation.
Add client classes to IdM’s web application classpath, either copying class files to WEB-INF/classes directory or copying the jar pack to WEB-INF/lib directory.
Create a fake Scripted JDBC adapter.
Create functional Javascript or BeanShell scripts to implement adapter capabilities with Java calls for WS requests and data exchange in between IdM and the WS client implementation. At the end of this article, you’ll find a sample ‘get user’ script in BeanShell.
Upload the scripts and test the resource.

Conclusion

Yes, it is a drawback to have a never used database connection, but it is still, in my opinion, a better solution then using Shell Script Adapter and more practical than developing a new adapter. If I have some free time, I am willing to develop a general purpose scripting adapter at this summer.

Appendix : A Sample getUser script

<?xml version ='1.0' encoding = 'UTF-8'?><!DOCTYPE Waveset PUBLIC 'waveset.dtd' 'waveset.dtd'><Waveset>
    <ResourceAction name='NDS-getUser-bsh'>
        <ResTypeAction restype='ScriptedJDBC' actionType='BeanShell' >
            <act>
import com.primecomponents.idm.avea.nds.UserManagementServiceLocator;
id         = actionContext.get("id");
action     = actionContext.get("action");
attrsToGet = actionContext.get("attrsToGet");
result     = actionContext.get("result");
errors     = actionContext.get("errors");
trace      = actionContext.get("trace");endpointAddress = "http://10.4.26.195:7001/IDMUserWebService/UserManagement";

var attrMap = new java.util.HashMap();
trace.info4( "NDS_getUser", "Starting the script." );

try {
    var locator = new UserManagementServiceLocator();
    locator.setUserManagementSoapPortEndpointAddress( endpointAddress );
    var userMgr = locator.getUserManagementSoapPort();
    var user = userMgr.getUser( id );

    if ( user != null )
    {
        trace.info4("NDS_getUser", "Converting the user object to an attribute map.");
        if ( user.getSurname() != null )
            attrMap.put( "userSurname", user.getSurname() );
        if ( user.getName() != null )
            attrMap.put( "userName", user.getName() );
        if ( user.getGroupId() != null )
            attrMap.put( "groupId", user.getGroupId().toString() );
        result.put( "attrMap", attrMap );
    }
    trace.info4( "NDS_getUser", "Ending operations successfully." );
} catch ( Exception ex ) {
errors.add( new com.waveset.msgcat.Message( ex.getMessage() ) );
trace.caught1( "NDS_getUser", ex );
}
trace.info4( "NDS_getUser", "Ending the script - after try/catch." );
            </act>
        </ResTypeAction>
    </ResourceAction>
</Waveset>