Hi,
Some comments inline ...
On Wed, Apr 17, 2019 at 2:16 PM Alfonso Alba GarcĂa <alfonso(a)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 ...