Re: [keycloak-user] Permissions: Slow/complex interactions

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(a)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(a)gmail.com&gt; wrote: > >> >> >> On Tue, Jul 24, 2018 at 11:11 PM, Pedro Igor Silva <psilva(a)redhat.com&gt; >> 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(a)gmail.com&gt; wrote: >>> >>>> >>>> >>>> On Tue, Jul 24, 2018 at 11:51 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jul 24, 2018 at 7:54 AM, Corentin Dupont < >>>>> corentin.dupont(a)gmail.com&gt; 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(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>> >>>>> >>>>> >>>> >>> >> >