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

[Federico Michele Facca]

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