Enterprise OAuth BOF Level Set

Issue/Topic: Enterprise OAuth BOF

Session: Wednesday 1E + 2E

Conference: IIW-11 November 2-4, Mountain View, Complete Notes Page

Convener: Marius S. Justin R.

Notes-taker(s): Phil Hunt

Tags:

Discussion notes:

Minutes of the Enterprise OAuth BOF

Apologies if I missed any attendees. These are notes are an attempt to paraphrase the general discussion only. Please let me know of any missing items and edits!

Many thanks for the large group of folks that attended to make this session really work. While I started this with a blog post and provided some loose organization, it was great to have everyone come forward to offer to pick up talks in advance. Special thanks to Patrick Harding of Ping Identity, Thomas Hardjono of MIT, Eric Sachs of Google for the help in setting this up. As in the notes, it is clear we should keep the dialog going. Feedback is appreciated. Should we follow with more IIW sessions, or should we meet more frequently?

Regards, Phil

Use Case Session, Led by Nishant Kaushik

Nishant Kaushik started the discussion with describing the Mint.com web site as an example of usage of uid/pwd and screen scraping of banking information which was something that is of concern to the banking community. One of the issues discussed that in the current status this might help the banks because as unwilling participants they can't be expected to accept liability. Whereas with a potential OAuth solution, they would be seen as supporting 3rd party access.

Patrick Harding indicated that this is a generic case here where businesses have partnered often with 3rd party services but want to deliver convenient SSO enabled service, but then the 3rd party needs access to data from the owner. Rather then opening broad access to the 3rd party, the enterprise actually does prefer a delegated access model as offered by OAuth.

There was some discussion that there may be some variations in scenarios where content providers are offering licensed or metered content.

There was a general discussion that there are lots of enterprise/consumer use cases, some where user consent is required, others where it isn't needed. Bob Blakley pointed out that in many cases, (such as the Banks) they will also want to ascent to a service provider acting on a user's behalf.

The conversation then shifted to one around how operations are initiated, Patrick Harding indicated that the Mint model follows a SP initiated paradigm whereas a bank referring a customer to a 3rd party service provider is an IDP initiated paradigm. The IDP initiated paradigm is certainly more common at present.

Prateek Mishra asked if there is an issue of duration, scope, and granularity of consent? Patrick indicated that Ping sees this as proceeding along strong contractural relations between SPs and IDPs.

Nishant: there is also the app store model. There are enterprise customers that do want to build 3rd party value-add services.

Alan Karp: Commented that Oauth tokens can be used as an enabling technology, bearer tokens that carry limited rights with minimal buy-in.

Prateek: Do you think bearer tokens are enough?

Alan: I don't know if they are enough, but they are a starting point

Bob: If you think they are enough you should go to the firesheep presentation.

Prateek: The issue is whether there is a strong binding to the service provider...so that the token can't be passed around

Alan: You can't stop passing around. They will want to do that.

Eric Sachs: This doesn't have to be solved technically it could be solved in contract law.

Bob: The question becomes is the CP authorizing mint.com or is it authorizing the user to allow mint.com to access.

Alan: The user wants to click on a share button and grab a token that can be passed around to familiy members.

Prateek: Isn't that an extended case where the access token is not bound to the SP, but rather is just bound to the user.

Paul Madsen: Who asks for the token, is it the user, or the application working on behalf of the user?

Bob: You could design it to work either way.

Patrick: Not sure we're hearing that kind of requirement in the enterprise space.

Alan: We have built several UIs where the user doesn't have to worry about the underlying complexity.

General/Prateek: There could be a general policy that states that clicking on a "share" button indicates certain types of consent.

Chuck Mortimore: Mentioned that there are ssos and session management issues to think about.

Bob: OAuth are being used to establish corba-like "associations" to handle the absence of session management. The idea is to remove re-authentications that are occuring because of session management issues rather than a policy requiring re-authentication.

Bob: are we overloading session management on to Oauth

Chuck: OAuth gives the applications an idea of a separate identity from the user...they can make different access decisions about the entity.

Bob: The fact that people are doing this without it being designed to happen may be a good reason to be worried.

Prateek: Do we need some guidance on OAuth+sessions.

Chuck: people seem to be already handling this well. Probaby we need good guidance on refresh, issues and re-authentication issues.

Observations...

