[keycloak-user] Fwd: Multi-org salesforce with single realm keycloak
Anthony Fryer
anthony.fryer at gmail.com
Mon Jun 13 03:51:59 EDT 2016
I never said anything about how the realm is created (I agree whatever
creates a new customer should create the keycloak realm). I was talking
about how to build a KeycloakConfigResolver that can work with new realms
that it doesn't know about in advance.
On Mon, Jun 13, 2016 at 5:25 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:
> I'm sorry but dynamically creating realms in this way is just crazy IMO.
> You should have whatever provisions new customers also create a realm on
> their behalf.
>
> On 11 June 2016 at 04:15, Anthony Fryer <anthony.fryer at gmail.com> wrote:
>
>> 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...
>>
>> {
>>
>> - realm: "tenantA",
>> - public_key:
>> "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA07H+1raA8G5lU9II9GwQ1r2yXzSeBpEC6Lz822iB+oZGi36KC6caVOyi1IVIWB/ZnxxoC8AHsn4ASYJnYUMNTjRvK9nwHCP825LD3nHFBHyQ0gUHBELRi6ZvmOu3TnyiIlnR2SCxwmND5ifgtDfKwldcdCTNWqJG5MkcOimhDEiZYLOrShH5pCcEkPE5JBj0GDGYs9AcUT8/OrJEvInVAfnMMxvzZfXhJQlXnq0HbkGPNL2LMq66bmfI7OTzWKpIIoa24DOcxvu5FEqnnfhEZ+RkhfrVVe876T7Jx9f128xOTAYgi98515+xeFGei1Qer1IJCtnE5vICKKVtDdJg1wIDAQAB"
>> ,
>> - token-service: "
>> https://keycloak.mydomain.com/auth/realms/tenantA/protocol/openid-connect
>> <https://keycloak.cyberavenue.com.au/auth/realms/tenantA/protocol/openid-connect>
>> ",
>> - account-service: "
>> https://keycloak.mydomain.com/auth/realms/tenantA/account
>> <https://keycloak.cyberavenue.com.au/auth/realms/tenantA/account>",
>> - admin-api: "https://keycloak.mydomain.com/auth/admin
>> <https://keycloak.cyberavenue.com.au/auth/admin>",
>> - tokens-not-before: 0
>>
>> }
>>
>> The KeycloakConfigResolver then uses the "realm" and "public_key" values
>> from that response, overrides the values from the keycloak-template.json
>> file to create the KeycloakDeployment (using KeycloakDeploymentBuilder).
>>
>> If your client isn't public and the client-secret differs and isn't known
>> in advance, then this solution wouldn't work. In that case, another
>> solution can be used which is slightly more complicated. The idea is the
>> KeycloakConfigResolver does the following...
>>
>> 1/ Get a token for the admin-cli client in the "master" realm. This may
>> require configuring a username and password that can be used used to obtain
>> this token.
>> 2/ Use the rest api to get a list of clients in the requested realm (ie.
>> http get to http://<keycloak_url>/auth/admin/realms/{realm}/clients
>> using a Bearer token obtained from step 1
>> 3/ Iterate through the list and find the Client you're interested in (ie.
>> client.getClientId().equals("my-client") ). You need the client UID
>> identifier from this.
>> 4/ Use the rest api to get the keycloak deployment installation file by
>> doing a GET to http://<keycloak_url>/auth/admin/realms/{realm}/clients/{client-uid}/installation/providers/keycloak-oidc-keycloak-json,
>> using the Bearer token from step 1 and the client UID from step 3. Then
>> use KeycloakDeploymentBuilder on the response body returned from this
>> service.
>>
>>
>>
>> Regards,
>>
>> Anthony
>>
>>
>> On 04:43, Sat, 11/06/2016 Jesse Chahal <jessec at stytch.com> wrote:
>>
>>> The keycloak config resolver works well when all realms are known in
>>> 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 at 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 at 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 at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > keycloak-user mailing list
>>> > keycloak-user at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160613/180b930b/attachment-0001.html
More information about the keycloak-user
mailing list