Re: [Ace] attribute based access control

[Randy Turner <[e-mail]>]

Hi Ludwig,

Apologies for getting back to you so late on your ABAC-related email reply — your approach sounds very similar to what we were thinking - originally, we were looking at CBOR-encoded JSON that represented an equivalent XACML authorization request.  However, we are also exploring ACE credentials grant flows as well, interpreting one or more token fields in our own way. 

I think an ABAC form of ACE would be a popular use-case going forward, and I was thinking an ABAC profile of ACE could be a “normative” thing, instead of an informational appendix or other example text.  This would allow my client to work with your AS, and other potential interoperable scenarios.  At the moment, our interpretation of how to do this would be a proprietary use of the token fields.

I looked at the ACE document collection and I’m not sure I see a document wherein a normative profile of a credentials grant for ABAC would fit.  Do you think an ABAC profile of ACE should be spec’d as a standards track document ?

Thanks!

Randy

On Dec 16, 2016, at 3:47 AM, Ludwig Seitz <[e-mail]> wrote:

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" class="" rel="nofollow">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" class="" rel="nofollow">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 http://www.ri.se/en/about-rise" class="" rel="nofollow">www.ri.se/en/about-rise