Enterprise OAuth Infrastructure

OAuth in the Enterprise (W1H)

Convener: RL “Bob” Morgan, Dave Sanford

Notes-taker(s): Dave Sanford

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:' This session was to explore some of the problems that Enterprises, including mid or small sized are having in being able to apply Oauth (and other mass market identity solutions) to solve real problems in their space.

Oauth typically is not used in the internal Enterprise context. There is the need to use ‘consent close’ in the Enterprise context. Currently Bob has lots of Rest based applications using X.509 certs and internal developers hate them. The developers believe that Oauth would be easier, controlling access within the Enterprise.

Alan (HP) asked about whether there is a need to extend internal Oauth to Federations and external users? Bob would like to be able to support them. There was agreement that currently for most organizations, how to do this is very ad-hoc.

There are differences in the perceived managers of permissions - currently with Federation and with X.509 certs – administrators can revoke, with Oauth the intent is to allow permissions to be managed and chosen by users, some of the time.

There was information from Ping Identity discussing the systems they provide that allow administrators and/or user to revoke tokens.

Much discussion about the fact that the relying party in Oauth has the advantage of not having to revoke them, tokens. Bob indicated that various legacy applications should not be in the business of validating tokens. The need for front-ends in this case was discussed.

Justin discussed the work that has been going on within Mitre for years applying enterprise Oauth – most of this has been using two-legged Oauth, but they also have use cases where Oauth is used in the context of the user, but is auto-approving authorization on their behalf. By policy Mitre knows that it is appropriate in these cases to take action on behalf of the user, however the token is appropriately scoped to the user in these cases. Mitre is using hexblobs for most tokens today. Mitre has some consent cases between DMZ to internal case (social app in DMZ, talking to internal system). This uses lots of code Mitre has created, but has made it easy for developers.

Ping Identity discussed that they are primarily seeing SAML for the Federated piece, with Oauth for native apps. Mike Schultz indicated that since providing an OpenID Connect IDP – they are starting to use it for their internal use.

Bob re-iterated as part of discussion that client certs are a pain in the ass, and difficult to use. Justin indicated that Oauth, SAML, OpenID connect can all be pulling from the same user store, they just use different end-points. OpenID connect on top of Oauth allows you to build out standardized identity APIs, consistent with Oauth, and also provides discovery.

Salesforce discussed the fact that they have stood up Oauth and have built OpenID connect – in a way that provides single sign-on and have the ability to provide cryptographic bearer tokens (essentially these are signed SAML assertions).

Salesforce is providing this for customers and still sending people through authorization. Administrators can take control of an application and administrators have the ability to authorize on behalf of all of their users, or have the ability to allow the users do it directly. From the application level it is the same.

Lots of discussion of how Salesforce provides Oauth service to customers – mostly around the fact that they are providing bearer tokens and are not re-validating the user upon use.

Justin indicated that in the Enterprise you are likely to end up with lots of authorization servers, and while you may want to consolidate, you probably cannot every do it fully. Rogue authorization servers are inevitable. Mitre is building mainly on the Spring Security Oauth project, and will continue to provide some open source code to the community, that may be useful to enterprises in building and using Oauth internally.

Ping Identity indicated that if the Enterprise customer has a lot of mobile apps default Oauth says authenticate for each time. They are looking for more standard ways to bulk token authorization. Mitre indicated that they have a helper app to allow that to happen. Various issues were discussed involving bulk tokens crossing organizational boundaries (Federated bulk token case).

Justin indicated that members of the Oauth and OpenID working groups are committing code out to Open Source – Apache Amber project, Spring Security. Those interested should start at protocol pages and will find links from there to various open source efforts.