MapStore-Feedback and Questions #15470

dominikschlosser · 2022-11-11T18:33:02Z

dominikschlosser
Nov 11, 2022

Hi Keycloak-Team!

We are currently looking at the new Map Storage and have feedback that may be helpful for further development of the store. Our assumption here is that you guys are giving high priority to supporting 3rd party store implementations for non-standard databases.

We are developing an implementation based on Apache Cassandra. The reason for this is the customer's infrastructure (as is probably the case for a large number of other deployment scenarios for Keycloak - the big USP of Keycloak, in our view, is its adaptability to existing infrastructure).

We have noticed the following:

Extending the physical layer (as we believe you envision) is not as easy for us to do. This is due to the fact that Cassandra specifies a so-called query-first approach. This means that the data model is basically defined by the queries, which have to be known in advance. Dynamic queries via CriteriaBuilder or similar are exactly the opposite of this (see also MapStorage: Provide query names as hint for custom implementations which are not able to directly translate QueryParameters #15345).
Therefore we opted to override the logical layer (UserProvider, RoleProvider etc.). Unfortunately it is no longer possible to set the default implementation via KC_SPI_USER_PROVIDER=cassandra or similar (because these properties are overwritten by the Quarkus Config API). Currently, however, there is the Datastore SPI, via which it is possible to override some (not all! e.g. sessions) of these providers. Will this remain a viable way in the future?
There are also implicit dependencies on the physical layer in the logical layer, e.g. the username constraint mechanism. This only works via a unique constraint in the database. There is no such thing in Cassandra, for example.
Another implicit dependency is on the first-level cache of Hibernate. Without this, the performance drops dramatically, since an extremely large number of redundant calls are made per transaction (our customer has therefore implemented a custom L1 cache).

Our most important questions are therefore whether it will be possible to overwrite the logical layer in the future and whether the missing providers (UserSession, AuthSession, ...) will also be included in the datastore SPI?
In addition, we would be very interested to know when we can expect an implementation of the FileStorage, so that we can simply provision everything outside of Cassandra (static configuration) via file.

How such an extension could look like can be seen here: https://github.com/opdt/keycloak-cassandra-extension

Best Regards
Dominik

hmlnarik · 2022-11-14T10:06:56Z

hmlnarik
Nov 14, 2022

Hi Dominik, thank you very much for your feedback!

Let me respond to your points below:

Extending the physical layer (as we believe you envision) is not as easy for us to do. This is due to the fact that Cassandra specifies a so-called query-first approach. This means that the data model is basically defined by the queries, which have to be known in advance. Dynamic queries via CriteriaBuilder or similar are exactly the opposite of this (see also MapStorage: Provide query names as hint for custom implementations which are not able to directly translate QueryParameters MapStorage: Provide query names as hint for custom implementations which are not able to directly translate QueryParameters #15345).

A query can have its name determined from the ModelCriteriaBuilder, say a realm_id=? and user_id=? would correspond to userById. However the ability to extend the queries should be perserved to allow further extension of Keycloak features without need to touch the base store layer, and for that reason the query names should be not predefined.

Yet there is a possible solution: for any storage implementation in the need to enumeration can implement a method (say getAlias) of its ModelCriteriaBuilder to return an alias (say userById) of its instance, when known, or throw an CriterionNotSupportedException otherwise.

Therefore we opted to override the logical layer (UserProvider, RoleProvider etc.). Unfortunately it is no longer possible to set the default implementation via KC_SPI_USER_PROVIDER=cassandra or similar (because these properties are overwritten by the Quarkus Config API). Currently, however, there is the Datastore SPI, via which it is possible to override some (not all! e.g. sessions) of these providers. Will this remain a viable way in the future?

The logical layer aggregates too much logic and represents to big a cost for maintenance, since new features often required introducing new methods. For that reason, overriding logical layer will not be supported, and the only supported store API after removal of legacy store will be the map store. Composition of stores (required e.g. for LDAP support) is also only targetted to physical layer.

The datastore SPI will remain but please beware it is subject to arbitrary change without deprecation period. Thank you for highlighting the importance for you to contain all areas, #15490 has been introduced to mend this.

There are also implicit dependencies on the physical layer in the logical layer, e.g. the username constraint mechanism. This only works via a unique constraint in the database. There is no such thing in Cassandra, for example.

There are certain stores that do not support arbitrary definitions of constraints, and for that reason Keycloak attempts to check if a duplicate exists in logical layer (e.g. duplicate username are checked here). Still if a constraint can be defined, it is advisable to use it for better measures. However if Cassandra does not support it, it falls into this less reliable check.

Another implicit dependency is on the first-level cache of Hibernate. Without this, the performance drops dramatically, since an extremely large number of redundant calls are made per transaction (our customer has therefore implemented a custom L1 cache).

As for this one, this is correct observation, map storage does not perform as well as it could with cache. There are plans to address it by plugging a cache store on top of a to-be-cached store by using the tree store. This work is planned after the tree store would be ready.

0 replies

dominikschlosser · 2022-11-14T18:36:26Z

dominikschlosser
Nov 14, 2022
Author

Thanks for your answer @hmlnarik !

A query can have its name determined from the ModelCriteriaBuilder, say a realm_id=? and user_id=? would correspond to userById. However the ability to extend the queries should be perserved to allow further extension of Keycloak features without need to touch the base store layer, and for that reason the query names should be not predefined.

Thats what we started with as well, but then we realized how cumbersome it is to derive all kinds of queries only based off of which SearchableFields and operators are set. So in order to be able to use the physical layer at all, a query-hint or alias like you suggested would be a godsend for us.

The datastore SPI will remain but please beware it is subject to arbitrary change without deprecation period. Thank you for highlighting the importance for you to contain all areas, #15490 has been introduced to mend this.

Very cool. This would help a lot actually. If you need help for this to make the next major release, we would certainly not hesitate to contribute as well!

One question you maybe overlooked: Do you have a timeline for FileStorage yet? Since map store doesnt support MariaDB anymore, our fallback for everything not in cassandra (static data like realm configuration) is gone.

1 reply

hmlnarik Nov 22, 2022

Very cool. This would help a lot actually. If you need help for this to make the next major release, we would certainly not hesitate to contribute as well!

That would be very nice. Thank you!

One question you maybe overlooked: Do you have a timeline for FileStorage yet? Since map store doesnt support MariaDB anymore, our fallback for everything not in cassandra (static data like realm configuration) is gone.

There is no ETA at this moment, but it is now being worked on. We would like to have at least limited support for realms in for Keycloak 21, but it may be postponed.

Navigation Menu

Repository navigation

MapStore-Feedback and Questions #15470

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 2 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

MapStore-Feedback and Questions #15470

Uh oh!

Uh oh!

dominikschlosser Nov 11, 2022

Replies: 2 comments · 1 reply

Uh oh!

hmlnarik Nov 14, 2022

Uh oh!

dominikschlosser Nov 14, 2022 Author

Uh oh!

hmlnarik Nov 22, 2022

dominikschlosser
Nov 11, 2022

Replies: 2 comments 1 reply

hmlnarik
Nov 14, 2022

dominikschlosser
Nov 14, 2022
Author