3

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.

|improve this question
  • Trying to understand a bit here. 1. Where are you trying to setup multiple SSO configurations - Okta or Salesforce? 2. Do you have any existing SSO configuration in your Salesforce (seems not) 3. Where do you get these messages as you have mentioned in your post? – Jayant Das Aug 30 '18 at 21:56
  • Currently, Okta is configured as our IDP for our Salesforce internal users. We are looking to enable a separate connector for our Partner Community users. Because of our setup in Okta, we are required to use two separate connectors, which means different certificates. The information from Okta (certificate, etc) is currently stored under "Single Sign On Settings" in Salesforce. There is an button on that page called "Enable Multiple Configs" which gives us the messages I have referenced. – SFDC Neuf Aug 30 '18 at 22:03
  • Is your sandbox provisioned prior to Summer '13? I haven't really come across this button and thus curious. Also as you said you already have a SSO configured, is that using SAML 2.0? And I will assume that you also have My Domain enabled? – Jayant Das Aug 30 '18 at 22:13
  • Our org was provisioned before Summer '13, we have My Domain enabled, and we are using SAML 2.0. – SFDC Neuf Aug 30 '18 at 22:26
  • 1
    Well this button in fact is not available for newer orgs. So as I understand, you already have a SSO configuration and that you cannot add a new one until you enable the multiple config? Is that correct? Now because you already have My Domain, so your existing SSO configuration definitely uses the custom domain URL. And if you can only add a new SSO configuration after enabling multiple configs, I would think, you can ignore those warnings as those seem to be pretty generic. The best route here will be to test this out in a sandbox before doing anything on Production. – Jayant Das Aug 30 '18 at 22:59
2
+100

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.
|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.