From this package:

Hi Pedro, All, I am have been looking a bit more in the permission CRUD operations. I think that it would be better to split the permission ticket from the permission policy themselves. In fact, if i understand correctly the spec, the current permission endpoint should be only used to create the permission ticket. UMA doesn't say anything on how to represent policies so this is totally up to keycloak. Ideally we should have: - /permission - POST - create a permission ticket - /user-policy (or anything similar) - POST - create a policy (owner of a resource can create a policy on it without RPT process) - GET - list policies - GET /id return a specific policy - DELETE /id remove a policy - PUT /id update a policy While at the time being this endpoint may support only "UMA policies" i.e. x request access to y with scope z, and owner grants it, in the future it could allow resource owners to "manage" directly other policies. E.g. allow scope x to all users in group z. For the time being (given that we needed to allow owners to grant directly access to a resource without using an permission ticket), we modified the existing "PUT" to allow the creation of a permission on a resource if the access token used is the one of the resource owner. Best, Federico On 11 May 2018 at 23:43, Federico Michele Facca <federico.facca@martel- innovate.com> wrote: > Hi, > > On 11 May 2018 at 18:04, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > >> >> >> On Fri, May 11, 2018 at 10:19 AM, Federico Michele Facca < >> federico.facca(a)martel-innovate.com&gt; wrote: >> >>> >>> Now the first question was how to “share” directly a resource with a >>> user. >>> >>> Currently using the API, supposing I am user A and I want to access a >>> resource Z from user B, we proceed as follow (i hope is the correct way… >>> any correction or guidance will be appreciated): >>> >>> 1. We create a permission request on the API (to get the ticket). E.g. >>> read resource x >>> >>> 2. We use the ticket to ask for a rtp token using a user token. >>> >>> curl --request POST \ >>> --url http://127.0.0.1:8080/auth/realms/master/protocol/openid-con >>> nect/token \ >>> --header 'Authorization: Bearer xxx' \ >>> --header 'Content-Type: application/x-www-form-urlencoded' \ >>> --data 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-t >>> icket&ticket=xxxx' >>> >>> If the user has already access, then he gets the rtp, if not he gets: >>> >>> { >>> "error": "access_denied", >>> "error_description": "request_submitted" >>> } >>> >>> Only in this moment the permission ticket i created at step 1 appears >>> in the list of permissions. (I am not sure this is the intended behaviour >>> though). >>> >> >> Yeah, that is the expected behavior. But you can also use a request >> parameter to tell to the token endpoint that you don't want to submit an >> authorization request. See https://www.keycloak.org/d >> ocs/latest/authorization_services/index.html#_service_authorization_aat. >> >> >>> >>> Then is up to the owner to authorise access (via API we can do that by >>> updating the permission and set granted to true) >>> >>> Now let’s suppose that I am the owner of the resource A, and I want to >>> authorise directly (without the user asking access to the resource A) >>> the user Z to access it. How can I do that? At the time being I could >>> not figure it out. >>> >> >> Similar to the update method, you can use the create method to create >> permissions. Is that what you are looking for ? >> See org.keycloak.testsuite.authz.PermissionManagementTest#te >> stCreatePermissionTicketWithResourceName. >> > > from what i see in the code, permission are persisted only when we > invoking the token api with grant_type=urn:ietf:param > s:oauth:grant-type:uma-ticket > > so in my understanding there is now way (assuming I am the owner of the > resource) to store directly the permission (with grant=true), which would > what > could be the way a user could share directly his resources as it is now > possible in the interface. > > am I wrong? > > i am lost... i see that in the code you refer to i see that you invoke > the token api with grant_type=urn:ietf:params:oauth:grant-type:uma-ticket > you are setting > the claim using the accessToken, but i don't see what this has to do with > the ability of a resource owner to grant directly the access to a resource > (i.e. creating a permission with grant = true) > > > -- > *Dr. FEDERICO MICHELE FACCA* > *Head of Martel Lab* > 0041 78 807 58 38 > *Martel Innovate* <https://www.martel-innovate.com/> - Professional > support for innovation projects > Click to download our innovators' insights! > <https://www.martel-innovate.com/premium-content/> > Follow Us on Twitter <https://twitter.com/Martel_Innovate> > -- *Dr. FEDERICO MICHELE FACCA* *Head of Martel Lab* 0041 78 807 58 38 *Martel Innovate* <https://www.martel-innovate.com/> - Professional support for innovation projects Click to download our innovators' insights! <https://www.martel-innovate.com/premium-content/> Follow Us on Twitter <https://twitter.com/Martel_Innovate>

