9:26 a.m.
Thanks for providing keycloak as an free open source security solution. It's
awesome!
**QUESTIONS**
1. Is there any way to design a keycloak policy for a oauth/uma/bearer token authorization
client/resource owner that efficiently expresses the idea that a user is granted access to
most items but denied access to a few?
Our system manages devices and for some customer systems we have as many as 0.1 million
devices. We'd like the app's keycloak policy to default to granting a user write
access to all devices but deny access to maybe a few dozen. Ideally, the Requesting Party
Token (RPT) response would contain a list of permissions like
Permission {id=3e633107-2291-4694-9f07-728ea6fa7744, name=All Devices Resource,
scopes=[device:grant:write]}
Permission {id=86d95056-7e24-4888-93ed-2afe33199212, name=Device 123 Resource,
scopes=[device:deny]}
Permission {id=33333333-3333-3333-3333-333333333333, name=Device 456 Resource,
scopes=[device:deny]}
2. Does this make sense; is there a better way to implement this idea?
3. Is this possible with keycloak?
4. Are there any quickstart examples that demonstrate use of denials?
I've been working with the keycloak quickstarts app-authz-uma-photoz and
app-authz-jee-servlet for a while but I don't see them using any "denial"
permissions. All the permissions seem to be "grants".
I've also have been searching the keycloak mailing list for similar questions. I have
not seen an answer to this question in these policy related threads:
1. [keycloak-user] Additional attributes for an authorization request
http://lists.jboss.org/pipermail/keycloak-user/2017-February/009451.html
2. [keycloak-user] How to implement this using Keycloak
http://lists.jboss.org/pipermail/keycloak-user/2016-July/007069.html
3. [keycloak-user] Keycloak authorization protected resource with user attributes
http://lists.jboss.org/pipermail/keycloak-user/2016-December/008821.html
4. [keycloak-user] understanding the photoz example
http://lists.jboss.org/pipermail/keycloak-user/2016-December/008917.html
**DETAILS ABOUT APPLICATION**
We're upgrading our device management application with keycloak authentication and
authorization. We sell our device management application to customers that install and
operate the device management application to run the customer's systems. Our device
management application consists of:
1. Single Page Application that runs in a web browser.
2. Google Dart-based server-side application from which the SPA gets its data (we wish it
was Tomcat-based but don't own the source code).
3. OSGi container running many bundles from which the Dart application get its data.
4. Several other parts e.g. Reporting, Device Data Collectors, database
For this generation of the application and due to our atypical architecture, we'll
probably be manually walking the claims in the RPT in JavaScript to govern our SPA's
user interface authorization.
The most important data in our system are devices. Devices consist of commands, alarms,
values, grids. Devices are typed similar to the relation between Java objects (device)
and Java classes (device_type). Devices and parts of devices can be logically grouped
into one or more "circuits". A device is attached to a computer (Device Data
Collector).
A typical system has:
1,000 devices; a very large system may have 0.1 million devices.
100 circuits
Each device has <100 commands, <300 fields, <50 grids, <100values
Each circuit has 5-20 devices
<15 computers
<100 users; a very large system may have 500 users
Here are some of our application's use cases. Write for our use cases means send
commands, change values, etc.
Administrators can write to all devices and circuits.
Operator A can only read all devices.
Operator B can write to all devices except device123, device456, and device678.
Operator C can only write circuit1.
Operation D can only write computer1.
Thanks for reading this far!
5. Any advice on how to implement these use cases with a keycloak policy? Is it too
ambitious to model this hiearchical permission scheme? What do you recommend? We're
a very small development team trying to implement finish this in 2018.
Brian
4:23 p.m.
On Tue, Sep 18, 2018 at 11:29 AM Brian Brooks (US) <
Brian.Brooks(a)datapath.com> wrote:
Thanks for providing keycloak as an free open source security
solution.
It's awesome!
**QUESTIONS**
1. Is there any way to design a keycloak policy for a oauth/uma/bearer
token authorization client/resource owner that efficiently expresses the
idea that a user is granted access to most items but denied access to a few?
Our system manages devices and for some customer systems we have as many
as 0.1 million devices. We'd like the app's keycloak policy to default to
granting a user write access to all devices but deny access to maybe a few
dozen. Ideally, the Requesting Party Token (RPT) response would contain a
list of permissions like
Permission {id=3e633107-2291-4694-9f07-728ea6fa7744, name=All Devices
Resource, scopes=[device:grant:write]}
Permission {id=86d95056-7e24-4888-93ed-2afe33199212, name=Device 123
Resource, scopes=[device:deny]}
Permission {id=33333333-3333-3333-3333-333333333333, name=Device 456
Resource, scopes=[device:deny]}
2. Does this make sense; is there a better way to implement this idea?
3. Is this possible with keycloak?
4. Are there any quickstart examples that demonstrate use of denials?
Do you mean also returning the resources/scopes that were not granted by
the server ?
I've been working with the keycloak quickstarts app-authz-uma-photoz and
app-authz-jee-servlet for a while but I don't see them using any "denial"
permissions. All the permissions seem to be "grants".
I've also have been searching the keycloak mailing list for similar
questions. I have not seen an answer to this question in these policy
related threads:
1. [keycloak-user] Additional attributes for an authorization request
http://lists.jboss.org/pipermail/keycloak-user/2017-February/009451.html
2. [keycloak-user] How to implement this using Keycloak
http://lists.jboss.org/pipermail/keycloak-user/2016-July/007069.html
3. [keycloak-user] Keycloak authorization protected resource with user
attributes
http://lists.jboss.org/pipermail/keycloak-user/2016-December/008821.html
4. [keycloak-user] understanding the photoz example
http://lists.jboss.org/pipermail/keycloak-user/2016-December/008917.html
**DETAILS ABOUT APPLICATION**
We're upgrading our device management application with keycloak
authentication and authorization. We sell our device management
application to customers that install and operate the device management
application to run the customer's systems. Our device management
application consists of:
1. Single Page Application that runs in a web browser.
2. Google Dart-based server-side application from which the SPA gets its
data (we wish it was Tomcat-based but don't own the source code).
3. OSGi container running many bundles from which the Dart application get
its data.
4. Several other parts e.g. Reporting, Device Data Collectors, database
For this generation of the application and due to our atypical
architecture, we'll probably be manually walking the claims in the RPT in
JavaScript to govern our SPA's user interface authorization.
The most important data in our system are devices. Devices consist of
commands, alarms, values, grids. Devices are typed similar to the relation
between Java objects (device) and Java classes (device_type). Devices and
parts of devices can be logically grouped into one or more "circuits". A
device is attached to a computer (Device Data Collector).
A typical system has:
1,000 devices; a very large system may have 0.1 million devices.
100 circuits
Each device has <100 commands, <300 fields, <50 grids, <100values
Each circuit has 5-20 devices
<15 computers
<100 users; a very large system may have 500 users
Here are some of our application's use cases. Write for our use cases
means send commands, change values, etc.
Administrators can write to all devices and circuits.
Operator A can only read all devices.
Operator B can write to all devices except device123, device456, and
device678.
Operator C can only write circuit1.
Operation D can only write computer1.
In general, you should try using scope-based permissions to govern access
fo each scope you want to protect. When creating scope-based permissions
you can a set of one or more scopes so the permission will be evaluated for
any resource associated with any of these scopes.
You can also write JS policies like that:
var context = $evaluation.getContext();
var identity = context.getIdentity();
var permission = $evaluation.getPermission();
var resource = permission.getResource();
if (identity.hasRealmRole('operator_b')) {
var resourceName = resource.getName();
if (resourceName.equals('Device 123')
|| resourceName.equals('Device 456')
|| resourceName.equals('Device 678')) {
$evaluation.deny();
}
} else {
$evaluation.grant();
}
Is just a matter of making sure this policy is evaluated all the time for a
set of one or more scopes (e.g.: using scope-based permissions for the
scopes you want to protect) or resources with a specific type (e.g.:
resource-based permissions with a type) .
Thanks for reading this far!
5. Any advice on how to implement these use cases with a keycloak policy?
Is it too ambitious to model this hiearchical permission scheme? What do
you recommend? We're a very small development team trying to implement
finish this in 2018.
We don't support hierarchies .... But you can define types to your
resources and apply permissions for any resource with the same type without
having to define a specific permission for each resource.
Brian
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
10:40 a.m.
Hi Pedro,
Thanks for taking the time to respond.
I responded to your question inline below.
Brian
> On Tue, Sep 18, 2018 at 11:29 AM Brian Brooks (US)
<mailto:Brian.Brooks@datapath.com> wrote:
>
> 1. Is there any way to design a keycloak policy for a oauth/uma/bearer token
authorization client/resource owner
> that efficiently expresses the idea that a user is granted access to most items but
denied access to a few?
>
> Our system manages devices and for some customer systems we have as many as 0.1
million devices.
> We'd like the app's keycloak policy to default to granting a user write
access to all devices
> but deny access to maybe a few dozen. Ideally, the Requesting Party Token (RPT)
response would
> contain a list of permissions like
>
> Permission {id=3e633107-2291-4694-9f07-728ea6fa7744, name=All Devices Resource,
scopes=[device:grant:write]}
> Permission {id=86d95056-7e24-4888-93ed-2afe33199212, name=Device 123 Resource,
scopes=[device:deny]}
> Permission {id=33333333-3333-3333-3333-333333333333, name=Device 456 Resource,
scopes=[device:deny]}
On Tuesday, September 18, 2018 5:23 PM Pedro Igor Silva <psilva(a)redhat.com> wrote:
Do you mean also returning the resources/scopes that were not granted by the server ?
No, I was trying to minimize the number of permission entries in the RPT. If the set of
devices a user
can access is
{All Devices} - {Device 123, Device 456}
Then I was trying to model the permissions that way i.e.
grant(All) + deny({Device123,Device456}).
Rather than
grant(Device0,Device1,Device2,...,DeviceN-3), where N may be 0.1 million.
N-3 because Device123 and Device456 will not be included because this user isn't
authorized.
Our concern is overloading keycloak with too many resources and the RPT with too many
permission entires.
Is the an upper limit on how many resources keycloak supports?
Has any scalability testing been done on resource count? If so, what were the results?
By "resources", I mean the data shown in this part of the Keycloak Admin
Console
http://localhost:8180/auth/admin/master/console/#/realms/photoz/clients/&...
If denials are not really supported in keycloak, are there any quickstart examples that
demonstrate "paging" the
RPT when resource counts/permissions exceed 10,000 (or whatever value would result in HTTP
response problems)?
11:35 a.m.
On Wed, Sep 19, 2018 at 12:40 PM Brian Brooks (US) <
Brian.Brooks(a)datapath.com> wrote:
Hi Pedro,
Thanks for taking the time to respond.
I responded to your question inline below.
Brian
>> On Tue, Sep 18, 2018 at 11:29 AM Brian Brooks (US) <mailto:
Brian.Brooks(a)datapath.com> wrote:
>>
>> 1. Is there any way to design a keycloak policy for a oauth/uma/bearer
token authorization client/resource owner
>> that efficiently expresses the idea that a user is granted access to
most items but denied access to a few?
>>
>> Our system manages devices and for some customer systems we have as
many as 0.1 million devices.
>> We'd like the app's keycloak policy to default to granting a user write
access to all devices
>> but deny access to maybe a few dozen. Ideally, the Requesting Party
Token (RPT) response would
>> contain a list of permissions like
>>
>> Permission {id=3e633107-2291-4694-9f07-728ea6fa7744, name=All Devices
Resource, scopes=[device:grant:write]}
>> Permission {id=86d95056-7e24-4888-93ed-2afe33199212, name=Device 123
Resource, scopes=[device:deny]}
>> Permission {id=33333333-3333-3333-3333-333333333333, name=Device 456
Resource, scopes=[device:deny]}
>
> On Tuesday, September 18, 2018 5:23 PM Pedro Igor Silva <
psilva(a)redhat.com> wrote:
> Do you mean also returning the resources/scopes that were not granted by
the server ?
No, I was trying to minimize the number of permission entries in the RPT.
If the set of devices a user
can access is
{All Devices} - {Device 123, Device 456}
Then I was trying to model the permissions that way i.e.
grant(All) + deny({Device123,Device456}).
Rather than
grant(Device0,Device1,Device2,...,DeviceN-3), where N may be 0.1
million.
N-3 because Device123 and Device456 will not be included because this
user isn't authorized.
Our concern is overloading keycloak with too many resources and the RPT
with too many permission entires.
Is the an upper limit on how many resources keycloak supports?
No limit.
Has any scalability testing been done on resource count? If so, what
were
the results?
Nothing official, but we did a few performance improvements in the last
releases and the number of resources should not impact performance. But how
you obtain permissions from the server. For instance, if you ask
permissions for all resources you could get bad response times depending on
how many resources you have. But requesting only a few, using limits to the
number of permissions the server should evaluate and performing incremental
authorization, you should get a good experience.
The number of resources you actually need also depends on how you design
your resources and permissions. For instance, if all your resources share
the same access constraints, you could have a "Device Resource"
representing all of them, where permissions associated with this resources
can be used to check whether or not user have access to a set of devices.
In a nutshell, you should consider a resource in keycloak not only as 1:1
map to what you want to protect as it can also represent a set of one or
more resources in your application.
Considering your example, why the user can't access Device123 and Device456
? Are you denyning access to the resource or only for some scopes/actions
users can perform on it ?
By "resources", I mean the data shown in this part of the
Keycloak Admin
Console
http://localhost:8180/auth/admin/master/console/#/realms/photoz/clients/
<client-id>/authz/resource-server/resource
If denials are not really supported in keycloak, are there any quickstart
examples that demonstrate "paging" the
RPT when resource counts/permissions exceed 10,000 (or whatever value
would result in HTTP response problems)?
https://www.keycloak.org/docs/latest/authorization_services/index.html#_s...
.
2276
days inactive
2277
days old
3 comments
2 participants
participants (2)
-
Brian Brooks (US) -
Pedro Igor Silva