Update documentation for removal of the map store
Signed-off-by: Alexander Schwartz <aschwart@redhat.com> Closes #24092
This commit is contained in:
parent
71b6757c2f
commit
1b12fe132b
3 changed files with 12 additions and 8 deletions
|
@ -60,3 +60,9 @@ If you find any issues or have any improvements in mind, you are welcome to cre
|
|||
ideally with the label `area/user-profile`. It is also recommended to check the link:{upgradingguide_link}[{upgradingguide_name}] with the migration changes for this
|
||||
release for some additional informations related to the migration.
|
||||
|
||||
= Removal of the Map Store
|
||||
|
||||
The Map Store has been an experimental feature in previous releases.
|
||||
Starting with this release, it is removed and users should continue to use the current JPA store.
|
||||
See the migration guide for details.
|
||||
|
||||
|
|
|
@ -1,12 +1,6 @@
|
|||
[[_user-storage-spi]]
|
||||
== User Storage SPI
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
This functionality depends on APIs bundled in the `keycloak-model-legacy` and `keycloak-model-legacy-private` modules.
|
||||
It will soon be replaced with the new map storage API which provides a uniform way to access both local and external information about users and other entities, and the old APIs will be removed eventually.
|
||||
====
|
||||
|
||||
You can use the User Storage SPI to write extensions to {project_name} to connect to external user databases and credential stores. The built-in LDAP and ActiveDirectory support is an implementation of this SPI in action. Out of the box, {project_name} uses its local database to create, update, and look up users and validate credentials. Often though, organizations have existing external proprietary user databases that they cannot migrate to {project_name}'s data model. For those situations, application developers can write implementations of the User Storage SPI to bridge the external user store and the internal user object model that {project_name} uses to log in users and manage them.
|
||||
|
||||
When the {project_name} runtime needs to look up a user, such as when a user is logging in, it performs a number of steps to locate the user. It first looks to see if the user is in the user cache; if the user is found it uses that in-memory representation. Then it looks for the user within the {project_name} local database. If the user is not found, it then loops through User Storage SPI provider implementations to perform the user query until one of them returns the user the runtime is looking for. The provider queries the external user store for the user and maps the external data representation of the user to {project_name}'s user metamodel.
|
||||
|
|
|
@ -154,6 +154,10 @@ some user profile classes and some validator related classes (but not builtin va
|
|||
`keycloak-server-spi` module. However, the packages for java classes remain the same. You might be affected in some corner cases, such as when you
|
||||
are overriding the built-in implementation with your own `UserProfileProvider` implementation However, note that `UserProfileProvider` is an unsupported SPI.
|
||||
|
||||
= Removal of the `storage` configuration setting
|
||||
= Removal of the Map Store
|
||||
|
||||
Since this release, it is no longer possible to use `--storage` related CLI options due to the announced discontinuation of the Map Store.
|
||||
The Map Store has been an experimental feature in previous releases.
|
||||
Starting with this release, it is removed and users should continue to use the current JPA store.
|
||||
|
||||
Since this release, it is no longer possible to use `--storage` related CLI options.
|
||||
The modules `keycloak-model-map*` have been removed.
|
Loading…
Reference in a new issue