Subject: [OAUTH-WG] OAuth 2.0 and Access Control Lists (ACL)

From: Melvin Carvalho <[email-masked]>
Date: Sun, 18 Dec 2011 18:05:42 +0100

Quick question.  I was wondering if OAuth 2.0 can work with access
control lists.

For example there is a protected resource (e.g. a photo), and I want
to set it up so that a two or more users (for example a group of
friends) U1, U2 ... Un will be able to access it after authenticating.

Is this kind of flow possibly with OAuth 2.0, and if so whose
responsibility is it to maintain the list of agents than can access
the resource?

---

From: Doug Tangren <[email-masked]>
Date: Sun, 18 Dec 2011 12:22:18 -0500

> responsibility is it to maintain the list of agents than can access

The scope parameter fulfills this role. It would be up to the service to
document the scope for clients, the auth server to ask the user if they
wished allow the client this extra scope of access, and the resource server
to interpret the scope for the particular request.

---

From: Blaine Cook <[email-masked]>
Date: Sun, 18 Dec 2011 17:49:26 +0000

On 18 December 2011 17:22, Doug Tangren <[email-masked]> wrote:
>
> On Sun, Dec 18, 2011 at 12:05 PM, Melvin Carvalho <[email-masked]>
> wrote:
>>

It's not necessary to use the scope parameter; you'd probably want
some private API that allows an authenticated client to say something
like: "User x is also allowed to access this resource", and when User
X's client obtains an access token, they'll be able to access the
resource in question.

The ACL in any event is the responsibility of the service provider, as
the service provider is the only entity able to enforce access
control.

b.

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Mon, 19 Dec 2011 10:53:45 -0600

The user authentication and access control to the resources is out of the OAuth scope. 
The question is how to make a resource (e.g., a photo) accessible by the authorized clients C1,...,Cn. If each client has obtained a user's authorization for the scopes that include the photo, then all clients' access tokens should enable them to access the photo. If for a client Ci the authorized scope does not include the photo, the client would need get a new user authorization. 

The resource server would be a logical place for maintaining ACL.

Zachary 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melvin Carvalho
Sent: Sunday, December 18, 2011 12:06 PM
To: [email-masked]
Subject: [OAUTH-WG] OAuth 2.0 and Access Control Lists (ACL)

Is this kind of flow possibly with OAuth 2.0, and if so whose
responsibility is it to maintain the list of agents than can access
the resource?
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Mon, 19 Dec 2011 09:58:02 -0800 (PST)

Why do you need OAuth for that?  You can apply the ACL after authentication, OR you can also specifically issue credentials for access to the specific resource, but this is a limited credential rather than applying a per user ACL.

________________________________
 From: Melvin Carvalho <[email-masked]>
To: [email-masked] 
Sent: Sunday, December 18, 2011 9:05 AM
Subject: [OAUTH-WG] OAuth 2.0 and Access Control Lists (ACL)

---

From: George Fletcher <[email-masked]>
Date: Mon, 19 Dec 2011 13:02:51 -0500

I would also recommend looking at User-Managed-Access which provides 
this kind of layer on top of OAuth2.

http://kantarainitiative.org/confluence/display/uma/UMA+Explained

Thanks,
George

---

From: Eve Maler <[email-masked]>
Date: Mon, 19 Dec 2011 15:53:01 -0800

If you check out the recording of the UMA webinar from last week, you'll see a demo (starting at about the 33:00 mark) that shows individual user data being accessed according to ACL-type authorization policy settings, with the resource owner able to set these policies and then not have to be online when the requester shows up:

http://kantarainitiative.org/confluence/display/uma/Home

(As an aside, the UMA spec also provides an extended example that illustrates how scopes can be made interoperable enough to protect photos individually. See http://tools.ietf.org/html/draft-hardjono-oauth-umacore-02, especially Sections 1.4 and 10.)

	Eve

On 19 Dec 2011, at 10:02 AM, George Fletcher wrote:

> I would also recommend looking at User-Managed-Access which provides this kind of layer on top of OAuth2.
> 

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl