Thursday, April 14, 2016

Setting up single sign on (SSO) with Okta and Salesforce Community


Consider this: you have a salesforce instance (sales or service cloud) where single sign on (SSO) was already setup. Later when you create a community, you want to reuse the same SSO configuration done in Salesforce without having to create a multiple SAML configurations in Salesforce.

Unfortunately, salesforce documentation isn't very clear on how to do this when you already have SSO setup for the main instance. Hopefully these steps will help.

I had done this integration with Okta and Salesforce, so the steps below reference Okta as the Identity Provider (IdP). But the overall process should be the same


  1. Your main instance (sales / service cloud) is already configured with SSO
  2. You have a few users setup with Community profiles/permissions in Salesforce
  3. install the SAML Tracer plugin in Firefox. You'll need this to help debug if there are any issues later

Step 1 : Prepare information for your IdP

In Okta, you'll need to create a new application integration with Salesforce for the community. You cannot use the existing Okta configured application for this. There is no way around this - while there will be a single SSO configuration in Salesforce, Okta will have two - one for the main Salesforce ServiceCloud and the other for the Community Cloud.

You'll need to provide information from your existing SSO setup in Salesforce. 

In Salesforce, Go to Setup-> Security Controls->Single Sign-On Settings

Okta needs the following values from your Salesforce instance
  • For the Okta Single Sign On URL & Recipient URL & Destination URL settings : provide your Community URL appended with the saml parameter from current instance. More on how to create this is below
  • For the Audience Restriction or Entity ID : Use the entity parameter from your Salesforce Single Sign On settings. Normally this is

Other settings for Okta
  • Name ID Format :     Unspecified
  • Response :     Signed
  • Assertion Signature :    Unsigned
  • Assertion Encryption :     Unencrypted
  • SAML Issuer ID: Use the issuer parameter from your Salesforce Single Sign On settings

1a: generate the community SSO URL

The first part of the SSO URL will be either of the following
  • In production it will be the community domain you have setup with /login/ appended at the end – say,
  • In sandboxes, it will be the community site URL with /login/ appended at the end – You can find the community site URL by going to Setup->Develop->Sites.
NOTE: The Site URL will show as http in the Salesforce Sites page (screenshot above), but you'll have to provide the https link.

The second part of the SSO URL will be the saml parameter from your existing SSO configuration in Salesforce
  • Go to Setup-> Security Controls->Single Sign-On Settings
  • Copy the saml= part of the Salesforce Login URL. This is what needs to be appended to the Community Login URL

Finally you'll get a URL which looks like this

Provide this to Okta as the Single Sign On URL

Step 2: Create the new application in Okta and add users to the new application in Okta

This step is done in Okta and will not be covered here. It's anyway specific to the IdP you choose.

Step 3: Test

Test the new SSO by going to the Okta Dashboard and logging in as one of the users assigned the application and clicking on the new application tile. Okta should drop you into the Community without having to relogin

Step N : Debug

This one is marked Step N since you'll be doing this multiple times :)

  1. In case there are issues, open up firefox and open the SAML Tracer extension
  2. Run through the login scenario and capture the SAML request. SAML Tracer helpfully marks this with a big SAML indicator on the right of the capture window
  3. copy the SAML post sent from the browser to SFDC and run it through the SAML Validator provided by SFDC. To use the SAML validator, go to Setup-> Security Controls->Single Sign-On Settings and Click on SAML Assertion Validator button.
  4. Paste in the SAML text and click validate
  5. The SAML Validator will provide a list of failures in red. 
    • First look if the identity is being passed correctly in the SAML assertion to Salesforce from the IdP
    • Next check if Salesforce could read the certificate passed from the IdP - this should not be an issue since the existing SSO configuration in Salesforce is being reused, so the certificates should already be installed in Salesforce



  1. Hi, Could you please add steps to setup Okta application for community? Because, when we are creating new Okta application it is generating new Issuer Id, I'm not sure how it is being related to the SSO setup we already did?

    1. Unfortunately, I moved to a different project and don't have access to the Okta instance anymore. Your best bet would be to work with Okta support.