Access Salesforce Data through SSO¶
While Salesforce documentation covers some aspects of this authentication flow, Skuid requires a few more options be configured to authenticate to a Salesforce org as a data source using the SAML 2.0 OAuth flow.
Note
This tutorial does not show how to use Salesforce as an IDP. Instead, it shows to connect Skuid, Salesforce as a data source, and a separate IDP, meaning end users will not see an OAuth popup when accessing Salesforce data.
1. Generate a certificate used for identity certification¶
- Navigate to Administer > Security Controls > Certificate and Key Management in the Salesforce sidebar.
- Click Create Self-Signed Certificate.
- You may alternatively Create a CA-Signed Certificate. See the section below for more information.
- Fill out the Label field with an appropriate name for your needs.
- The auto-generated values and defaults for your other fields will be fine, so click Save.
Click Download Certificate.
On CA-signed certificates [[]]¶
To create a CA-signed certificate, you must click Create a CA-Signed Certificate, fill out the certificate information, adn then click Download Certificate Signing Request.
You must send this downloaded Certificate Signing Request (it will be a .csr file) to a Certificate Authority (Verisign, Comodo, etc.). The CA will then sign your certificate using their root certificates, and provide you with the Certificate (.crt file).
You must then return to the original certificate record in Skuid or Salesforce and click Upload CA-Signed Certificate. Select the fully-signed certificate provided to you by your CA.
2. Configure your data source and your IdP for SSO authentication¶
To access a Salesforce org’s data using this flow, ensure that the Salesforce org you are accessing is configured to accept SSO logins from your IdP. To do so, you’ll need to:
- Configure an identity provider connection for your IdP within the Salesforce org you are connecting to.
- Set up an correlating SSO connection within your IdP.
The examples below use Okta as the IdP in question (with the same configuration outlined :dosc_url::in this tutorial <skuid/single-sign-on/saml-example-idp-okta.html>). To properly configure these SSO settings in Salesforce and Okta, see the Okta document, How to Configure SAML 2.0 for Salesforce.
Note
If you have your Okta metadata file, you may also use that to streamline the Salesforce configuration process using the New from Metadata File button.
After saving your Salesforce identity provider connection, you’ll see its details. There is an important field to note here:
- Issuer: Use this field as the issuer within your Salesforce connected app, even if you’re on Skuid SFX. This field essentially verifies to Salesforce that this org allows access to its data using SAML.
After noting the issuer field, follow the steps listed How to Configure SAML 2.0 for Salesforce to create your Salesforce application within Okta as well.
After you’ve properly configured both Salesforce and Okta for single sign-on to your org—and with your certificate at the ready—you’ll have all you’ll need to properly configure a connected app that brings all these services together.
3. Creating an OAuth app connection within your data source¶
Similar to the process for accessing multiple Salesforce orgs using the Salesforce data source type, you must create a connected app to obtain OAuth credentials for your data source. But in addition to those settings, you’ll configure some SAML-specific options.
The values entered in during this process are very important. You’ll need to enter the Issuer field from the Salesforce single sign-on configuration from the previous step. Additionally, you’ll need to set the appropriate service provider entity ID and ACS URL.
By placing all of these values in the appropriate fields within the Salesforce connected app, you’ll connect all of the links to authenticate and facilitate data transfer.
If you haven’t done so, create a Salesforce connected app for Skuid as outlined in Setting up a Salesforce connected app for Skuid.
Return to your list of connected apps (Build > Create > Apps in the Salesforce sidebar).
Click Edit beside your connected app.
Configure your settings as follows:
- API (Enable OAuth Settings)
- Check Use digital signatures.
- Click Choose File.
- Upload the certificate file you downloaded in 1. Generate a certificate used for identity certification.
- Web App Settings
- Check Enable SAML.
- Entity ID: Use your My Domain URL, e.g. if your My Domain is “acme”, use https://acme.my.salesforce.com/
ACS URL: Append /services/oauth2/token to your My Domain URL
e.g.
https://acme-dev-ed.my.salesforce.com/
would use https://acme-dev-ed.my.salesforce.com /services/oauth2/token
- API (Enable OAuth Settings)
- Subject Type: Username
- Issuer: Enter the Issuer field from the Salesforce identity provider connection you created above.
- Navigate to Settings > Single Sign-on.
- Use the value from Issuer field for the IdP your end users will be logging in from.
- IdP Certificate: Default IdP Certificate
- Verify Request Signatures and Encrypt SAML Response are advanced, optional fields. For more information about their configuration, see Salesforce’s Create a Connected App documentation.
- Click Save.
- Click Continue on the confirmation page to return to your connected app’s page.
- Click Manage.
- Click Edit Policies.
- Configure your settings as follows:
- OAuth policies
- Permitted Users: Admin approved users are pre-authorized
- Define who has authorization through profiles and permission sets within Salesforce.
- IP Relaxation: (Optional) Relax IP restrictions
- Try this setting if you are having issues with authentication.
- Refresh Token Policy: Refresh token is valid until revoked
- Enables end users to employ the token they receive without expiration.
- Permitted Users: Admin approved users are pre-authorized
- Check Enable User Provisioning if you wish to provision users, which will require some additional configuration outside the scope of this topic.
- OAuth policies
- Click Save.
Assign the connected app to users¶
Use permissions sets to assign the connected app to any end users that will be accessing data within this Salesforce org. Even if a user can access Salesforce via your IdP, they will not be able to access data if they are not assigned the connected app.
With all data source and identity provider connections complete, the final steps of this process take place entirely within Skuid.
4. Configure a Skuid authentication provider and data source¶
In this final section, you’ll be configuring two key things:
- An authentication provider that uses the consumer key and consumer secret provided by your Salesforce connected app.
- A data source that points to the configured authentication provider and provides an identifier to your data source.
First, create a Skuid authentication provider to authenticate—using the OAuth credentials from your app connection—to your data source using the SAML protocol.
Navigate to Settings > Data Sources > Authentication Provider.
Click New Authentication Provider.
Fill out the field as follows:
- Name: Enter an appropriate name for your authentication provider, such as <Your Data Source>SAML.
- Authentication Method: OAuth 2.0 / OpenID
- Provider Type: Salesforce
- Grant Type: SAML 2.0 Bearer Assertion
- Token Endpoint URL: Fill in your My Domain in the appropriate area.
- Assertion Signing Certificate: Enter the unique name of the certificate you created on Salesforce in the first section.
- Client ID: Enter the consumer key of the Salesforce connected app.
- Client Secret: Enter the enter the consumer secret of the Salesforce connected app.
Click Save.
After this, create a Skuid data source that uses the above authentication provider. Within that data source, also configure a name identifier—a field that must correlate with a user record on the external data source being accessed, such as a username or email address.
- Navigate to Settings > Data Sources.
- Click New Data Source.
- Select Salesforce for your Data Source Type.
- Enter an appropriate name for your authentication provider, such as <Your Data Source>SAML.
- Click Next Step.
- Configure any data source specific options.
- Click Next Step.
- Select the authentication provider you previously configured.
- Click Save new Data Source.
After creating this new data source, you’ll need to configure some final settings to properly send a username to the external data source you are connecting to. If you do not see the settings listed below, refresh your page.
- Click Advanced Settings for the newly created data source.
- Ensure that the Authentication Method is still set for the previously configured authentication provider.
- Beside Name Identifier Field, enter a value that will correlate to the name identifier of the org you are connected to. Select an option appropriate for your use case:
- Email: Use this option to send the email of the current user as the identifier in the assertion.
- Federation Identifier: Use this option to send the federation identifier of the current user as the identifier in the assertion.
- Username: Use this option to send the username of the current user as the identifier in the assertion.
- Result of a Formula: If the identifier does not directly correlate with the above values, you can enter a formula using some text transformation functions and merge syntax here. The following functions are available:
- LOWER(): Will return the parameter in entirely lowercase letters.
- UPPER(): Will return the parameter in entirely uppercase letters.
- FIRST(): Will return the first letter of its parameter.
- LAST(): Will return the last letter of its parameter.
- An example formula with a function and merge syntax: LOWER({{$User.FirstName}}) && “@example.com”
- Save the data source configuration.
Make sure that the Name Identifier Field is set to match the username schema of the org you are connecting to. (Since Salesforce usernames can be complex, you will most likely need to use a Result of a Formula.)
And with that, you’ve successfully configured both Skuid and your Salesforce org for SSO data source authentication.
To see it in action, use this new data source for a Skuid model, set a component to use that model, and preview the Skuid page. Your data should display as it normally would—without any OAuth popup or logging in when visiting the Skuid page.
Anticlimactic? Perhaps, but you’ve made the runtime experience that much easier for your end users.
Troubleshooting¶
Invalid_client or object Object errors appear when selecting the object for a Salesforce model.There is an issue with the credentials within your IdP matching up with your Salesforce credentials—this can happen due to certificate mismatches or unset permissions.
- The most likely culprit is the certificate settings. Ensure that you are using the correct certificate in your Salesforce connected app and your identity provider connection:
- Navigate to Administer > Security Controls > Single Sign-On Settings in the Salesforce sidebar.
- Click Edit beside your identity provider connection.
- Ensure that the Request Signing Certificate is the same one uploaded to your Salesforce connected app.
- You should also check that the Assertion Signing Certificate for your authentication provider matches the label of the certificate you have chosen.
- In Skuid, navigate to Settings > Data Sources > Authentication Providers.
- Click Details on your authentication provider.
- Check that the Assertion Signing Certificate matches your certificate’s label.
- Check that the connected app you created has been assigned to any end user attempting to login via permission sets or profile permissions.
The getaddrinfo ENOTFOUND error appears when selecting the object for a Salesforce model.
- Your My Domain within your Skuid authentication provider may not be correct. Ensure that you have the right My Domain value entered, and that there are no extra characters, such as periods.
A 400: Bad Request error appears when selecting the object for a Salesforce model.
- You may not be logged into Skuid via SAML. To use this flow you must log into Salesforce using your IdP. If you login using the standard login screen—and not through your IDP, you will not be able to access data sources using this flow.