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

[Federico Michele Facca]

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)


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