Juju OAuth2 Application Security Design Proposal

1. Juju OAuth2 Application Security Design Proposal We don’t 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 API’s, 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/