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