Tag: portals

Single-Sign-On between multiple Salesforce Communities with custom domains on same Salesforce org

For a customer I was looking into Single-Sign-On (SSO) between multiple Salesforce Communities using a custom domain for each. Consider a customer with two communities (Community 1 at comm1.example.com and Community 2 at comm2.example.com) – these could be different customer communities, a customer community and a partner community etc. The issue we encountered was that when using custom domains (i.e. comm1.example.com and comm2.example.com) the built in session ID cookie support will not suffice as the cookie will be bound to the exact domain. This means the cookie is not sent along when accessing the second community and hence no SSO.

Now the solution to all this is using SAML with is baked into the Salesforce platform and included in the license. There is a bit more stuff to configure with SAML but once set up you get SSO for non-Salesforce Community properties as well such as a property on Heroku as well.

All in all I think it’s worth the additional configuration.

Before I list what I configured let me say that it may feel a bit convoluted as the Salesforce org is both the Identity Provider (IdP) and the Service Provider (SP) in SAML-speak. Usually Salesforce is either the one or the other but but not both.

Please note: Below I assume a certain level of knowledge about Salesforce Communities around controlling access to communities using Profiles, activating Communities and mapping to custom domains. All is well documented in the documentation but understand you cannot simply do the below steps and be done…

What I ended up configuring was the following:

  1. A community (“SSO”) used for Single-Sign-On and self-service (password reset etc.) where I style and brand the SSO experience at sso.example.com. The community has a CA signed SSL certificate and a custom domain setup via the Domains setup.
  2. A community (“Community 1”) for customers at comm1.example.com. The community has a CA signed SSL certificate and a custom domain setup via the Domains setup.
  3. A community (“Community 2”) for customers at comm2.example.com. The community has a CA signed SSL certificate and a custom domain setup via the Domains setup.
  4. A Customer Community profile with the SSO community as the default community. This profile I use to control access to the communities in Members.
  5. I next configured the Salesforce as an Identity Provider using a self-signed certificate. This will allow the org to act as an IdP in a SAML authentication flow.
  6. Next I created 2 Single-Sign-On configurations (under “Single-Sign-On Settings” in Setup). One for comm1.example.com and one for comm2.example.com with separate, unique, entity IDs and mapping each to the appropriate community as the only login configuration under Workspaces/Administration/Login & Registration. I used “Federation ID” for the SAML Identity Type. Ensure you use the SAML configuration from the SSO community.
  7. Next configure the SSO community to only use “Username & Password” under Workspaces/Administration/Login & Registration. This ensures the customers actually are able to login using their Salesforce credentials.
  8. Under “App Manager” in Setup create a Connected App for each community configuring SAML and using the appropriate entity ID remembering to also set these to use Federation ID.
  9. Allow the community user profile to use the Connected Apps (both of them) and ensure user records have a federation ID set.

The result is that I can access all 3 communities on my custom domains. Accessing sso.example.com simply allows me to logon with username and password and do self-service incl. password reset etc. Accessing either comm1.example.com or comm2.example.com will redirect me to sso.example.com for authentication if not authenticated already. If already authenticated to sso.example.com it will simply bounce me via that and authenticate the user to the community transparently.

YMMV!