How does policy mechanism works related to scope and user management ?

By: Pek Templeton user 29 Mar 2017 at 2:57 a.m. CDT

4 Responses
Pek Templeton gravatar
Hello, I have some issues in understanding on how authorization regarding policies and scope works (theoretically) such as described in UMA specs and done in Gluu implementation. I read the related topic in [gluu's doc](https://gluu.org/docs/ce/latest/admin-guide/uma/#uma-policies). And also read the related part in [UMA spec](https://docs.kantarainitiative.org/uma/rec-uma-core.html) in the recommendation version which defines scope, resource and policy such as: - **_Resource set: One or more protected resources that a resource server manages as a set, abstractly. In authorization policy terminology, a resource set is the "object" being protected. This term derives from [OAuth-resource-reg]._** - **_Scope: A bounded extent of access that is possible to perform on a resource set. In authorization policy terminology, a scope is one of the potentially many "verbs" that can logically apply to a resource set ("object"). UMA associates scopes with labelled resource sets. This term derives from [OAuth-resource-reg]._** - **_Policy: The configuration parameters of an authorization server that effect resource access management. Authorization policies typically include elements similar to parts of speech; for example, "subjects" describe those seeking access (requesting parties and clients), "verbs" describe operational scopes of access, and "objects" describe targeted resource sets. Policy configuration takes place between the resource owner and the authorization server, and thus is out of scope for this specification._** And describe its use in [part 2](https://docs.kantarainitiative.org/uma/rec-uma-core.html#protecting-a-resource). From these and other sources my understanding of it is that a scope is something which define an action which can take place on the resource_set. Am I wrong? But here is where I am confused. It is that considering that policies are bound to a scope and that a user can add its own policies wouldn't these policies which are user specific not working with such scope? Or is it necessary to create a generic policy with like a db to store the user policies? But in such case what are the interests of being able to set multiple policies to a scope? It is to say that I don't quite understand not the authorization flow but the authorization mechanism/structure inside the AS. Thanks in advance for your time and enlightenment, Pek Templeton
Gluu Other OS Version : N/A
closed

Answers

By Yuriy Zabrovarnyy staff 29 Mar 2017 at 9:39 a.m. CDT

Copy
Yuriy Zabrovarnyy gravatar
Hi Pek, Scope describes "something" that grant client permission to do some action on the resource. It's not really action, e.g. "read" action can be allowed with scope "read" or "all". Means that different scopes can grant access to the same action. At the same time for some action Resource Server (RS) may want different scopes at the same time. It all depends on RS implementation and business logic behind. Policy defines whether to grant access or not for given scope. Lets take example, we have resource `GET /photo`. In order to access it RS required "read" scope. If we have dummy policy which always return true than with authorization request to /photo with scope "read" the access will be granted successfully because policy always return true. From here if we wish to have some sophisticated logic to grant access only to specific client then on authorization request /photo with scope "read" in policy we can put something like client_id = "@1111". Policy allows to provide logic whether to grant access for given authorization request (with scope) or not. I hope it helps. Thanks, Yuriy

By Pek Templeton user 29 Mar 2017 at 10:17 a.m. CDT

Copy
Pek Templeton gravatar
Hi, Thanks for your answer. I do understand this simple user case but where I get confused is when you get multiple ressource, the scope is not really "read" but more "user@1111_read" because it cant be reused for another resource to authorize another user if you do not wish to have user "@1111" to also be allowed. So does it makes sense in a UMA sense to have a scope by user or a scope by resource if you set specific user in policy? In such case what is the interest of policies and interest of scope for the second part? And is it a good practice? My problem is not really the technical feasability of an idea it is more about understanding if it respect the idea behind UMA and Gluu's implementation. Hope you understand where my grey area is. Pek

By Yuriy Zabrovarnyy staff 29 Mar 2017 at 10:45 a.m. CDT

Copy
Yuriy Zabrovarnyy gravatar
Pek, Not sure I really understood the grey area but anyway ... It depends on how you wish to handle protection. Scope can be multi-resource ("read") or it can be per-resource ("photo_read") however I can hardly understand what would mean per-user scope. In that case scopes would need to be handled somehow on the fly? Usually user permissions are handled via claims/attributes (e.g. role=manager). In first and second case the role of policy is clear. For user scope case of course policy would not make much sense because scope is specific enough. But to be honest I never saw such cases as well as UMA implementations with dynamic scope generation. Do you know any ? It would be interesting to look into it. Thanks, Yuriy

By Pek Templeton user 30 Mar 2017 at 10:25 a.m. CDT

Copy
Pek Templeton gravatar
After thinking a lot about it, I think that only the scope multi-resource and per-resource makes practical sense. Because first, dynamic scope generation wouldn't make practical sense and then a scope by user would technically work but I think it would defeat the purpose of scope and policy(because resources are declared by RS and managed with AS so more than that it would break the expected behavior(because you would need the RS to change "policies")). Moreover the use of per-user scope over user permission would cause an overhead which might not be unconsequential for large set. For information the case I thaught which might profit a simpler mechanism is data sharing between individuals . But as I said, I don't think its a good (long term) solution at all. Thanks to you I think I better understand the subject and I cleared all of my questions. I will close the ticket. Thanks for your time and have a good day. Pek

Post an answer