3:43 a.m.
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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user