1. Questions whether content providers (e.g. banks) will agree to participate in an OAuth delegated system
2. What forms of user consent needed: IDP, Content Provider. Long term vs. Short term (transactional)
3. Token strength and format, bearer, others?
4. Token is bound to a user, should not be bound to a service?
5. User may not have direct relation with the service provider.
6. On subject of contracts or relations:

• • CP would have list of SPs
    • static relations
    • user believes they are interacting iwth the content provider?
  • CP is the only IDP
  • Or, Dynamic - no pre-existing relationship defined. Parties are brought together by the user

1. B2B use-case
2. Methodology to Expose apis on the internet
3. Session management. Need guidance on refresh issues and re-authentication.

Kerberos and OAuth, led by Thomas Hardjono, MIT

Thomas Hardjono - I'm with the MIT Kerberos consortium. When we first heard the news, we felt kerberos had been re-invented again.

We have the same questions with regards to the tokens.

Gartner had some data 60% of enterprises deploy AD and kerberos enabled infrastructure.

For many being able to sell software into the enterpise, being able to work with windows kerberos is a given.

Redhat has a product called FreeIPA which has this challenge.

What we are hearing from financial folks is how can replicate this infrastructure for our own customers. How can we can extend Kerberos service tickets to be used as tokens? Why because this has been looked at for 20 years. TGT is equivalent to refresh token. Many of the functionality of OAuth has been available in Kerberos for some time.

So customers are asking how kerberos tickets can be used in a federated relationship.

How can we integrate kerberos with OAuth.

One possiblity is to wrap a service ticket so it can be used in OAuth. But the other side would have to know how to unwrap it.

vmware: Some of the hold hierarchical admin models of old systems does not work in the cloud. The rigidity is not because of the protocol, but rather the implementation. If you toss out k

Phil: Oauth is working on a cloud architecture where relationships are highly firewalled. Can a Kerberos adapt well to this environment?

Chuck: the oauth ocmmunity is also working from a place of large scale and availability. It isn't necessarily that isn't being ignored.

Thomas: There hasn't been a history that proves the success of oauth

Chuck: Yes, there is an issue that some sites want to deploy relatively lightwieght by intent. Yet if a poorly implemented OAuth situation gets compromised the press won't differentiate it from an enteprise implementation that is secure.

Thomas: there isn't a spec for token in OAuth.

Chuck: That's true, but most web tokens aren't specified or standardized.

Pam: tokens shouldn't be specified, but they should be translatable.

Chuck: The ability to adjust tokens to a standaridized form is difficult. The tokens don't need to be interoperable and there isn't really value in having that way. Changing the session tokens has huge impact. If I need to exchange with a partner I federate and do token translation at that point.

General...there are lots of situations where kerberos is used to authenticate to the IDP which then issues a saml assertion to bootstrap into OAuth. Token exchange isn't a bad thing but probably a requirement.

Alan: one of the issues of Kerberos is the administrative problem can be burdensom, so many enterprises revert back to simple NTLM

Chuck: OAuth takes it to another extreme by forcing responsibility back on the user.

Chuck: is there a good summary about why cross-domain kerberos isn't working?

Vmware: Sharepoint seems to be the only usecase where it has been popular.

Alan: But it is still difficult to run internally.

Alan: I can't issue tokens for rights in mutually distrustful situations (e.g. DOD)

Alan: I'm not against either, but I'd like to make sure OAuth learns from some of the failrues of kerberos.

vmware: we want to move away from on-premise STSs because of the binding to AD. Can we move them to the cloud.

Prateek: OpenId and SAML have been responding to this issue of loose-coupling. OAuthv10 does some of this, but it is still too lightweight on security. But it will be difficult because security impacts rigidity and loose coupling.

Pamela Dingle: Many won't be willing to go through 400 pages of specs, we have to get the knowledgable people to participate in the generation of the OAuth spec.

Prateek: maybe we need to have a group of enterprise folks go off and isolate the key use cases and possibly develop some code.

SAML and OAuth, Lead By Prateek Mishra

Observation:

1. The basic web client profile in oauth is basically the saml artifact profile
2. The security properties of OAuth seem to be very under specified. When I see another implementer of the draft spec, I wonder what have they done to secure the implementation because in SAML the attacks were difficult to get nailed down. Excepting the point that people probably won't want to be told what type of token to use.

Chuck the main problem is that some of the providers don't have the same security posture. There is a broad range of needs. Becuase they are running at very high scale and state replication can be a big issue.

Pam: this sounds like a profiling exercise to identify multiple profiles for different types of requirements.

Chuck: as a practical point we should set up a working group to work on enterprise security issues.