You can implement a dynamic keycloak config resolver that can work with realms not known in advance. I've just been doing exactly the same thing. My requirement was to use the host name to identify a realm, so tenanta.mydomain.com/my-client would use realm "tenanta",tenantb.mydomain.com/my-client would use "tenantb" etc and realms could be created dynamically and my-client would immediately work with those new realms without requiring a reboot or re-configuration. There are different KeycloakConfigResolver implementations you can use to do this, depending on your client configuration.
If the client is configured as public (no client secret) or if the client secret for the application is the same in each realm, then you can use a keycloak template for configuration. So you could deploy a WEB-INF/keycloak-template.json file which looks something like this...
{"realm": "tenantA", "realm-public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA07H+1raA8G5lU9II9GwQ1r2yXzSeBpEC6Lz822iB+oZGi36KC6caVOyi1IVIWB/ZnxxoC8AHsn4ASYJnYUMNTjRvK9nwHCP825LD3nHFBHyQ0gUHBELRi6ZvmOu3TnyiIlnR2SCxwmND5ifgtDfKwldcdCTNWqJG5MkcOimhDEiZYLOrShH5pCcEkPE5JBj0GDGYs9AcUT8/OrJEvInVAfnMMxvzZfXhJQlXnq0HbkGPNL2LMq66bmfI7OTzWKpIIoa24DOcxvu5FEqnnfhEZ+RkhfrVVe876T7Jx9f128xOTAYgi98515+xeFGei1Qer1IJCtnE5vICKKVtDdJg1wIDAQAB", "auth-server-url": "https://keycloak.mydomain.com/auth", "ssl-required": "none", "resource": "my-client", "public-client": true }The KeycloakConfigResolver would use this template for each realm and just overwrite the "realm" and "realm-public-key" values with the real values. To get those real values, the KeycloakConfigResolver would first work out the realm name. In my case, I derive the realm name from the hostname, so tenanta.mydomain.com would indicate "tenanta" was being used. Once you have derived the realm name, then you can do a http get request to http://<keycloak_url>/auth/realms/<tenantname> (eg. https://keycloak.mydomain.com/auth/realms/tenanta). This endpoint isn't secured and returns something similar to the following...{}
advance. I was trying to imply in my diagram that all realms are not
known in advance as realms are going to be created for new customers
on demand. Doing a new production deployment whenever a SaaS product
has a new customer added is not a feasible solution.
On Wed, Jun 8, 2016 at 7:01 PM, Anthony Fryer <anthony.fryer@gmail.com> wrote:
> Why do you say "very hard to get App1 to support multiple realms (no adapter
> or keycloak support)"?
>
> Keycloak does provide multi-tenancy support via the KeycloakConfigResolver.
> See https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant.
>
> The issue would be if your app can't use a keycloak adapter.
>
> On Thu, Jun 9, 2016 at 10:05 AM, Jesse Chahal <jessec@stytch.com> wrote:
>>
>> Hi,
>>
>> I'm back again. I'm trying to figure out how scale Identity Providers.
>> We are planning on trying to integrate our App1 with salesforce. A
>> user who logs into salesforce should be able to have a native feel of
>> our App1 within it. Todo this we'll probably have to end up building
>> salesforce native apps. For every salesforce organization/licensee we
>> will have to register an Identity provider with keycloak to make sure
>> they can correctly use App1. Some configuration options we came up
>> with are listed below. Has anyone else solved a similar problem?
>>
>> OPTION 1
>> ########################################################
>> # Keycloak
>> #
>> # ---> master realm
>> #
>> # ---> realm 1
>> #
>> # --- ---> app1_client (open ID)
>> #
>> # --- ---> salesforce_org1_saml2.0_identity_provider
>> #
>> # --- ---> salesforce_org2_saml2.0_identity_provider
>> #
>> #
>> #
>> # Salesforce
>> #
>> # ---> org1
>> #
>> # ---- ----> salesforce_appX (uses App1)
>> #
>> # ---> org 2
>> #
>> # ---- ----> salesforce_appX (uses App1)
>> #
>> # ---- ----> salesforce_appY (uses App1)
>> #
>> # .....
>> #
>> #
>> #
>> # App 1
>> #
>> # ---> OpenID to realm1 (using adapter)
>> #
>> ########################################################
>> benefits
>> - single login page
>> - single realm
>> cons
>> - login page with infinite number of identity provider buttons present
>>
>>
>> OPTION 2
>> ########################################################
>> # Keycloak
>> #
>> # ---> master realm
>> #
>> # ---> realm 1
>> #
>> # --- ---> app1_client (open ID)
>> #
>> # --- ---> salesforce_org1_saml2.0_identity_provider
>> #
>> # ---> realm 2
>> #
>> # --- ---> app1_client (open ID)
>> #
>> # --- ---> salesforce_org2_saml2.0_identity_provider
>> #
>> #
>> #
>> # Salesforce
>> #
>> # ---> org1
>> #
>> # ---- ----> salesforce_appX (uses App1)
>> #
>> # ---> org 2
>> #
>> # ---- ----> salesforce_appX (uses App1)
>> #
>> # ---- ----> salesforce_appY (uses App1)
>> #
>> # .....
>> #
>> #
>> #
>> # App 1
>> #
>> # ---> OpenID to realm1, realm2, realm#.... (using adapter)
>> #
>> ########################################################
>> benefits
>> - single salesforce button per login page
>> - users are more isolated in single realm
>> cons
>> - very hard to get App1 to support multiple realms (no adapter or
>> keycloak support)
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user