hi pedro, that's are not what we can call "user managed authorisation" policies, in fact are from the "admin" api (and indeed i have been wondering why the back implementation of current "uma permissions" is not based on "user policy"). "user managed authorisation" is related to the fact that a user owns the resource. in practise you could implement "user managed authorisation" using existing policies (this would actually also avoid the current issue i reported, i.e. regarding the complete separation between UMA permissions and policy based permissions at the evaluation time which leads to the fact that authorised users with UMA are not listed as authorised when asking access via permissions)

i copy again the test: My set-up is a follows: 1. I have a policy that says that the owner of a resource is authorised with scope read, write and delete. Such policy is attached to a resource with a * path (e.g. /resource/*). 2. User A create a resource /resource/A 3. User A ask all permissions. He is returned he can do anything on /resource/A So far so good. Now it's the part that i believe is not working as i would expect. 4. User B create a resource /resource/B 5. User B share resource B with User A 6. User A ask all permissions. He is returned he can do anything on /resource/A but no information is returned about resource B, despite there is a permission granted. It looks like User A can check if he can access resource B only if I create a permission ticket and I specifically check that, but as a requester, I don't know in advance if i am authorised to access a resource via UMA ticket or via another policy. In fact, if ask if i have read permission using the permission parameter, i get not authorised: curl --request POST \ --url http://127.0.0.1:8080/auth/realms/master/protocol/ openid-connect/token \ --header 'Authorization: Bearer xxx' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma- ticket&permission=da2fdbf6-076e-4716-8b91-2c7feeda8bee% 23read&audience=test' while if i create a ticket for that resource with permission read, i get authorised. federico On 14 May 2018 at 14:36, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > We do have endpoints for managing policies via Keycloak Admin REST API. > From this package: > > https://github.com/pedroigor/keycloak/tree/035ebc881abfe78 > 544861f394c30b1dd9623f879/testsuite/integration- > arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/client/ > authorization > > You'll find tests for each permission/policy type we support. Is that > what you are looking for ? > > On Mon, May 14, 2018 at 9:25 AM, Federico Michele Facca < > federico.facca(a)martel-innovate.com&gt; wrote: > >> Hi Pedro, All, >> >> I am have been looking a bit more in the permission CRUD operations. I >> think that it would be better to split the permission ticket from the >> permission policy themselves. >> In fact, if i understand correctly the spec, the current permission >> endpoint should be only used to create the permission ticket. UMA doesn't >> say anything on how to >> represent policies so this is totally up to keycloak. >> >> Ideally we should have: >> >> - /permission >> - POST - create a permission ticket >> - /user-policy (or anything similar) >> - POST - create a policy (owner of a resource can create a policy on >> it without RPT process) >> - GET - list policies >> - GET /id return a specific policy >> - DELETE /id remove a policy >> - PUT /id update a policy >> >> While at the time being this endpoint may support only "UMA policies" >> i.e. x request access to y with scope z, and owner grants it, >> in the future it could allow resource owners to "manage" directly other >> policies. E.g. allow scope x to all users in group z. >> >> For the time being (given that we needed to allow owners to grant >> directly access to a resource without using an permission ticket), >> we modified the existing "PUT" to allow the creation of a permission on >> a resource if the access token used is the one of the resource owner. >> >> Best, >> Federico >> >> On 11 May 2018 at 23:43, Federico Michele Facca < >> federico.facca(a)martel-innovate.com&gt; wrote: >> >>> Hi, >>> >>> On 11 May 2018 at 18:04, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: >>> >>>> >>>> >>>> On Fri, May 11, 2018 at 10:19 AM, Federico Michele Facca < >>>> federico.facca(a)martel-innovate.com&gt; wrote: >>>> >>>>> >>>>> Now the first question was how to “share” directly a resource with a >>>>> user. >>>>> >>>>> Currently using the API, supposing I am user A and I want to access a >>>>> resource Z from user B, we proceed as follow (i hope is the correct way… >>>>> any correction or guidance will be appreciated): >>>>> >>>>> 1. We create a permission request on the API (to get the ticket). >>>>> E.g. read resource x >>>>> >>>>> 2. We use the ticket to ask for a rtp token using a user token. >>>>> >>>>> curl --request POST \ >>>>> --url http://127.0.0.1:8080/auth/realms/master/protocol/openid-con >>>>> nect/token \ >>>>> --header 'Authorization: Bearer xxx' \ >>>>> --header 'Content-Type: application/x-www-form-urlencoded' \ >>>>> --data 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-t >>>>> icket&ticket=xxxx' >>>>> >>>>> If the user has already access, then he gets the rtp, if not he gets: >>>>> >>>>> { >>>>> "error": "access_denied", >>>>> "error_description": "request_submitted" >>>>> } >>>>> >>>>> Only in this moment the permission ticket i created at step 1 appears >>>>> in the list of permissions. (I am not sure this is the intended behaviour >>>>> though). >>>>> >>>> >>>> Yeah, that is the expected behavior. But you can also use a request >>>> parameter to tell to the token endpoint that you don't want to submit an >>>> authorization request. See https://www.keycloak.org/d >>>> ocs/latest/authorization_services/index.html#_service_author >>>> ization_aat. >>>> >>>> >>>>> >>>>> Then is up to the owner to authorise access (via API we can do that >>>>> by updating the permission and set granted to true) >>>>> >>>>> Now let’s suppose that I am the owner of the resource A, and I want >>>>> to authorise directly (without the user asking access to the resource A) >>>>> the user Z to access it. How can I do that? At the time being I could >>>>> not figure it out. >>>>> >>>> >>>> Similar to the update method, you can use the create method to create >>>> permissions. Is that what you are looking for ? >>>> See org.keycloak.testsuite.authz.PermissionManagementTest#te >>>> stCreatePermissionTicketWithResourceName. >>>> >>> >>> from what i see in the code, permission are persisted only when we >>> invoking the token api with grant_type=urn:ietf:param >>> s:oauth:grant-type:uma-ticket >>> >>> so in my understanding there is now way (assuming I am the owner of the >>> resource) to store directly the permission (with grant=true), which would >>> what >>> could be the way a user could share directly his resources as it is now >>> possible in the interface. >>> >>> am I wrong? >>> >>> i am lost... i see that in the code you refer to i see that you invoke >>> the token api with grant_type=urn:ietf:params:oauth:grant-type:uma-ticket >>> you are setting >>> the claim using the accessToken, but i don't see what this has to do >>> with the ability of a resource owner to grant directly the access to a >>> resource (i.e. creating a permission with grant = true) >>> >>> >>> -- >>> *Dr. FEDERICO MICHELE FACCA* >>> *Head of Martel Lab* >>> 0041 78 807 58 38 >>> *Martel Innovate* <https://www.martel-innovate.com/> - Professional >>> support for innovation projects >>> Click to download our innovators' insights! >>> <https://www.martel-innovate.com/premium-content/> >>> Follow Us on Twitter <https://twitter.com/Martel_Innovate> >>> >> >> >> >> -- >> *Dr. FEDERICO MICHELE FACCA* >> *Head of Martel Lab* >> 0041 78 807 58 38 >> *Martel Innovate* <https://www.martel-innovate.com/> - Professional >> support for innovation projects >> Click to download our innovators' insights! >> <https://www.martel-innovate.com/premium-content/> >> Follow Us on Twitter <https://twitter.com/Martel_Innovate> >> > > -- *Dr. FEDERICO MICHELE FACCA* *Head of Martel Lab* 0041 78 807 58 38 *Martel Innovate* <https://www.martel-innovate.com/> - Professional support for innovation projects Click to download our innovators' insights! <https://www.martel-innovate.com/premium-content/> Follow Us on Twitter <https://twitter.com/Martel_Innovate>

Hi, I think it makes sense (I hope i understood at least what you mean :) ) As first steps, I could do the following if you agree: 1. Make a pull request that split the permission ticket API from the "policy" api. I propose to use /uma-policy, Basically no change w.r.t. what is there now, except we expose a policy creation method in /uma-policy that can be used only be resource owners to share directly their policies. in future, the model and api can be extended to support "user policies" (in a constrained way of course) beyond "the ticket like" ones.

2. Make a pull request to have in the authorisation part so to combine under certain conditions UMA and normal policy evaluation. e.g. no ticket and no rpt = return evaluation from UMA policies (related to the user identified by the accessToken) + generic policies e.g. permission = return evaluation from UMA policies (related to the user identified by the accessToken and the resources in the permissions) + generic policies (applicable to resources and scopes included in the "permission" request and for the specific user) ticket based authorisation will not change.

The above would allow already to: 1. User A owning a resource B to share directly with User C, without User C asking. 2. User A to ask if he can access to a resource with Ticket or permission indifferently. Later on, we can think how to generalise the "user" policies in something more generic than the ticket based ones (but I think this would be better to be discussed with some design document). Ideally, while the encoding should be the same as the normal keycloak policies, the API should constrain the type of policies created and simplify the creation (allowing a single call to the API rather than multiple ones). Still such policies should be probably stored separately (allowing for control only by users and not by admins). Evaluation will be always disjoint and result aggregated (result = Evaluation generic policies + Evaluation user policies). Still it may be interesting to provide a mechanism (I have to understand how policy evaluation works currently) where if by default resource Type X can be accessible by anyone, the user can say no, this is now protected if instance of Type X is owned by me).

Federico On 14 May 2018 at 19:05, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > I see now... > > We could solve your current issue by fixing the processing of entitlement > requests to also consider permissions granted by a user via permission > tickets. This is the easiest solution ... > > However, I think we would be still limiting users regarding the different > policies they can use to protect their resources. For instance, today a > permission granted directly by the user (and backed by a permission ticket > approved by this same user) takes precedence over whatever policy you have > defined to a resource. > > We could start using a policy (and not the ticket) to decide whether or > not the user is granted access to someone else resource. In fact, it would > make sense to use an Aggregated Policy to combine whatever policy the user > has defined to rule access to a resource. The current implementation is > using the ticket because users can only decide to share a resource or not, > regardless of other conditions. > > The "/user-policy" endpoint you mentioned would be basically managing > the "Aggregated Policy" associated with a specific resource by adding and > removing whatever policy the user wants to define. > > Does it make sense for you? > > -- *Dr. FEDERICO MICHELE FACCA* *Head of Martel Lab* 0041 78 807 58 38 *Martel Innovate* <https://www.martel-innovate.com/> - Professional support for innovation projects Click to download our innovators' insights! <https://www.martel-innovate.com/premium-content/> Follow Us on Twitter <https://twitter.com/Martel_Innovate>

Hi, On 14 May 2018 at 21:36, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > > > On Mon, May 14, 2018 at 2:57 PM, Federico Michele Facca < > federico.facca(a)martel-innovate.com&gt; wrote: >> >> 1. Make a pull request that split the permission ticket API from the >> "policy" api. I propose to use /uma-policy, >> Basically no change w.r.t. what is there now, except we expose a >> policy creation method in /uma-policy that can be used only be resource >> owners to share directly their policies. >> in future, the model and api can be extended to support "user >> policies" (in a constrained way of course) beyond "the ticket like" ones. >> > > What if we just change HTTP POST to /permission to persist tickets where > this operation is only allowed if the owner is making the request (like you > said)? We could add both "requester" and "grant" properties to > PermissionRequest. If grant is marked as true we persist the ticket. > i think that in the end this is not going to be "clean" because: a) to extend to "real" policies we will need any how to have the /uma-policy endpoint b) in my understanding the according to the standard, /permissions is only to create tickets (you cannot manage them) c) we are going to embed more and more information in the ticket that is not part of the standard (requester and grant)

d) :P i almost have a pull request to split the end point (tests are running locally, for the time being as regards the authz client, i deprecated the old methods, but are still supported (i changed the endpoint)

> > >> >> 2. Make a pull request to have in the authorisation part so to combine >> under certain conditions UMA and normal policy evaluation. >> e.g. no ticket and no rpt = return evaluation from UMA policies >> (related to the user identified by the accessToken) + generic policies >> e.g. permission = return evaluation from UMA policies (related to >> the user identified by the accessToken and the resources in the >> permissions) + generic policies (applicable to resources and scopes >> included in the "permission" request and for the specific user) >> ticket based authorisation will not change. >> > > +1. The change should e quite trivial. > > >> >> The above would allow already to: >> 1. User A owning a resource B to share directly with User C, without >> User C asking. >> 2. User A to ask if he can access to a resource with Ticket or >> permission indifferently. >> >> Later on, we can think how to generalise the "user" policies in >> something more generic than the ticket based ones (but I think this would >> be better to be discussed with some design document). >> Ideally, while the encoding should be the same as the normal keycloak >> policies, the API should constrain the type of policies created and >> simplify the creation (allowing a single call to the API rather than >> multiple ones). >> Still such policies should be probably stored separately (allowing for >> control only by users and not by admins). Evaluation will be always >> disjoint and result aggregated (result = Evaluation generic policies + >> Evaluation user policies). >> Still it may be interesting to provide a mechanism (I have to understand >> how policy evaluation works currently) where if by default resource Type X >> can be accessible by anyone, the user can say no, this is now protected if >> instance of Type X is owned by me). >> > > I played with this a bit and the changes should be quite trivial. > Basically, everytime a ticket is marked as "granted" we create a aggregated > policy. Then we add to this policy a user policy that grants access to the > requester. Once this is set, the policy evaluation engine will treat UMA > permissions just like any other policy associated with the resource. The > difference is that decisions taken from a UMA policy (now a aggregated > policy) takes precedence over any other policy associated with the resource. > > you surely know the code better than me :) i started looking into it last thursday xD > When access is revoked by removing a ticket, we also remove the > aggregated policy. > > The nice thing abou this is that we could use the "/uma-policy" (or > whatever name we decide for this) to allow users to manage policies > associated with a resource (add users, time, group, etc). Instead of what > we have today that always grant access to a requester if there is a ticket > granted by the owner (good for now but limited if we think about more > complex use cases). > looks nice, things is "how" to define resource from the user perspective then without conflicting with "global" definition of resource. e.g. admin creates a default resource that map to a generic endpoint /resource/{id} and defines default policies. would the user be able to define his own policies for all the resources he will own that that match the pattern /resource/{id} ? i suppose this in the ends means creating "a new policy" with path /resource/{id} that is specific to the user and where he can attach his policies and that is evaluated only for resources owned by him.

maybe to complex at this point :) > > The user could configure if they want to all policies to evaluate to a > PERMIT or just one of them, etc, etc. > > Maybe an endpoint like this "/permission/{resource_id}/policy". > > Btw, won't ask you to move this discussion to keycloak-dev :) Sorry for > that. > > -- *Dr. FEDERICO MICHELE FACCA* *Head of Martel Lab* 0041 78 807 58 38 *Martel Innovate* <https://www.martel-innovate.com/> - Professional support for innovation projects Click to download our innovators' insights! <https://www.martel-innovate.com/premium-content/> Follow Us on Twitter <https://twitter.com/Martel_Innovate>

hi, On 14 May 2018 at 23:11, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > > > On Mon, May 14, 2018 at 5:15 PM, Federico Michele Facca < > federico.facca(a)martel-innovate.com&gt; wrote: > >> Hi, >> >> On 14 May 2018 at 21:36, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: >> >>> >>> >>> On Mon, May 14, 2018 at 2:57 PM, Federico Michele Facca < >>> federico.facca(a)martel-innovate.com&gt; wrote: >>>> >>>> >>>> OK, let`s see what you have. It will be nice to get a better picture > on what you are proposing. I don't see any issue in extending the spec and > supporting those additional methods to /permissions (as long as we support > what is defined in the spec). > i made the pull request for splitting the ticket creation from the ticket management. this was the /permission api stays fully compliant with the standard spec.

we will have "/uma-policy" we may not need anymore the ticket management, but that requires a bit of work on the specs, since i think the api need to be simple and not requiring many different calls as it is in the admin api (thus hiding the complexity to the user, while keeping the same internal re-presentation). the policy structure could be something like: { subject: "xxx", (id linked to a subjectType) subjectType: "xxx" (a user, a group, a role, a client) resource: "xxx", resourceType: "xxx", scopes: [ "xxx", "xxx" ], "owner": "xxx" (creator of the policy) "active": true (or false), "positive": true (or false) } so he can express things as: - share with scope read resource A to user X - share with scope read resource A to group X - share with scope read resource A to client X - share with scope read resource A to role X - share with scope read any resource of type Z (owned by me) to user X

and so on. current ticket could be then translated to "share with scope read resource A to user X" with active = false and we would not need "ticket management". my current code knowledge is not good enough to evaluate if the above can be done leveraging on the current "policy store" and it allow to filter policies by owner (so that admin should not be able to see / edit them in the current list of client policies).

should we have a google doc to discuss this?

today i am gonna work on 2: >>> >>>> >>>> 2. Make a pull request to have in the authorisation part so to combine >>>> under certain conditions UMA and normal policy evaluation. >>>> e.g. no ticket and no rpt = return evaluation from UMA policies >>>> (related to the user identified by the accessToken) + generic policies >>>> e.g. permission = return evaluation from UMA policies (related to >>>> the user identified by the accessToken and the resources in the >>>> permissions) + generic policies (applicable to resources and scopes >>>> included in the "permission" request and for the specific user) >>>> ticket based authorisation will not change. >>>> >>> >>> +1. The change should e quite trivial. >>> >>> >> federico > >> -- >> *Dr. FEDERICO MICHELE FACCA* >> *Head of Martel Lab* >> 0041 78 807 58 38 >> *Martel Innovate* <https://www.martel-innovate.com/> - Professional >> support for innovation projects >> Click to download our innovators' insights! >> <https://www.martel-innovate.com/premium-content/> >> Follow Us on Twitter <https://twitter.com/Martel_Innovate> >> > > -- *Dr. FEDERICO MICHELE FACCA* *Head of Martel Lab* 0041 78 807 58 38 *Martel Innovate* <https://www.martel-innovate.com/> - Professional support for innovation projects Click to download our innovators' insights! <https://www.martel-innovate.com/premium-content/> Follow Us on Twitter <https://twitter.com/Martel_Innovate>