Securely Implementing Salesforce as a IdP in a Multi-Org Architecture

Written by Aaron Costello is an Offensive Security Engineer at AppOmni

By focusing on streamlining access to applications and services, most enterprises have deployed tooling that allows consolidated login for quicker access to the resources their employees need to accomplish their day-to-day job activities. This seemingly magic process is attributed to Single Sign-On (SSO), however, the star of the show, and the one doing the heavy lifting beneath the hood, is SAML. While not necessarily understood by most, this protocol has weathered the release of alternatives such as OpenID Connect (OIDC) and remains a top contender for a streamlined authentication experience. Apart from centralized user management and an improved user experience, what can SAML offer in terms of security for your organization?

If you are one of the many enterprises that uses this protocol, specifically within Salesforce multi-org architecture, this article is for you. It is focused on providing you clear information and best practices on utilising Salesforce as the single source of truth for identity management and AuthN/Z. It will also provide best practice guidance for securing your authentication flows if you are utilising Salesforce as the single source of truth for identity management in a multi-org architecture.

This article assumes a basic knowledge of SAML and respective key terms. For a quick refresher, Duo provides a concise and clear demystification of the protocol on their site.

Salesforce as an IdP for Multiple Organizations

The approach Salesforce takes to act as an IdP can be seen as a ‘one size fits all’ model. They provide a centralized identity management solution for not only SAML supporting external applications, but also those favouring OAuth2, OpenID, and SCIM. In terms of features, the attraction to Salesforce as an IdP is not without good reason. It provides administrators capabilities for concise app provisioning and robust authorization policy management.

However the question remains as to why an enterprise may want to maintain a multi-org architecture with regards to Salesforce. Consider the following:

• Mergers and acquisitions: The subsidiaries’ operating business model can likely be either ‘Diversification’ or even ‘Replication’. Each one may have independent BUs, different business processes and data, and as such there is a high-level of complexity to integrate them into a single org. For those occasions, and when data is required to be shared cross-org such as records, SalesforceToSalesforce makes this easy.
• Organization limitations prevent the creation of newer processes, incentivizing decentralization and the logical separation over multiple orgs
• There is no need to refactor permission sets, hierarchies, and sharing, which can be difficult to maintain.

Taking this into account, utilizing SAML for this architecture simply makes the most sense. In terms of both user convenience, by minimizing login steps, but also security, in which users will only need to maintain a single password.

By following guidance provided by OASIS security guidelines, secure configuration of a central Salesforce instance for identity management within a multi-org model is possible.

Enabling the Identity Provider

After arriving at the decision to leverage Salesforce as the IdP but prior to implementation, the following steps are recommended. The first step is to decide on the certificate that will be used when communicating with the Service Provider (SP). Salesforce provides a self-signed certificate in ‘Certificate and Key Management’ that can be used for this purpose, or you may import your own.

Certificate and Key Management Vault

SAML’s explicit trust model ensures that even using a self-signed certificate ensures trust , and it only trusts that cert. Utilizing a certificate from a trusted PKI CA for the separation of security responsibility is another approach, albeit more difficult to maintain as the self-signed option supports longer lifetimes. Ultimately this decision should be based on your risk appetite.

Upon completion, navigate to the ‘Identity Provider’ section and enable the feature, specifying your chosen certificate. After doing so, download the certificate and metadata of the IdP which will later be supplied to the SSO enabled orgs.

This now-acting IdP instance has increased responsibility and a higher security risk. Since compromising an account on the IdP can provide a gateway to other orgs that will be connected, proper secure configurations should be implemented. This includes, maintaining strong password policies, ensuring that at a minimum, the default Salesforce policy of 8 characters in length and basic complexity rules are the minimum bar. In addition, the implementation of MFA/2FA for further validation of all users prior to confirming their identity to the application(s) should be required.

Configure the Service Provider

In the SP’s ‘Single Sign-On Settings’, there are two ‘methods’ in which the SP can be configured, delegated authentication (‘DA’) and federated authentication (‘FA’). The former does not utilize SAML, and is simply a web callout that checks the entered username and password with a provided external endpoint. This external web services endpoint will require setup for communication, and should be viewed as increased overhead for administration. For this reason, federated authentication is favored for both security and ease of setup.

However only selecting ‘SAML Enabled’ under FA isn’t always sufficient. ‘Disable login with Salesforce credentials’ should also be selected to ensure users cannot circumvent the SAML auth process by authenticating through standard login. It’s important to note that since no DA gateway URL will be supplied, the DA auth flow will never be used.

Single Sign-On Settings

