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

[Or Harary]

 On Wed, Feb 14, 2018 at 2:52 PM, Pedro Igor Silva <psilva at redhat.com>
wrote:

>
>
> 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! =]