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-03which 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
