[keycloak-user] Using Keycloak for per field authorisation

[Courtney Robinson]

>
>
>> One of us in the team will be working on this in our next sprint so a lot
>> of things should fall into place as part of this.
>>
>
> In the next release, we are also delivering improvements around
> performance. We found places we could improve and especially the policy
> evaluation engine. We have introduced some cache layers to avoid redundancy
> when evaluating permissions/policies. Let us know about your experience, we
> know we can still improve it. But as the first work we did around
> performance tests, the results are pretty much good (and much better from
> previous releases).
>
>

Sounds good. I'll provide feedback once we've implemented and put it under
some real load

with it. One outstanding concern with our proposed move to Keycloak for
>> authorisation is understanding how to scale it well with the rest of our
>> stack.
>>
>
> Not it is not and you are not the first one from community with similar
> requirements. Maybe we could start discussing and including this in our
> roadmap.
>

I am more than happy to do that. Keycloak provides everything we think we
need for authz so we're more than happy to help get that last 20% in there.
We're a tiny team though so I expect we wouldn't be able to do much in the
way of contributions until mid-Nov after our current roadmap targets have
been delivered. Post that we can schedule some Keycloak work into our
sprints.


>> I've had an attempt at a user SPI and concluded we'd be better off
>> pushing it to Keycloak backed by Postgres. (Considered if we could write an
>> Ignite drop in or something similar but the effort wasn't worth the initial
>> perceived gains since users are probably going to remain relatively small
>> compared to resources).
>> Out of interest however, Keycloak's using Hibernate right? How pluggable
>> is this so that it could be replaced with Hibernate OGM?
>>
>
> IIRC, OGM is based on JPA spec, right ? If you mean implementing User SPI
> sing OGM, it should work.
>

Yeah, the latest OGM is JPA 2.2 compliant now if memory serves. It's more
of a Hibernate for "NoSQL" so you could hook up Cassandra, Ignite, CouchDB
etc as a persistence unit and for the most part use the Hibernate APIs as
if they were going to a relational DB.
I meant more of a drop in replacement so all of the Keycloak persistence
went through OGM. I'll experiment, I just asked in case you readily knew.

Nice. As I mentioned before, we have been working with performance
> improvements. During this work I noticed that performance is not really
> related with the number of resources or scopes, but on how you design your
> policies and how you obtain them from server. For instance, if you query
> the server for all permissions an user has, you would not get good
> throughput. However, if you can perform incremental authorization, ask for
> chunks of permissions, etc, you will get a good throughput. Of course, this
> is relative, I could give you numbers but that could be misleading and not
> based on your real constraints.
>
> This is an area we want to improve for now on, so, feedback is always
> welcome.
>

I think because the entry point to our API is GraphQL it lends itself well
to being able to do incremental authorisation. I'll have some feedback soon
on how this turns out.
Thanks for all the info. it's been very helpful.