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

Pedro Igor Silva psilva at redhat.com
Wed Sep 19 12:35:31 EDT 2018


On Wed, Sep 19, 2018 at 12:40 PM Brian Brooks (US) <
Brian.Brooks at 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 at 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 at 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#_service_obtaining_permissions
.


More information about the keycloak-user mailing list