It really depends on how different the organization settings are. Without knowing your use case in details, I assume that an organization may have different client applications. A SaaS solution would have organizations mapping to realms and not clients. In this case, each organization has its own user database and security settings. It seems that your use case is more likely related with groups as organizations given that you have a shared user database. FYI, the identity broker feature set in Keycloak can help to solve the "shared user database" across realms problem if you want to keep a single realm as them the main repository of users and still have these users "federated" to other dependent realms. Suppose you have an "Eden" realm where you manage all your users. Then you have "Organization Foo" realm and "Organization Bar" realm. Each of these realms would be configured to delegate authentication to "Eden" realm and thus have users federated across all of them. Just a random thought :) On Thu, Apr 18, 2019 at 8:09 AM Alfonso Alba García <alfonso(a)alfonsoalba.com <mailto:alfonso@alfonsoalba.com>> wrote: Hi Pedro, Thanks a lot for your answer. I will have a look at the three things you are suggesting: groups, resource types and pushing claims. At the moment I'm having a deeper look at the Policy Enforcer documentation. I consider that I read that part of the documentation and did not get it right. As you suggest, pushing claims can simplify my policies. I had a look at the app-authz-rest-employee[1] and app-authz-rest-springboot[2] examples. I already have some ideas about it after going through them. I will post an update after trying a little more. Just one last question: in the first post I asked if using one client per organisation would be a good idea or not. Has anybody some advice about this? I don't know if I'm using the client to do something it's not supposed to do. Thanks again, Alfonso -------- [1] https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-re... [2] https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-re... Pedro Igor Silva wrote: > Hi, > > Some comments inline ... > > On Wed, Apr 17, 2019 at 2:16 PM Alfonso Alba García > <alfonso(a)alfonsoalba.com <mailto:alfonso@alfonsoalba.com> <mailto:alfonso@alfonsoalba.com <mailto:alfonso@alfonsoalba.com>>> wrote: > > I've installed keycloak locally and now I'm trying to implement these > requirements. I've started with the ones I think are the easiest: The > organisation Owner an Administrator. Following what's suggested in the > threads mentioned above, I implemented these resource roles as follows: > > * Create three scopes: organisation:edit, organisation:view, > organisation:billing > > * Create a resource "Organisation 1" with scopes organisation:edit, > organisation:view and organisation:billing > > * Create two client roles "Organisation 1 Owner" and "Organisation 1 > Administrator" > > * Create two policies: "Organisation 1 Owner Policy" and > "Organisation 1 > Administrator Policy" > > * Create one scope-permission "Organisation 1 Managers Permissions" > that > allows users with roles "Organisation 1 Owner" or "Organisation 1 > Administrator" get permission for the scopes organisation:edit and > organisation:view > > * Create one scope-permission "Organisation 1 Owners Permissions" that > allows users with roles "Organisation 1 Owner" access the scope > organisation:billing > > > Your policy model is fine but I think you can make it simpler if you > just use groups to represent organization membership. > > By using groups, you can have a single "Organization Resource", > "Organization Managers Permissions" and "Organization Owner Permission". > Your policies could benefit from claims pushed by your application [1] > in order to make decisions based on whether or not the user is a member > of an organization plus the RBAC. > > For instance, if you have in Keycloak a group "organization-foo" and > your application provides a REST endpoint like "/api/organizations/foo", > you could send the request URI to your policies, extract the "foo" part > of it and check if the user is member of organization-foo. I think the > same logic could be applied to other resource types. > > You could check this example [2]. > > [1] > https://www.keycloak.org/docs/latest/authorization_services/index.html#_e... > [2] > https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-re... > > I created these for three organisations and as well as several users. > I've been playing around with them using the Evaluate functionality of > the keycloak client and apparently everything is working fine. Now I'm > thinking about how I could implement the access to the packages I > mentioned above, the members, etc, but before I continue I have several > questions: > > * Since users can have different roles in different organisations, I'm > creating only one realm. I guess that's ok since different realms do > not > share users. > > * For every organisation that we create in our application we will need > to create all the policies, roles and permissions described above. Is > this supposed to be like that or am I missing something? > > * If this is the way to do it, I was wondering if it's a good idea to > create a Resource Server (i.e. a new client inside the realm) for each > organisation. This way I can create a client organisation-1-client with > all the resources, policies and permissions for "Organisation 1". I > think that this will make deleting an organisation quite easy after the > user deletes the organisation, I just need to delete de client > organisation-1-client. I don't know if this a good idea or not, has it > any negative impact in performance? will this make the application code > more difficult? or may be this not a good practice for any reason? > > > I would recommend you to try other approaches like that one I suggested. > I can think about another one using resource types. > > Considering your current design, I think the addition of a new > organization is pretty much related to a provisioning logic backed by > our REST APIs, so you can automatize this process. But I hope you can > find an alternative ... > > > Thanks for your time. Regards, > > Alfonso > > > ------- > [1] > http://lists.jboss.org/pipermail/keycloak-user/2016-August/007309.html > [2] http://lists.jboss.org/pipermail/keycloak-user/2018-June/014347.html > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@lists.jboss.org>> > https://lists.jboss.org/mailman/listinfo/keycloak-user >