[keycloak-user] Fwd: Multi-org salesforce with single realm keycloak
Stian Thorgersen
sthorger at redhat.com
Mon Jun 13 03:25:21 EDT 2016
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/3133eb2b/attachment-0001.html
More information about the keycloak-user
mailing list