Re: [Ace] attribute based access control

[Randy Turner]

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 <lud...@sics.se> 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 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 +46(0)70-349 92 51 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

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace