[keycloak-user] [keycloak-dev] How to share a resource with a user via UMA 2.0 API

[Pedro Igor Silva]

On Mon, May 14, 2018 at 5:15 PM, Federico Michele Facca <
federico.facca at martel-innovate.com> wrote:

> Hi,
>
> On 14 May 2018 at 21:36, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>>
>>
>> On Mon, May 14, 2018 at 2:57 PM, Federico Michele Facca <
>> federico.facca at martel-innovate.com> 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)
>

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).


>
>
>>
>>
>>>
>>> 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.
>

In fact, if I understood correctly what you said, we already have support
that. If you have a typed resource (/resource/{id} and type foo} associated
with some default permissions/policies you can override permissions when
evaluating them for a resource with the same type that belongs to the user
(/resource/1 and type foo).


>
> 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>
>