Note: Nintex Apps data centers are located in West US and Australia (AUS). In-region processing of Nintex Apps data is only available in these regions.
Access Salesforce Data through SSO
While Salesforce documentation covers some aspects of this authentication flow, Nintex Apps requires a few more options be configured to authenticate to a Salesforce org as a connection using the SAML 2.0 OAuth flow.
Note: This tutorial does not show how to use Salesforce as an IDP. , it shows to connect Nintex Apps, Salesforce as a connection, 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 Settings > Certificates.
- From here you may download Nintex Apps's default certificate, or generate a unique self-signed or CA-signed certificate.
- To download the default certificate:
- Click the drop down arrow beside Create Self-Signed Certificate.
- Click Download Default Certificate.
- To generate your own certificate:
- Click Create Self-Signed Certificate.
- Fill out the Certificate Name field with an appropriate name for your needs.
- Choose whether the certificate's Key Size should be 2048 or 4096 bits.
- Click Save.
- Click View Certificate Details.
- Click Download.
- To download the default certificate:
If you choose to generate and use a self-signed certificate for your connection's OAuth app connection, you must select this certificate within your identity provider connection:
- Navigate to Settings > Single Sign-on.
- Click the identity provider connection.
- Select the appropriate certificate in the Request Signing Certificate field.
2. Configure your connection 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 in this tutorial) 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 Nintex Apps. 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 connection
Similar to the process for accessing multiple Salesforce orgs using the Salesforce connector, you must create a connected app to obtain OAuth credentials for your connection. 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 Nintex Apps as outlined in Setting up a Salesforce connected app.
-
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: Retrieve this value from your identity provider connection:
- Navigate to Settings > Single Sign-on.
- Click the identity provider connection (or click More Options > Configure ).
- Use the value from the Audience URI / Service Provider Entity ID / Metadata URL field.
- ACS URL: Retrieve this value from your identity provider connection:
- Navigate to Settings > Single Sign-on.
- Click the identity provider connection (or click More Options > Configure ).
- Use the value from the Assertion Consumer Service (ACS) URL field.
- 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 connection and identity provider connections complete, the final steps of this process take place entirely within Nintex Apps.
4. Configure a Nintex Apps authentication provider and connection
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 connection that points to the configured authentication provider and provides an identifier to your connection.
First, create a Nintex Apps authentication provider to authenticate—using the OAuth credentials from your app connection—to your connection using the SAML protocol.
-
Navigate to Settings > Connections > Authentication Provider.
-
Click New Authentication Provider.
-
Fill out the field as follows:
- Name: Enter an appropriate name for your authentication provider, such as <Your Connection>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.
- Signing Certificate: Select the certificate you created on Salesforce in the first section.
-
Click Save.
After this, create a Nintex Apps connection that uses the above authentication provider. Within that connection, also configure a name identifier—a field that must correlate with a user record on the external connection being accessed, such as a username or email address.
- Navigate to Settings > Connections.
- Click New Connection.
- Select Salesforce for your Connector.
- Enter an appropriate name for your authentication provider, such as <Your Connection>SAML.
- Click Next Step.
- Configure any connection specific options.
- Click Next Step.
- Select the authentication provider you previously configured.
- Click Save new Connection.
After creating this new connection, you'll need to configure some final settings to properly send a username to the external connection you are connecting to. If you do not see the settings listed below, refresh your page.
- Click Advanced Settings for the newly created connection.
- 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 connection 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 Nintex Apps and your Salesforce org for SSO connection authentication.
To see it in action, use this new connection for a Nintex Apps model, set a component to use that model, and preview the Nintex Apps page. Your data should display as it normally would—without any OAuth popup or logging in when visiting the Nintex Apps 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 Settings > Single Sign-on.
- Click the identity provider connection.
- Ensure that Request Signing Certificate is the same one uploaded to your Salesforce connected app.
- 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 Nintex Apps 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 Nintex Apps via SAML. To use this flow you must log into Nintex Apps using your IdP. If you login using the standard login screen—and not through your IDP or the Login with SAML option in Nintex Apps, you will not be able to access connections using this flow.