Allow adding realm users as an organization member

[pedroigor]

Closes #29023

• Enables use cases where existing realm users should be added as members of an organization
• Introduces the concept of managed/unmanaged organization members so that we can manage member accounts according to the relationship between their identities and the organizations they belong to. For instance, existing realm users and their identities are not bound to a specific organization but the realm. On the other hand, members federated from the identity provider associated with an organization have their identities, and their lifecycle, strongly coupled with the organization.
• Make sure the kc.org attribute set to users can not change if not managed through the Organization API
• It is now possible to have a username other than the email where validations related to the organization (e.g.: email domain matching the organization domain) only happens when validating the email attribute.
• Members not managed by the organization can use any email domain and authenticate using their credentials as per the realm's policies.
• The Organization API no longer creates or updates users as we are now introducing the possibility of linking existing users to an organization.
• Removing organization members now takes into account whether they are managed or not by the organization they are associated with so that managed members have their account completely removed from the realm. On the other hand, users whose identities do not depend on the organization are not removed from the realm but only their link to the organization.

[vramik]

Thank you @pedroigor for the PR. LGTM, I've just two minor comments.

[martin-kanis]

What if the user is not a local user i.e user imported from LDAP or a custom user federation? (id in f:uuid:uuid format) Do we want to allow the user to become a member?

[pedroigor]

Isn't this handled by UserStorageManager? I don't see any reason why don't allow any realm user to become a member.

[vramik]

@martin-kanis please correct me if I am wrong ... I believe the question or concern might come from a fact that there is no control over those users who are not local keycloak users, so any update to those users (such as messing up with kc.org attribute) might be done outside of Keycloak.

Would there be needed some mechanism to prevent/detect this kind of outside updates?

[pedroigor]

For LDAP, we can do that as attributes like this one are very likely to be managed through a mapper. For custom providers, it will depend on how they are managing the user attributes.

Federated users (from custom providers) have their attributes stored in a specific table in Keycloak. I think we can handle such cases as well.

We can discuss this in a follow-up if you guys want as this PR is blocking others to go in. It is a very valid point and we need to see how to deal with custom user storages.

[sguilhen]

Yep, a mapper would probably be in place for cases like this if we are to propagate the persistence of the org attribute to LDAP. But the question still remains - if an admin changes the org in LDAP, how are we going to handle that? Will we need to validate these changes when re-importing/validating the user?

[pedroigor]

If we don't allow creating a mapper to kc.org we don't need to worry about this, I would say.

The real problem, I would say, is with custom user providers because they have access to internals and can easily bypass user profile or any other validation we enforce elsewhere.

[alice-wondered]

outside of existing comments this all LGTM

[vramik]

@pedroigor For me the PR looks good, thank you. The only remaining thing is resolving @martin-kanis's comment. As far as I'm concerned we can address it as a follow-up (which I would prefer to be created prior merging this one), but leaving it for @martin-kanis as he started the discussion.

[pedroigor]

@vramik @martin-kanis Anything else blocking you from finishing reviewing and approving?

[martin-kanis]

@pedroigor For me the PR looks good, thank you. The only remaining thing is resolving @martin-kanis's comment. As far as I'm concerned we can address it as a follow-up (which I would prefer to be created prior merging this one), but leaving it for @martin-kanis as he started the discussion.

Follow-up created #29080

[pedroigor]

Follow-up created #29080

Thanks. Please, let me know if you want to change anything else so we can move forward.

[martin-kanis]

LGTM, thanks!

[mhajas]

Approving based on reviews from @vramik @martin-kanis and @sguilhen