[keycloak-user] Performance with a large number of resources

[Scott Elliott]

On Fri, May 5, 2017 at 7:51 AM Pedro Igor Silva <psilva at redhat.com> wrote:

> On Thu, Apr 20, 2017 at 3:38 PM, Scott Elliott <scottpelliott at gmail.com>
> wrote:
>
>> Using the photoz application as an example, what is the expected
>> performance if there are a very large (say, 5M) number of albums?  What
>> about if there are multiple resources per album?  You quickly get a very
>> large number of resources. The OIDC adapters cache some number of these,
>> so
>> what effect will that have on the resource server?
>>
>
> Right now we cache things based on a very simple LRU cache with some
> expiration of entries. Number of cached entries is fixed though. Something
> we can expose via configuration.
>

"Right now" being 3.1.0.CR1?  What about in 2.5.5.Final?


>
>
>>
>> Ideally there would be a way to authorize any resource associated with an
>> album, so if /album/vacation were authorized by /album/{id},
>> /album/vacation/photo/1 was also authorized, i.e., the URI that selects
>> the
>> resource to be authorized would always be /album/vacation.
>>
>
> All depends on how fined grained you want your config. For instance, if
> you define a path "/album/{id}/*", the same resource (and associated
> permissions) will also be related with resources like "/album/vacation" and
> "/album/vacation/photo/1". However, if you have a resource on the server
> with a path "/album/vacation/photo/1", the enforcer is going to use this
> resource to check whether the user has access or not.
>
>

This gets us back to my original question about passing other info to the
authorization request.  Right now we'd have too many resources that would
need to be registered and maintained.  I did a hack as a test to add the
actual URL to the permission request, and set it in the ticket in the
permission response, so that it is passed to the authorization request, and
can be accessed as part of the evaluation context.  It does what we need,
but I do not know if it violates any standard.

Scott