Using OX for Social Login

1. Using OX for Social Login So you have a website or mobile application, and you want to support social login? Consider using the following imaginary website for Acme Incorporated. Instead of your local username and password, you decide to use the “Login with Yahoo” button. OX enables a domain to define custom authentication scripts. When you click the “Login with Yahoo” button, the login page uses Acme’s OpenID Connect API (served by OX), and includes the GET parameters “auth_mode=yahoo”. This enable OX to select the correct authentication script for Yahoo. This script could use the Yahoo API to validate your current session or to re-direct you for authentication. Once you are authenticated, you can see a portal with several panels. Each panel is served by a different back-end web server which needs to know your identity in order to display the right content. Its a bad idea to instruct each backend web application to use the social API directly. If you did that, each application would have to implement business logic for every social login API. If Yahoo or Google updates their API, every application would have to update their code. Plus, introducing new authentication mechanisms would be difficult: you’d have to get every app to do so.

2. Using the social login API directly could make it hard for the backend web applications to get all the needed information about you. For example, the billing application might need your Acme account number, which Yahoo does not know. But how does Acme know which person corresponds to which social account? This is where you need to consider enrollment. Frequently, a person with a local account specifies that they want to associate a social account. Or if you first authenticate with a social login, you may need to provide additional information–for example address, phone number, account number–to enable the organization to setup a local account. In many ways using a social login API is no different from the considerations of using any external authentication provider, for example Duo or OneID. A custom authentication script could even support uber-authentication API’s, like Janrain or Gigya. These services would enable you to create one custom authentication script to support multiple consumer IDP’s. The key takeaway from this should be the following: within your domain, stick to open standards like OpenID Connect and SAML. This gives you the most flexibility to change your business logic for authentication, without having to update your applications. Article Resource: http://thegluuserver.wordpress.com/2013/11/06/using-ox-for-social-login-2/

3. Think about the front door Businesses are advised to invest in the part of their facility that the customer sees. With access management systems, this is the login experience, and the authorization experience. Frequently I remind Gluu customers to consider the authentication triangle, the vertices are (1) security, (2) price and (3) usability. Each authentication mechanism has its own unique triangle. Much attention lately has been focused on security. But many of the advancements have been to enable stronger security, while at the same time improving usability. The best kind of authentication is the one you never see! Consumer IDPs are looking at many contextual indicators to figure out if an interactive authentication is needed. Organizations should follow suit. Try your best, but be flexible. If a certain application can’t use OAuth2, its ok to fallback. There might be an old version of IIS you need to support. Or the SaaS provider just supports SAML… its ok! Don’t worry. You want to guide applications to use open standards. SAML or even SiteMinder is a lot better than for the website to store credentials for the person. Is SiteMinder “Dead” Granted… “SiteMinder is Dead” is sensationalist. Old SSO protocols hang around until you disconnect the last site. That can be some time, which is why we want the standards to be well tested. That’s why the title of the previous blog said “Decline”, not “Dead”. If you have a sizable organization, and are looking at a green field, are you installing a commercial IAM Suite, an IDaaS, or open source? The last two didn’t even exist until a few years ago. No matter how you slice it, monolithic IAM Suites like CA SiteMinder are going to get a smaller percentage of the market, and reducing prices to get a small number of new customers might not be offset by revenue loss from existing customers. In rapidly growing markets, the price goes down, the total size of the market increases, and the initial suppliers are challenged to make a very difficult pivot.

4. In any case, at Gluu, we think there is a bigger opportunity to provide service to the market that doesn’t yet have a “SiteMinder”, than disrupting current monolithic IAM customers. Most current solutions are hub and spoke: usually a big IDP and lots of internal websites, some external SaaS services, and partner sites. How many inbound SAML connections does your average organization support? The answer is frequently “not many.” Big companies can afford commercial Access Management / Federation software, but their partners usually cannot. Net-net, this means the cost of “extranet” user management is either too high or even worse, its insecure. Organizations want open source because there is a benefit if their partners can cost effectively upgrade their IAM. You can substitute “SiteMinder” with the IAM product of your choice, for example Oracle Access Manager (OAM), RSA Cleartrust, or IBM Tivoli Access Manager (TAM). Although some IAM products also use HTTP reverse proxies, the idea is generally the same: align with the old until you migrate existing apps. Notice in this diagram, there are two OAuth2 Authorization Servers. OAuth2 enables federated authorization… sometimes many parent organizations make different policies, and application developers need to ensure all the policies are considered. Article Source - http://www.gluu.org/blog/how-to-move-away-from-ca-siteminder-to-open-source-authn-authz/