11:45 a.m.
Hi guys,
We have a rails app with a very simple Role-Based access control model.
The thing is that this very simple model needs to become something much
more fine grained and I think that keycloak is the right tool for that.
We need a permission system to do the following:
* "Organisations" have users with different roles: Owner, Admins,
Collaborators and Members. These roles are what we call "Resource Roles"
* "Organisations" have modules or packages (for example "Events
package"
or "Email package") that the owner can buy. Only the users with resource
role "Owner" can buy these item
* Owners and Admins of an organisation can edit the organization profile
or any resource of the organization (Event, Meeting, Contact, etc)
* Owners and Admins of an organisation can add users to packages. For
example, user XXXX will have permission to edit,create,destroy and view
any resource created in module YYYY in organisation ZZZZ.
* Owners and Admins can add Collaborators: a collaborator will have
permission to access certain organisation resources, for example,
collaborator XXX will have permission to edit Event YYYYY
* Owners and Admins can add Members: a member will have permission to
see all the resources from all the active packages that are marked as
"visible by members only"
* Members can edit the organization resources they create inside the
packages they have access to
* Packages have limits: if you the organisation is free, you can only
create 2 events for example.
*etc, etc, etc...
These are just a few of the permissions we need. At the moment, the
product owner is changing the roles and permissions regularly trying to
find the best way to monetise and test the business model. We need a way
to deploy those changes as soon as possible and I think keycloak can
help us with this task!
I've done some research about this use case and I found these two
threads [1], [2] in which a similar (simplified) model is discussed.
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
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?
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
1:26 p.m.
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 ...
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
https://lists.jboss.org/mailman/listinfo/keycloak-user
11:06 a.m.
Hi,
I've been able to simplify the policy model a lot by posting claims to
the resource server. Since I'm using rails and there is no adapter and
no policy enforcer implementation, I'm just making calls to the REST API
and sending the claims with the context that I need.
Instead of create a resource for each new entity that the user creates,
in our resource server we create just one resource for each resource
type, for example:
{
"name": "Event Resource",
"type": "Event",
"ownerManagedAccess": false,
"displayName": "Event Resource",
"attributes": {},
"_id": "XXXXXXX",
"uris": [
"http://localhost:3000/events/*
],
"scopes": [
{
"name": "event:create"
},
{
"name": "event:edit"
},
{
"name": "event:show"
},
{
"name": "event:destroy"
}
]
}
{
"name": "Meeting Resource",
"type": "Meeting",
"ownerManagedAccess": false,
"displayName": "Meeting Resource",
"attributes": {},
"_id": "XXXXXXX",
"uris": [
"http://localhost:3000/meetings/*
],
"scopes": [
{
"name": "meeting:create"
},
{
"name": "meeting:edit"
},
{
"name": "meeting:show"
},
{
"name": "meeting:destroy"
}
]
}
I created one Rule-based policy in javascript that reads all the claims
passed by our app in the API call and then decides if the user has
access to a particular instance of the resource.
Doing this I managed to simplify the policy model substantially. On the
other hand, we have to pass to the resource server all the context
(around 15 claims) needed by the policy to know it the user can access a
resource. I'm wondering if this Ok or I'm putting too much logic in the
application side that should be in keycloak.
Furthermore, with this policy model I when I get the entitlements for a
user, the token that we get does not contain a list of resources to
which the user has access. This means we would need to query the
resource server individually for any resource the user wants to access.
I'm quite new to keycloak and UMA. Before, all this logic was
implemented in our application and I'm trying to figure out who should
do what. Since we have a lot of rules, I have the feeling that the
application should provide the context (claims) and keycloak should
implement the rules to grant access to the resources based on that
context. Am I seeing this right?
Thanks again for your help.
Alfonso.
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>> 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>
https://lists.jboss.org/mailman/listinfo/keycloak-user
2:03 p.m.
When doing context-based authorization you need to provide all the
information you need in order to make the correct decisions. I would not
say you are bringing logic to your app but the opposite, where you are just
passing the facts that you need to be processed by your rules/policies.
IMO, what you are doing is fine. Just keep in mind that you might
eventually have some information/claim within the token already.
Regarding the entitlement request, I think you are not getting the
permissions because now your policies are based on certain claims ?
On Mon, Apr 22, 2019 at 1:06 PM Alfonso Alba García <alfonso(a)alfonsoalba.com>
wrote:
Hi,
I've been able to simplify the policy model a lot by posting claims to
the resource server. Since I'm using rails and there is no adapter and
no policy enforcer implementation, I'm just making calls to the REST API
and sending the claims with the context that I need.
Instead of create a resource for each new entity that the user creates,
in our resource server we create just one resource for each resource
type, for example:
{
"name": "Event Resource",
"type": "Event",
"ownerManagedAccess": false,
"displayName": "Event Resource",
"attributes": {},
"_id": "XXXXXXX",
"uris": [
"http://localhost:3000/events/*
],
"scopes": [
{
"name": "event:create"
},
{
"name": "event:edit"
},
{
"name": "event:show"
},
{
"name": "event:destroy"
}
]
}
{
"name": "Meeting Resource",
"type": "Meeting",
"ownerManagedAccess": false,
"displayName": "Meeting Resource",
"attributes": {},
"_id": "XXXXXXX",
"uris": [
"http://localhost:3000/meetings/*
],
"scopes": [
{
"name": "meeting:create"
},
{
"name": "meeting:edit"
},
{
"name": "meeting:show"
},
{
"name": "meeting:destroy"
}
]
}
I created one Rule-based policy in javascript that reads all the claims
passed by our app in the API call and then decides if the user has
access to a particular instance of the resource.
Doing this I managed to simplify the policy model substantially. On the
other hand, we have to pass to the resource server all the context
(around 15 claims) needed by the policy to know it the user can access a
resource. I'm wondering if this Ok or I'm putting too much logic in the
application side that should be in keycloak.
Furthermore, with this policy model I when I get the entitlements for a
user, the token that we get does not contain a list of resources to
which the user has access. This means we would need to query the
resource server individually for any resource the user wants to access.
I'm quite new to keycloak and UMA. Before, all this logic was
implemented in our application and I'm trying to figure out who should
do what. Since we have a lot of rules, I have the feeling that the
application should provide the context (claims) and keycloak should
implement the rules to grant access to the resources based on that
context. Am I seeing this right?
Thanks again for your help.
Alfonso.
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>> 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>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
6:09 a.m.
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...
Alfonso Alba García 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...
2544
days inactive
2550
days old
4 comments
2 participants
participants (2)
-
Alfonso Alba García -
Pedro Igor Silva