We work in Oracle, and we “eat our dog food” to use the Oracle Single Sign On. As we work towards providing Opensocial capabilities to our internal networking site (Connect), we find that Opensocial fits very well with SSO within the corporate domain.
So, how does SSO help opensocial apps? Well, if the backend of the opensocial app is also SSO enabled, it gives hugh benefits. Every employees has a single-sign on account, and once the user logs on into Connect, he/she is authenticated across all services. Every time when an open social app requests data from its own backend, Connect acts as a proxy and forward the request along with the user credentials to the backend server, and the user is already authenticated. The SSO account basically serves as an Open ID, and there is even no need for an OAuth token exchange. I personally find this very cool and it really leverages the power of SSO. This gives users much better user experience, less hassle in signing on again and again through the OAuth service if you require security, and it saves users time and key strokes.
For the backend servers that support open social apps, SSO serves as the authentication mechanism. Such backend service no longer needs to worry about adding additional layers of security as long as they verify the request is legitimate and do come from a server it trusts.
Not only that, for open social apps, normally they need to keep a mapping between the user id of the opensocial site and their own internal ids. In addition, there is no mechanism of knowing the true identity of their friends other than knowing their user ids of the opensocial site and their names. With SSO, the picture flips around. By using the single-sign on user id, it is globally unique across all sites, and you can even use LDAP to look up more details regarding to a particular user. There is no need for a user id mapping, and you know the true identity of the user. If you have data currently exists that is related to the user, you can also choose to present these additional information to him/her as well. Google is trying to identify users through the Social Graph API over the convoluted Internet, but we get this for free and in a very simple elegant manner within the firewall.
Hi Anthony,
Good article.
In some my customer implementations we used Enterprise SSO solution like Oblix for internal apps authentication and then SAML for external (SaaS/externally hosted) apps to authenticate with the internal identity store. Is the integration pattern that you explained in this blog is similar to this pattern?
Regards,
Gopi Padakandla
Blog : http://www.enterprise20link.com/
Hi Anthony, I like this solution too! Easy to implement, high security. But I doubt if it is technically feasible that “Connect acts as a proxy and forward the request along with the user credentials to the backend server, and the user is already authenticated. ” What do you mean by “user credentials” here? is it SSO token? My knowledge on Oracle SSO is limited. I do not know whether Connect can fetch this and forward to another application. If it is possible, this solution is very cool!
Hi Gopi,
Nope. SAML is the right thing to do for authentication between external and internal domains.
For the case above, everything is still under firewall, and we are leveraging single-sign on to allow different internal service providers to communicate to each other without having the user to authenticate to each service.
Thanks.
Sincerely,
Anthony
The secure token being generated by Connect contains the user credentials for which service providers can authenticate and verify the user identity.