Once the IDP metadata has been imported, several options may be modified that define both the SAML flow and also the security of the overall authentication process. industry best practice recommendations ensure correct validation and integrity of communication, from beginning to end.

• Request Signing Certificate - The request signing certificate for the initial AuthnRequest will default to your self-signed certificate within the ‘Salesforce Certificate and Key Management’ vault, but another existing certificate may be selected. The purpose of signing the AuthnRequest is so the IdP can confirm the legitimacy of the initial SAML request’s source.

• Request Signature Method - From a security perspective and compliance with the industry standard, RSA-SHA256 should be the chosen algorithm over RSA-SHA1.
• SAML Identity Type - Selecting Federation ID provides a high level of flexibility and easier user management which scales once more SPs are introduced, as not all organizations will follow the same structure for usernames. The ability to map identities effectively across several orgs is a requirement that is satisfied when this option is chosen. Keep in mind that Federated IDs must be assigned by the Administrator, but the ground work is minimal when utilising the Salesforce Data Loader to assign them en masse.
• Assertion Decryption Certificate - The purpose of this field is to be discussed in the next section. For the moment, select a certificate from the vault that will be used to decrypt the SAML response from the IdP.
• Single Logout Enabled - Logging in is the first half of the story, as orphaned logins are continuously threatened by session hijacking attacks. It is highly recommended to enable this option to enforce SP-initiated logout. By doing so, the logout request made to this org is propagated via the IdP to all other orgs serving as an SP that may have been authenticated to by the user, ultimately destroying the session in each. Once enabled, the algorithm selected for the ‘Use Selected Request Signature Method for Single Logout’ option should be kept consistent with that of the initial SP AuthnRequest.

Once the config has been saved, modify the ‘My Domain’ settings to enable ‘Prevent login from https://login.salesforce.com’ and ensure the IdP service is selected as opposed to ‘Login Form’.

My Domain Configuration

Connected App Configuration & Permissions

To ensure that the IdP recognises the SP, a connected app must be created from the ‘Identity Provider Settings’.

SP Connection Settings

SAML is a multi-party system, and part of that system is assuring that both the IdP and SP are in agreement with how they communicate. For a functioning authentication flow when configuring the app, the selected settings should mirror that of the SP where possible. This applies to the ‘Single Logout’, ‘Subject Type’, and ‘Verification of Request Signatures settings’. The Entity ID, ACS URL, and Single Logout field values can be populated with those provided by the SP.

The most important part of the SAML flow is the response, as this contains the Assertion. By default the Assertion is not encrypted due to transportation over HTTPS, providing privacy at the transport layer. The debate over whether or not to encrypt typically relates to scenarios in which the Assertion is passed through intermediate parties, and only orgs with ‘User JIT Provisioning’ enabled may potentially have an Assertion containing actual PII. Taking into account the worst case scenario, in this example the possibility of an inadvertently leaked Assertion, it is advised to encrypt the SAML Response using the corresponding public key of the Assertion Decryption Certificate held by the SP.

After saving the connected application settings, users will now require SSO enablement to take advantage of the service. This is configured from the SP instance. For ease of use, SSO enablement via User Profile is advantageous over the Permission Sets route. Multiple orgs imply a larger quantity of users that currently exist, and modification of an existing profile eases the workload of bulk permission assignment to large groups. Alternatively, the SSO enabled profile can be a modified clone of an existing one, with users being transferred when the organisation is ready to enable SSO. Keep in mind that ‘Is Single Sign-On Enabled’ should not be selected for Salesforce Admins in the event that there is an issue with the SSO configuration, but MFA should be added as an extra measure to secure these accounts.

Summary

As demonstrated, the versatile and highly configurable nature of Salesforce provides a complete SAML solution with all the trimmings for your organizations. But securing the authentication flow is only the first step of scaling security with the complexities that a rapidly growing enterprise introduces. While this article provides a strong basis to work from, the settings and permissions outlined must be monitored and maintained. This can be done either manually or through the use of an SaaS Security Posture Management (SSPM) solution. This set of posture toolings provides continuous insight into not only your authentication flow configurations, but every corner of your Salesforce instance. Hopefully this article sparked a thought for how SaaS can honour your needs and requirements for both usability and the need to safeguard critical data.

About the Author

Aaron Costello is an Offensive Security Engineer at AppOmni, and one of the core members of the Labs function. Prior to trailblazing R&D at AppOmni, Aaron was a triage analyst at HackerOne. He is a passionate evangelist for all things SaaS security; focusing on expanding the detection capabilities of the SSPM solution, pioneering security research in the SaaS space, and paving the way for future additions to the product.