[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 2:57 PM, Federico Michele Facca <
federico.facca at martel-innovate.com> wrote:

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

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.


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

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

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.


>
> Federico
>
> On 14 May 2018 at 19:05, Pedro Igor Silva <psilva at redhat.com> 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>
>