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
Acmes OpenID Connect API (served by OX), and
includes the GET parameters auth_modeyahoo.
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
youd 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 informationfor example
address, phone number, account numberto 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 APIs, like
Janrain or Gigya. These services would enable you
to create one custom authentication script to
support multiple consumer IDPs.   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/usin
g-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 cant 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! Dont 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. Thats 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
didnt 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
doesnt 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/