[keycloak-user] Share resource by checking if some other user is in a certain group

[Pedro Igor Silva]

Btw, created https://issues.jboss.org/browse/KEYCLOAK-6628. Fell free to
review description and provide any information you find relevant.

Thanks.

On Thu, Feb 15, 2018 at 8:00 AM, Or Harary <harary.or at gmail.com> wrote:

> On Wed, Feb 14, 2018 at 2:52 PM, Pedro Igor Silva <psilva at redhat.com> wrot
> e:
>
>>
>>
>> On Wed, Feb 14, 2018 at 10:11 AM, Or Harary <harary.or at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Thanks for the response.
>>> I have a policy which checks if a user is in a certain group which is
>>> related to the resource, but my case is a bit different because I want to
>>> check if another user (not the one who calls the authorization api) is in a
>>> group.
>>> I'll try to explain some more-
>>>
>>> I have one case like this:
>>>
>>> some resource with the following path:
>>> /company/{company id}/resource_name/{resource_id}
>>>
>>> a group representing the company with the name:
>>> /company/{company id}
>>>
>>> Users who are managers in the company are in this group.
>>> I have a group mapper which puts the groups with their full path inside
>>> the token.
>>> This way it's easy for me to check if a user has access to a company's
>>> resources by a JS policy (match the groups companies ids with the resource
>>> uri).
>>>
>>> My different case with the wallet is that the resource is not held by
>>> the company, it's the user's resource and this resource should be "visible"
>>> by multiple company's in the right conditions.
>>> This resource URI is:
>>> /{user-1-id}/wallet/{wallet-id}
>>> as I mentioned before
>>>
>>> So when a "manager" (a user in a company's group) try to access a
>>> different user resource like this, I don't have the option to check groups,
>>> because I need the resource owner groups and not the groups of the user who
>>> requests the permissions.
>>> Hope it clears the question a little more.
>>>
>>
>> Yeah, it is clear now. Thanks.
>>
>> I think we can improve the Evaluation API and expose the owner as an
>> object. Or even provide additional methods to check roles/groups that
>> accept an username/id (such as the owner as it stands today).
>>
>>
>
> That would be awesome! querying the resource owner groups/roles would work
> great for me here!
>
>
>
>> Other improvement we are planning is allow pushing additional claims when
>> obtaining a RPT (token with permissions) from the server. Not sure if this
>> is going to help you in this case, but you will be able to push these
>> claims to your policies and use them to determine a decision.
>>
>> For last, there is also an issue to introduce attributes to resources ....
>>
>
>
> Pushing claims could also help in some stuff but resource attributes will
> be more efficient.
>
>
>
>>
>>
>>>
>>> With the improvements you mentioned about the user managed access will
>>> it be possible to control it by a policy or will it be implicit by
>>> specifying specific users which will be able to access this resource?
>>> because I need a dynamic solution (managers can always change)
>>>
>>
>> By specifying specific users which will be able to access a resource.
>> This is not controlled by a policy, but a direct approval by the resource
>> owner to access some of his resources. The main idea behind this feature is
>> privacy. Users should be able to grant access, revoke and review access to
>> his resources anytime (such as using Keycloak User Account Service). But
>> you can also manage these permissions using the RESTful endpoints I
>> mentioned before.
>>
>> These permissions override any result produced by the evaluation engine.
>> If this user-defined permission exists (and are granted), access is granted
>> even though your policies voted for a DENY.
>>
>
>
> Sharing like this is also very useful and will also be a great improvement
> and let users control their resources access better.
>
> Thanks a lot for the help,
> Would love to see these improvements when they'll arrive! =]
>
>