Re: [keycloak-user] Organization Based Accounts and Permissions

Hi Pedro, Thanks for the suggestions, this is great. Out of curiosity, are we able to make Groups or Roles the owners of resources? I couldn’t find much documentation on the “owner” function within the gitbooks at the moment. Thanks, Justin On 8/17/16, 6:25 PM, "Pedro Igor Silva" <psilva(a)redhat.com&gt; wrote: ----- Original Message ----- From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Charles Henck" <cjhenck(a)live.com&gt; Cc: keycloak-user(a)lists.jboss.org Sent: Wednesday, August 17, 2016 6:38:01 PM Subject: Re: [keycloak-user] Organization Based Accounts and Permissions ----- Original Message ----- 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. 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 :)