Juju OAuth2 Application Security Design Proposal

1
Juju OAuth2 Application Security Design
Proposal

• We dont need SSO, we need trust elevation
•  
• There is no point in designing a solution that
  provides just (SSO). Today, people are using an
  array of devices (think IOT). Applications need
  to understand how (and how long ago) a person has
  been authenticated, and based on the context of
  the situation, whether they need to
  re-authenticate a person. There is no way to
  efficiently address the complexities of trust
  elevation without the ability to centrally define
  policies. Authentication single sign on alone is
  not flexible enough.
•   
• Integration Point The Application
• As a green field design, it makes sense for Juju
  to adopt the most advanced application security
  technology available. Only an OAuth2 based
  authentication and authorization solution has the
  potential to address the the newest requirements
  that domains face to secure APIs, web and native
  applications. Lessons learned from SAML and OAuth
  1 have taught us that developer usability is the
  key to adoption. OAuth2 offers two relatively
  painless integration options for web developers

2
Inter-Domain Trust Management   SSO would be easy
if you could figure out which domains you want to
trust, and what information about people you want
to share with them. Luckily, federation SAML
provides an excellent example of how to manage
trust in an ecosystem of partners multi-party
federations. See In Common for a good example of
a multi-party federation. In this model, a host
organization defines the rules that partners in
the ecosystem will abide, and the protocols and
schema that members will use to exchange
data.   Although no standards yet exist for
multi-party federations in OAuth2, the same idea
can be borrowed from SAML. A trusted central
authority publishes the metadata, which
contains the participants in the federation,
their public certificates, and information about
the services they offer. The metadata can be used
by the applications for discovery. The federation
also provides the legal Agreements. For example,
if you want to join In Common, you can read the
Participation Agreement here. Federations can be
very formal or very informal, depending on the
participants and their business goals. The
federation is also a good place for domains to
collaborate on threat detection and other
inter-domain security issues.
3
If you already have a SAML federation, you are
one step ahead. New protocols bring new jargon
and business considerations. For example, the UMA
OAuth2 profile defines client, authorization
server, resource server and scopes. OpenID
Connect also has its own jargon. Likely, the
federation will also have to reference an OAuth2
multiparty federation standard, like the one Gluu
proposed in the Emerging Work section of the
OpenID Foundation Wiki. As the considerations for
federation extend beyond OpenID Connect, the IETF
may be a good place for this standard, for
example perhaps as an OAuth2 working group. Note
protocol translation alone from SAML to OAuth2
will not work because OAuth2 brings new
capabilities. But there is no reason why SAML and
OAuth2 support at the federation needs to be
mutually exclusive.   Article resource -
http//thegluuserver.wordpress.com/2014/05/16/how-
to-benchmark-ox-for-a-large-scale-deployment/