prepare for Keycloak internal "organization" support

[lsmith77]

From my reading of https://github.com/keycloak/keycloak/discussions/23948, they are looking at p2 as a proof of concept but they do not intend to care at all to make migration easy.

As such I would suggest to add an (optional) table prefix to namespace all database tables to prevent collissions and to ensure clarity between the two implementations as you already noticed that there is a real risk of overlapping names.

[xgp]

@lsmith77 Thanks for the thoughts.

The Keycloak organization feature will likely differ from ours, despite culling extensively from our feature set, and so I don't think "migration" is relevant. Because of some core feature differences, we're probably not going to create any kind of migration tool, or do anything in the immediate term to interoperate. Their "features" (which apparently they will decide on the fly, rather than from a comprehensive requirements and design process) are supposed to be targeted at "B2B" use cases. I roughly understand what that means, but, again without a feature list to compare, don't really have an idea what how that will manifest in concrete terms.

Our features have always been targeted at Enterprise SaaS companies who have the requirement of allowing each enterprise to have their own Identity Provider, have users who can potentially be members of multiple organizations, and support use cases where it is possible to easily reason authorization across multiple organizations.

We've got a draft of a note about the addition of organization features to Keycloak core and how that will effect our popular extension, but tl;dr, it won't really. We have severl hundred free and paid users who are happy with the mature set of features that have been validated over >3 years. I'll publish that on the README of this repo later this week.

Regarding overlapping database table names, for the immediate term, that is solved by https://github.com/keycloak/keycloak/issues/28246 where they agreed to use ORG_ for their new database tables, which doesn't collide with our tables.

I would suggest to add an (optional) table prefix to namespace all database tables to prevent collissions

Sadly, Liquibase doesn't make it that easy. Unless you are installing from scratch, you can't "migrate" into a different naming scheme without experiencing the collision, since it will run the creates using the previous names. We have an idea to release a major version of the plugin:

1. immediately proceeded by a version that must be run if you are an existing user to change the table names
2. with new table names prefixed something like EXT_PHASETWO_
3. with a from-scratch migration that just creates the most recent state of the tables without all historical changes, using Liquibase preConditions to not create the new table if it is already present.

[lsmith77]

I share your sentiment that at least what they communicate towards the outside is a bit fuzzy and your offering (SaaS) is more inline with theirs (B2B) with what we are trying to achieve in our use case. So we are planning to adopt P2 for sure. Also because P2 is a mature platform. My concern was more about maintaining the ability to use new Keycloak releases.

The migration topic I see more as a thing in 1-2 years when their solution has become more mature. They might then also expand the scope (ie. cover SaaS) or at the very least some core entities could be adopted by P2 (like f.e. the organization entity, even if it needs additional attributes etc).

[xgp]

@lsmith77 We're certainly going to watch what they do and incorporate features as they progress.

I'll close out this issue once I've posted the note to the README.