[keycloak-user] Keycloak 4.x Fine Grained Authorization - OAuth / UMA - Permissions That Deny Rather Than Grant?

[Pedro Igor Silva]

On Tue, Sep 18, 2018 at 11:29 AM Brian Brooks (US) <
Brian.Brooks at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>