[keycloak-user] Permissions: Slow/complex interactions

[Corentin Dupont]

Regarding JVM settings, I assume they are correct? Is there a way to
improve?
I use docker-compose to run Keycloak docker. It should not limit the CPU?


On Wed, Jul 25, 2018 at 12:07 PM, Corentin Dupont <corentin.dupont at gmail.com
> wrote:

> This is what I have:
> JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M
> -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true
> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
>
> On Tue, Jul 24, 2018 at 11:21 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Btw, how much you set your heap?
>>
>> Do you have limitations on cpu ?
>>
>> Could you share your JVM settings ?
>>
>> On Tue, Jul 24, 2018 at 8: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.
>>>
>>> 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.
>>>
>>> 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 ?
>>>
>>>
>>>>
>>>> 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 ?
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>