Protecting OAM (IdentityXML) with OSB

A great use case for this blog - "How to add OSB in front of OAM". This question came from a customer, and touches on a number of interesting issues

This link has all of the information about the WSDL for Identity.xml.


This link describes how to use WSDL in OSB


To clarify, you can load the WSDL as a file into OSB and use those local WSDLs to work with the services of IdentityXML. The fact that OAM does not expose the WSDL in the ?WSDL form is not an issue. OSB is happy to work with a file.

So, basically:

1 - Create a proxy service for a WSDL ( this will expose ?WSDL to clients)
2 - Create a business service for an Identity XML using the same WSDL
3 - Create a pipeline that maps that routes the requests (very simple mapping...not much work)

The most interesting part here is how to propagate the credentials through OSB.

IdentityXML uses a proprietary format - It doesn't use WS-Security. IdentityXML looks for all of the information in the body, but I would argue a "better" implementation and a better use of OSB would be to add more standard WS-Security tokens to the exposed WSDL.

For example, you could replace the username/password elements with WS-Security UsernameTokenProfile and the ObSSOToken could be mapped to a custom WS-Security BinaryToken (common) practice.

To this, you wouldn't process the WS-Security Envelope in OSB, but rather do some transformations from the exposed WSDL and WS-Security messages to their appropriate localtion inside of the actual IdentityXML endpoint running in OAM.