[keycloak-user] Permissions: Slow/complex interactions

Thu Aug 2 05:35:36 EDT 2018

I tried to use github HEAD, but on startup it gives:
Table 'keycloak.RESOURCE_URI' doesn't exist

On Wed, Aug 1, 2018 at 3:56 PM, Pedro Igor Silva <psilva at redhat.com> wrote:

> Btw, here is the PR https://github.com/keycloak/keycloak/pull/5416
>
> On Wed, Aug 1, 2018 at 10:55 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Yeah, that is why I'm also evaluating graaljs. But I think we will only
>> get better results if using native images (ahead of time compiling vs jit),
>> not sure ... But like I said, I've noticed some improvements in JS runtime
>> when running KC on top of graalvm.
>>
>> I was also wondering if Groovy could be a nice language to support as an
>> alternative/replacement to JS policies ...
>>
>> On Wed, Aug 1, 2018 at 10:46 AM, Corentin Dupont <
>> corentin.dupont at gmail.com> wrote:
>>
>>> It also seems that Nashorn script engine will be deprecated:
>>> http://openjdk.java.net/jeps/335
>>>
>>>
>>>
>>> On Wed, Aug 1, 2018 at 3:25 PM, Corentin Dupont <
>>> corentin.dupont at gmail.com> wrote:
>>>
>>>> I tried to make some more performance testing.
>>>> With the same settings than before (70 resources, one scope), I obtain:
>>>>
>>>> - User policy (3 users): 15 ms
>>>> - Javascript policy 1: 41ms
>>>> - Javascript policy 2: 45ms
>>>>
>>>> It seems that Javascript policies are very slow.
>>>> Actually I think the user policy does not take more than 3 ms to run
>>>> over all the resources (if we remove the time due to HTTP overhead).
>>>> While the Javascript policies take around 30ms to run over the
>>>> resources.
>>>> Is it a problem due to loading/switching to the Javascript engine for
>>>> each resource?
>>>>
>>>>
>>>>
>>>> On Wed, Jul 25, 2018 at 12:58 PM, Corentin Dupont <
>>>> corentin.dupont at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 24, 2018 at 11:11 PM, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> We have now a performance testsuite (thanks to Tomaz) that can
>>>>>> generate also generate datasets to cover different scenarios. I'm the
>>>>>> middle of checking Tomaz work and preparing some datasets to include in our
>>>>>> testsuite.
>>>>>>
>>>>>
>>>>> Great!
>>>>>
>>>>>
>>>>>>
>>>>>> I'm going to give a try to your use case and see if I can get the
>>>>>> same numbers. Not sure if this is your case, but I found some performance
>>>>>> issues when defining multiple resources with a type where the owner is the
>>>>>> resource server itself. This causes an overhead during evaluation where the
>>>>>> engine tries to consider permissions granted to any of these typed
>>>>>> resources. Someone reported this some time ago, and IMO, this is an invalid
>>>>>> usage of resource types ... Not sure if this is your case though.
>>>>>>
>>>>>
>>>>> I don't really use the type of resource, actually... How do you make a
>>>>> permission request based on types?
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> More answers inline.
>>>>>>
>>>>>> On Tue, Jul 24, 2018 at 7:24 PM, Corentin Dupont <
>>>>>> corentin.dupont at gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 24, 2018 at 11:51 AM, Pedro Igor Silva <
>>>>>>> psilva at redhat.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 24, 2018 at 7:54 AM, Corentin Dupont <
>>>>>>>> corentin.dupont at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi guys,
>>>>>>>>> I experience some performance issue on my API server using
>>>>>>>>> Keycloak.
>>>>>>>>> After someone issue a GET on my API server, here is what happens:
>>>>>>>>>
>>>>>>>>> - API server -> DB server: get requested resources
>>>>>>>>> - API server -> Keycloak: get client token (to get resources)
>>>>>>>>> - API server -> Keycloak: get resources (to complement DB server
>>>>>>>>> with
>>>>>>>>> resource owner & visibility)
>>>>>>>>> - API server -> Keycloak: get user token (to get permission)
>>>>>>>>> - API server -> Keycloak: get permission (to filter resources)
>>>>>>>>> At this point the filtered resources are returned.
>>>>>>>>>
>>>>>>>>> But this process is quite slow. I noticed a call to KC can take up
>>>>>>>>> to 100ms.
>>>>>>>>> The complete call on the API server can take up to 600ms on my
>>>>>>>>> laptop, in
>>>>>>>>> localhost setting.
>>>>>>>>> The delays become noticeable on my UI...
>>>>>>>>>
>>>>>>>>
>>>>>>>> Are you able to confirm the step(s) spending more time to process ?
>>>>>>>> If when obtaining client tokens, resources or during evaluation ?
>>>>>>>>
>>>>>>>
>>>>>>> I made a quick benchmark, here is the result:
>>>>>>>
>>>>>>> - API server -> Keycloak: get client token: 400ms
>>>>>>> - API server -> Keycloak: get resources: 1356ms
>>>>>>> - API server -> Keycloak: get user token: 162ms
>>>>>>> - API server -> Keycloak: get permission: 2400ms
>>>>>>> Total: 4366ms
>>>>>>>
>>>>>>> However, this timings are obtained only on the first try after I
>>>>>>> reboot the server.
>>>>>>> The next calls are faster. Maybe it's due to caching?
>>>>>>>
>>>>>>
>>>>>>> - API server -> Keycloak: get client token: 17ms
>>>>>>> - API server -> Keycloak: get resources: 19ms
>>>>>>> - API server -> Keycloak: get user token: 92ms
>>>>>>> - API server -> Keycloak: get permission: 314ms
>>>>>>> Total: 476ms
>>>>>>>
>>>>>>
>>>>>> Yeah, it is caching. But numbers for steps #2 and #4 are high. Will
>>>>>> see what we can improve.
>>>>>>
>>>>>> Thanks for the numbers. Wondering if you have percentiles for these
>>>>>> requests ? Or this happens when you send a single request ?
>>>>>>
>>>>>
>>>>> This is a single request... I scrapped the timestamps in my traces.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> So yes, it's the evaluation taking time (and user token on a lesser
>>>>>>> extent).
>>>>>>> On this call, I need to get permissions for all resources on one
>>>>>>> scope: permissions=#sensors:view
>>>>>>> Because I need to filter out the resources the user cannot see.
>>>>>>> There are around 70 resources and 3 policies (one user policy and 2
>>>>>>> javascript).
>>>>>>> Keycloak is in a docker container.
>>>>>>>
>>>>>>
>>>>>> I'm working with more aggresive numbers, and results are better than
>>>>>> yours. However, all depends on how you are setting up your settings. Need
>>>>>> to check your setup and see if I can create a dataset based on it.
>>>>>>
>>>>>> Could you send me an example of those javascript policies ? Are they
>>>>>> doing much ? Do you have more than one user per user policy ?
>>>>>>
>>>>>
>>>>> I attach my 2 javascript policies. They are very simple, should be
>>>>> O(1).
>>>>> The user policy has 3 users.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Also, could you elaborate more what this step is doing: "- API
>>>>>>>> server -> Keycloak: get resources (to complement DB server with
>>>>>>>> resource owner & visibility)" ?
>>>>>>>>
>>>>>>>
>>>>>>> I read the resources from Keycloak (authz/protection/resource_set/)
>>>>>>> because I need to return the owner of the resource in my server response.
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> With a resource SPI strategy (if developed), it should be:
>>>>>>>>>
>>>>>>>>> - API server -> DB server: get requested resources
>>>>>>>>> - API server -> Keycloak: get user token (to get permission)
>>>>>>>>> - API server -> Keycloak: get permission (to filter resources)
>>>>>>>>> - Keycloak -> DB server: get resources
>>>>>>>>>
>>>>>>>>> There is a little less requests. Additional gain is that resources
>>>>>>>>> are not
>>>>>>>>> split between 2 databases.
>>>>>>>>>
>>>>>>>>> I wonder if resources could be pushed during the permission
>>>>>>>>> request? Like a
>>>>>>>>> "pushed claim".
>>>>>>>>> This would be even more straightforward:
>>>>>>>>>
>>>>>>>>> - API server -> DB server: get requested resources
>>>>>>>>> - API server -> Keycloak: get user token (to get permission)
>>>>>>>>> - API server -> Keycloak: get permission and push resources
>>>>>>>>
>>>>>>>>
>>>>>>>>> Can this work?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think this is an area we might want to improve in order to allow
>>>>>>>> evaluating permissions solely based on claims pushed to the server. That
>>>>>>>> means you won't need to manage resources in the server but rely on policies
>>>>>>>> to process the "pushed claims".
>>>>>>>>
>>>>>>>
>>>>>>> Yes that would be great. Let me open a Jira to track this.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-user mailing list
>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>