[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 23:11, Pedro Igor Silva <psilva at redhat.com> wrote:

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