SDO and SaaS

I have always been impressed by the Service Data Objects specification and the utility value it has when generic services interact with each other. By the very fact that an object can be percieved as a self-describing message makes service orchestration/choregraphy much simpler. The specifications are implemented by ASF with Apache Tuscany(C++ and Java) as well as IBM/Eclipse(Java) - Implemented along with the Eclipse Modeling Framework. Assuming a scenario where application can send messages in any format they want but as SDO objects which self describe themselves, other applications can sucessfully retrieve and interpret the data in a highly decoupled manner. The specification enables interoperability between applications in terms of data models existing between them.

What would be more interesting is to see if any of the SaaS application platform providers actually use the SDO specification for both their integration requirements as well as Data Model Extensions. Amazingly SDO is the perfect candidate to provide extensions to data models since they are self describing and therefore metadata driven.

Technorati Tags     SDP,SaaS,SDO

User Authentication in SaaS applications

I have been working on a SaaS delivery enablement platform called Agora. I have had some insights after talking to multiple customers and most of them have always hinged on one crucial function, namely, User Authentication. It looks like this is a very common problem.

I believe Salesforce has a feature where in, the customer can implement a webservice interface given by salesforce, provide the details and Salesforce can then call the webservice for authentication. This was primarily done to abstract out the implementation/integration problems of multiple types of authentication.

The other option ofcourse is standards like OpenID. Allow users to have logins based on OpenID Providers and then use the same for the SaaS application too. But corporate customers would'nt want their user accounts to be personal email accounts. But this definitely is an option if the application is end consumer oriented.

I dont think that Federation as in replicating the user details or having a secure VPN between customer and SaaS App Provider is the right way to go, the former completely unnecessary and the later very costly.

I think the Salesforce approach does make sense. For e.g. a corporate customer can allow its users to login into the SaaS application using their corporate credentials for the first time. This action then creates a mapping between the SaaS application and the corporate user account. Subsequently any further requests for authentication can then be done seamlessly. The specifics of the implementation coule be anything ranging from SAML assertions to simple custom API's. The crucial question though is the communciation medium between the SaaS app provider and the corporate. I think either a standard auth gateway at the customer premise if already available or a standard webservice implementation like what Salesforce does.

Technorati Tags     SDP,Authentication,SaaS