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