SSO: Enable Multiple Configs - considerations

Question

In our Salesforce Org, our internal users sign on via Single Sign On in our Identity Provider, Okta. We are looking use Okta for our partner community users as well, and to do so, we need to add a separate connector to Salesforce.

It appears that I will need to enable multiple SAML configurations to do so. This is an irrevocable action, and I want to, first, make sure that this is necessary, and second, make sure that this does not break anything before moving forward. I receive the following message:

• Once you enable this feature, you can't disable it.
• You will not be able to use SAML 1.1 once this feature is enabled.
• Audience will berequired in all SAML Responses.
• Your existing single sign-on configuration will be converted, and you will be able to create multiple SAML 2.0 configurations for your organization.
• A new Self-Signed Certificate will be created and used to sign SAML Requests.
• Your Salesforce Login URL will change from https://login.salesforce.com to https://mycompany.my.salesforce.com?so=00D40000000XXXX. This may cause users to be unable to log in using SAML.
• SAML Responses that can't be parsed will no longer result in login history for your organization. Please ensure your Identity Provider generates valid SAML Responses using the SAML Validator.

Will this be a necessity to enable SSO for the partner community? We do need to have separate connectors because we are using a partner login feature in Okta. If so, then when it says the Salesforce Login URL will change, will that affect logins from other sources (From web browser, connected apps, etc.)? I want to make sure that once the connector is updated with the new certificate and URL, no configuration or integrations outside of our IDP will need to be changed.

Answer 1

Based on the details I was able to gather from the comments, here's a bit of explanation on this.

1. Your org is configured prior to Summer '13 and that's the reason you are getting that button. For orgs later than Summer '13, this option does not even exist (and I can say that based on all my experiences around previous versions of Salesforce, definitely not anything prior to 2015). Refer to this excerpt from the documentation:

   If you don’t see the Assertion Decryption Certificate field you need to enable multiple single sign-on for your organization. (Applies to orgs created before the Summer ’13 release that aren’t using SAML 1.1)

2. As for your question:

   Will this be a necessity to enable SSO for the partner community?

   You don't need to enable or utilize another SSO configuration just for using it with Partner community. You can just use the same SSO configuration that you have currently if your IdP remains the same, which does look like it will be still Okta. What you only need here is to make sure that the SAML assertion being sent for the Community has the correct URL in it. Refer to the below excerpt from the documentation (I can confirm this as I have had a very recent experience around this use case):

   When implementing SAML for communities, the key is to use the community URL associated with login for the single sign-on flow. Also make sure that the community URL in the SAML assertion POST includes /login

3. As for your other question around the message that you get if you attempt to Enable multiple configs.

   If so, then when it says the Salesforce Login URL will change, will that affect logins from other sources (From web browser, connected apps, etc.)?

   While I don't have any experience around the message itself, but based on your comments, as you already have My Domain enabled which is kind of a pre-requisite for SSO, so you definitely don't have to worry about that piece assuming your SSO works on the My Domain enabled URL. As long as you are not restricting the login from login.salesforce.com, you are still good to use that URL even if My Domain is enabled. And that, this restriction is applicable only for UI flows, API integrations always work fine.

   Also, you mentioned that you are already using SAML 2.0 for SSO, so the message which mentions SAML 1.1 is irrelevant in that case too.

---

With how it stands right now, below is my recommendation:

1. Identify if you really need to configure another SSO configuration. If you intend to use the same IdP and utilize that for Community, you can still use the same configuration with the changes in SAML assertion as mentioned above
2. If at all you need to enable multiple configs, then make sure you first test this out in a Sandbox before making any changes in Production. That way you make sure your existing SSO does not break.