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...
.