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