feature: Add support for tenant-specific identity providers

[anarsultanov]

This PR enhances the extension's functionality by integrating it with Identity Providers (IDPs) , enabling a smooth user onboarding and authentication process with external IDPs across different tenants, by introducing the concept of tenant-specific IDPs.

1. Tenant-Specific IDP Configuration:

• To enable tenant-specific configuration for IDPs, tenants' IDs should be added to the multi-tenancy.tenants configuration attribute of the IDP as comma separated list. This can be accomplished using the standard Keycloak REST API.
• With tenant-specific IDP configuration, IDP restricts access to only tenants listed in the configuration. If a user signing in with IDP isn't a member of any of these tenants and automatic membership creation isn't configured, an error will be generated.

2. Automatic Tenant Membership Creation:

• By including the create tenant membership authenticator in the IDP's first login flow, users can be automatically added as members of all the configured tenants during their initial login.
• Alternatively, this authenticator can be added into post login flow allowing memberships to be created even for tenants added to the IDP after the user has already been onboarded.

3. Public IDP Configuration:

• IDPs lacking the multi-tenancy.tenants configuration attribute are considered public.
• These public IDPs grant access to any tenants for users who are members of those tenants.
• This ensures compatibility with existing setups, as it doesn't disrupt the way things were previously configured.

[anarsultanov]

@oleaasbo I'd appreciate if you could take a look at this PR and tell me if it meets your needs.

[oleaasbo]

Great work as always! I have not had the chance to test this out yet, but I believe it might not completely align with my use case for IDP tenants. Nevertheless, I definitely see the potential for Tenant-Specific IDPs, and I think this will be a valuable addition to the extension.

For my particular use case, I am envisioning a more universal implementation rather than one that is highly specific. I would like to suggest the addition of a tenant IDP option, which would differ from the tenant-specific IDP by allowing users to log in with any IDP tenant without being required to be on a pre-approved list of tenants. In my application, tenants have the ability to share access to resources with other tenants. Updating the list of allowed tenants within Keycloak every time there is a need to share resources seems a bit excessive. If I need to restrict tenant access to my application, I can manage this directly within Entra ID by implementing a "Tenant Restriction Policy." For IDPs without this feature, the tenant-specific IDP implementation that you've introduced would be very useful.

Regarding automatic tenant membership creation, I am not convinced of its necessity in this context. Please correct me if I am mistaken, but I understand that tenant memberships are used to manage a user's roles in relation to the tenant they have logged in with. This is essential for utilizing the keycloak-multi-tenancy API. However, I would like to propose restricting access to this API when users log in with an IDP tenant, as the IDP's API should be the source of truth for tenant memberships and user roles in these scenarios. Requiring IT personnel to manage tenant memberships and roles in both the IDP and Keycloak could create unnecessary overhead, especially for enterprise organizations. Ideally, once IT personnel remove a user’s membership within the IDP platform, the user should no longer be able to log in or be associated with that tenant.

What is your thoughts on this?

[anarsultanov]

Thank you for the feedback, @oleaasbo!

For my particular use case, I am envisioning a more universal implementation rather than one that is highly specific. I would like to suggest the addition of a tenant IDP option, which would differ from the tenant-specific IDP by allowing users to log in with any IDP tenant without being required to be on a pre-approved list of tenants.

I think we can address this use case by introducing an additional configuration attribute for the IDP, such as multi-tenancy.access, with possible values like TENANTS and ALL. This way, it will be possible to configure the IDP to allow access to all tenants or restrict it to specific tenant lists, providing more flexibility in accommodating various scenarios.

Regarding automatic tenant membership creation, I am not convinced of its necessity in this context. Please correct me if I am mistaken, but I understand that tenant memberships are used to manage a user's roles in relation to the tenant they have logged in with. This is essential for utilizing the keycloak-multi-tenancy API.

The main purpose of memberships is to establish the connection between the user and the tenant, which is a crucial part of the multi-tenancy system. While the role defined in the membership is essential for utilizing the keycloak-multi-tenancy API, the one assigned by default doesn't grant any administrative privileges and can be easily ignored by your application in favor of other claims that can be added by a separate mapper.

Requiring IT personnel to manage tenant memberships and roles in both the IDP and Keycloak could create unnecessary overhead, especially for enterprise organizations. Ideally, once IT personnel remove a user’s membership within the IDP platform, the user should no longer be able to log in or be associated with that tenant.

I understand your concern about the potential overhead of managing memberships and roles in both the IDP and Keycloak, but it's important to note that when a user logs in using an IDP, a local user is typically created in Keycloak. If this user is removed from the IDP, they might lose access to the IDP tenant, but their local copy and associated resources would still remain in the system and need to be removed from Keycloak separately. As far as I know, this should usually be solved by using SCIM, but I’m not sure that Keylock supports it.

Additionally, not creating a membership in Keycloak would contradict your previous request, since it would make it impossible to enter the IDP tenant through Keycloak when using credentials or another IDP, as Keycloak would have no knowledge of the user's association with an IDP tenant.

[anarsultanov]

@oleaasbo I'm merging the PR, but please feel free to further comment in it or create a separate issue explaining your use cases in more detail.