[keycloak-user] Organization Based Accounts and Permissions

[Ushanas Shastri]

Classification: INTERNAL
Hello,

I don’t mean to hijack this thread, but I've had similar requirements, and would love some advice.

Do you create Resources based on Features (menus in an application) or based on actual data.  For e.g. if Bank Account Maintenance is a feature that allows you to create/update bank account information, do you create a Resource in KC for each bank account in the system, and then give permissions/policies on it, or do you create one Bank Account resource as indicative of the type Bank Account?

Regards, Ushanas.
Viteos Fund Services Ltd | www.viteos.com
Direct : +91-22-61082230 | US : +1- 888-821-7561 extn 240
Cell : +91-9820225580
Email : ushanas.shastri at viteos.com

-----Original Message-----
From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Pedro Igor Silva
Sent: Thursday, August 18, 2016 3:56 AM
To: Charles Henck
Cc: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] Organization Based Accounts and Permissions

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Charles Henck" <cjhenck at live.com>
Cc: keycloak-user at lists.jboss.org
Sent: Wednesday, August 17, 2016 6:38:01 PM
Subject: Re: [keycloak-user] Organization Based Accounts and Permissions

----- Original Message -----
> From: "Charles Henck" <cjhenck at live.com>
> To: keycloak-user at lists.jboss.org
> Sent: Tuesday, August 16, 2016 4:49:01 PM
> Subject: [keycloak-user] Organization Based Accounts and Permissions
> 
> 
> 
> Hello all,
> 
> I’m working on an organization-based service and want to have 
> resource-specific permissions that are restricted by (from a user
> perspective) organization-specific roles. Since I’m not familiar with 
> the specific terminology, I’m thinking of something similar to how 
> GitHub manages their permissions:
> 
> 
> 
> - A single user can be a member of multiple organizations
> 
> - A user can have a different roles with different organizations that 
> grant them access to all of an organization's resources

If the organizations each represent a separated realm, you won't be able to share users. In Keycloak, an user belongs to a single realm.

I think that with some creative naming for roles (and groups), you can get there.

> 
> - A user can have access to a specific resource
> 
> - That organization-specific role determines access to different 
> organization resources

You can address these two by using our authorization services. Or even writing a plenty of "ifs" in your application based on the information carried by a token. I would suggest you to give a try to the authorization services :)

For instance, let's say you have a "Organization A Resource". This resource is associated with a "Organization A Resource Permission". Here the "Organization A Resource" represents any resource in Organization A and "Organization A Resource Permission" represents all the policies you want to enforce to any resource that belongs to Organization A. In this case, you can apply different types of policies to these resources, for instance, only users with role "organization-a-role" are allowed.

You may also have a "Charles Resource", which was created by your service using the Protection API. In this case, your service may specify that "Charles Resource" belongs to Charles (resource owner) and apply permissions/policies to this resource that define that only Charles is allowed to access.

Going further, let's say that you want to give temporary access to your resource to someone. You may create a "Temporary Access Policy" that specifies which users (user-based policy) are allowed to access your resource.

Another thing you can do is perform access decisions based on the actions that you can perform on your resource. Let's say that everybody can see your resource, but only the resource owner (you) can edit or delete it.

I'm really thinking about pushing a new example application with a permission model similar to github, it will be fun :)

> 
> 
> 
> Are there any best practices or patterns for this model?
> 
> 
> 
> Thanks!
> 
> Justin
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Viteos Capital Market Services Ltd.and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity