[keycloak-user] Using Keycloak for per field authorisation

[Pedro Igor Silva]

We appreciate any feedback. Performance is one of the key aspects we will
be looking at for now on. Next release will have some improvements and we
hope to deliver more.

On Thu, Aug 16, 2018 at 12:23 AM, Courtney Robinson <
courtney.robinson at hypi.io> wrote:

>
>>> 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.
>
>