Re: [Ace] attribute based access control

[Ludwig Seitz <[e-mail]>]

On 2016-12-16 07:28, Randy Turner wrote:
> HI,
>
> I was looking at draft-ietf-ace-oauth-authz-04, specifically the
> client-to-AS section — I am trying to determine if it is possible to
> use this OAUTH-based model to implement attribute-based authorization
> (ABAC). The client-to-AS section of this draft refers the reader to
> section 4 of RFC 6749, which provides a “client-id” (good) and a
> “scope” to include in an authorization request.


> In addition, it looks like the ACE draft adds to this the “aud” and
> “cnf” parameters.
>
> I’m trying to map this client-to-AS request to a traditional ABAC
> authorization request which asks the question “Identity <A> wants to
> perform action <B> on resource <C>” … is this allowed ?  (allow/deny
> response)
>
> In one of the ACE draft examples, it uses the “aud” field to include
> the name of a sensor “tempSensor4711”  - this could be the “resource”
> of the ABAC request, and the “client ID” (RFC 6749) could be the
> “identity”
>
> I’m missing the type of operation or “action” that the client is
> trying to perform on a resource (“read”, “write”, “something else,
> hopefully extensible”) — would this be the “scope” parameter ?
>
> I did see section 8.2 of the draft where it discusses a registry of
> parameters which might allow additional parameters to a client-to-AS
> request, but I was looking for a way to do ABAC without having to
> register anything.
>
> I’m specifically asking about obtaining an access token to be used
> later by a client accessing the actual resource.
>
> Has anyone tried combining draft-ietf-ace-oauth-authz-04 with ABAC
> systems ?

Yes I have. My approach is the following:

I use the OAuth client credentials grant flow to request an access 
token, and then I use an XACML engine internally on the AS to decide on 
access token requests base on the client's credentials and the "scope" 
and "aud" parameters of the access token request.

When it comes to extracting an action and a resource from an access 
token request, my understanding is that the scope parameter actually 
gives you both in an application specific way.

If you look at the examples of how scope is used in 
https://www.brandur.org/oauth-scope you can see that e.g. LinkedIn uses 
some kind of capability-like format for their scope parameters 
(r_basicprofile r_emailaddress rw_groups w_messages). Thus you could 
extract the action and the resource from scope with an application 
specific processing module.

You could also have a look at
https://tools.ietf.org/html/draft-bormann-core-ace-aif-03
which defines a CoAP specific capability format. I was considering to 
use that as values for the scope in CoAP-specific scenarios.

I would be happy to hear your take on this and discuss the issue in more 
detail.

Regards,

Ludwig



-- 
Ludwig Seitz, PhD   SICS Swedish ICT AB
Ideon Science Park, Building Beta 2
Scheelevägen 17, SE-223 70 Lund
Phone [phone]

The RISE institutes SP, Swedish ICT and Innventia are merging in order
to create a unified institute sector and become a stronger innovation
partner for businesses and society. At the end of the year we will
change our name to RISE. Read more at www.ri.se/en/about-rise