This chapter contains the resources required to govern Phase C of the Salesforce Platform Governance Method. If you’ve been reading this book and using these resources, you’ll know that although we have tried to cover all the major areas relating to this topic, you should always do additional research into the subject matter. The areas covered in this resource base have been meticulously chosen to reflect the method, set you up for success, and help you to govern your project implementation.
You do not need to use this resource base as a strict method or process. The idea is that this will give you a good indication of what you should be taking into consideration. The expectation is that you will use this as a guide and then build upon it as you navigate the Salesforce ecosystem.
Guidelines and Best Practices
This section contains the guidance and best practices that are available from Salesforce, as well as other resources that we have determined will be valuable. This section should serve to provide a good set of guidelines that can be reviewed by anyone delivering the governance function within your organization.
We know there is an infinite number of resources available on the Web, and although some are better than others, this resource base will provide you with a good selection of resources that we recommend you review. As per all the resource base documentation in this book, giving you the complete technical definition for every aspect of identity and access management is not the objective; if we did, the book would be as thick as a medieval wall, which if you didn’t know could be up to five meters thick. The resource base is divided into two main sections: the resources themselves and then related standards, and finally there is a supporting checklist.
As is the case with all the resource base chapters in this book, the links to the resources will be managed in the Salesforce Platform Governance Method GitHub account. The URL for this account is as follows: github.com/salesforceplatformgovernancemethod.
Salesforce Identity & Single Sign-On (SSO)
Single Sign-On Resources
Artifact | GitHub Ref | Description |
|---|---|---|
Salesforce Identity Implementation Guide | Identity Implementation Guide | This resource is where you should focus your initial attention. It answers the questions relating to what identity is and how Salesforce natively provides support for access to resources via SSO. Whether Salesforce is the IdP (Identity Provider) or your solution opts for an external IdP, this resource explains all the key concepts to consider. |
Single Sign-On Reference | Single Sign-On | Review this resource to understand more about the SSO use cases and related terminology for SAML and OpenID Connect–based SSO implementations and FAQs. There is a lot to learn regarding this topic, but these resources are well written and explain the concepts extremely well. |
Understanding More about Authentication | Understanding Authentication | Use this resource to learn more about how you can use the OAuth protocol to access resources without having to expose user access credentials. Salesforce supports numerous authentication flows, some of which are described here. |
SSO Strategy | Choosing an SSO Strategy – SAML vs. OAuth2 | This resource covers the basic principles of both SAML and OAuth. The basic flows are described, and the attributes of both options are discussed in detail. To provide a user with a single sign-on experience, a developer needs to implement an SSO solution, but which one? This resource helps to provide some guidance as well as a comparison between SAML and OAuth2. |
Connected Apps | Connected App | A connected app is used to enable access to your Salesforce application—either API access or by using numerous protocols, such as SAML, OAuth, and OpenID Connect. Review this resource to understand the part a connected app plays and how you can use this platform feature to drive authentication to Salesforce resources. |
Learning Connected Apps with Trailhead | Connected App Trailhead Resources | For additional learning for connected apps, review this Trailhead learning resource. This will provide a good overview of how external applications can integrate with your Salesforce application. |
SSO with SAML | SAML SSO Covers IDP and Service Provider Enablement | SAML (Security Assertion Markup Language) is an open authentication standard that allows IdPs and service providers to securely exchange user information to enable user authentication. This resource explains how you can use SAML in your SSO solution and how to configure it, with example flows. Here you will find resources that cover SAML as the service provider and as the identity provider. In addition, with SAML you can add support for JIT (Just-In-Time) user provisioning, and this resource covers how to achieve this in your solution. |
Using OpenID Connect | Configure an Auth Provider using OpenID Connect | You may want to use a third-party authentication provider that uses OpenID Connect. Once authenticated to Salesforce, users are authorized to access Salesforce-protected resources. If this is your use case, then this resource will provide useful insights on how this can be achieved. |
OAuth Tokens and Scopes | OAuth Tokens and Scopes in Detail | If you intend to use OAuth as part of your authorization flow, you need to get familiar with all the terminology and token definitions used in this resource, how they are used, and what information they must contain. Additionally, this resource defines the OAuth scopes or Salesforce API resources that your application is authorized to access. |
OAuth Flows | OAuth Authorization Flows | If you decide to use OAuth and OpenID Connect as part of your identity solution, there are several different flows that will need to be considered. This resource details each one that could be applicable to your use case. Whether your app is a Web app, mobile app, or a server-to-server integration, all the applicable auth flows are detailed. For server-to-server integration, for example, you will need to create a JSON Web Token (JWT) that’s supplied from one server to another and signed with a trusted certificate. This enables access to a resource without interactively logging in. |
Salesforce Authentication Provider | Configure a Salesforce Authentication Provider | This resource covers the requirement to add a Salesforce authentication provider, which allows users to login to an external web application using their Salesforce credentials. |
SSO FAQs | Single Sign-On FAQs | Review the Salesforce SSO FAQs page for some best practice tips that may prove to be useful as part of your solution design. Things like MFA adoption, testing SSO, and login configuration are all covered in this resource. |
Coding SSO Securely | SSO Secure Coding | If you are a developer, this wiki resource is a must read that will inform on techniques used to protect a user’s session ID (SID, the authentication token that’s akin to a username and password). This resource describes the vulnerability and provides the reader with a set of instructions on how to test and validate if your application is vulnerable. |
Identity Training with Trailhead | Identity Trailhead Learning Resource | This Trailmix provides you with a good overview of Salesforce identity and how to use this feature to give users access to resources. Here you will find learning resources for Salesforce Identity Connect, My Domain, identity for mobile, and user authentication. |
Salesforce My Domain | My Domain | This resource introduces the My Domain feature in Salesforce. My Domain is a feature that allows you to create a subdomain for your Salesforce org, which is essential if you want a URL that reflects your company name. It’s also essential to consider this feature in your design as many Salesforce features depend on this being configured. Plus, with My Domain you can take advantage of branding your login experience, set up authentication providers such as Google or Facebook, and enable custom login policies that determine how users are authenticated. You will need My Domain if you intend to use SSO, so this really cannot be overlooked. |
App Launcher | Configure and Use the App Launcher | The Salesforce App Launcher is what your users will use to switch between applications in your Salesforce environment. This feature is available to all Lightning users by default. However, if your Salesforce environment is on the classic-based UI, then there are some additional things you will need to consider as part of your application design. This resource provides details on how to configure the App Launcher feature for your users. |
SSO for Mobile Apps | Set up SSO and Access for Mobile Apps | This resource covers the configuration required for setting up your mobile applications to work with SSO. This resource section also demonstrates how SSO is integrated with mobile applications with Salesforce identity. |
Login Flows | Salesforce Custom Login Flows | As part of your solution, you may want to direct your users through a login process that’s used to capture end user information or to conduct additional security checks before access to a resource is granted. A good use case for this could be to apply a custom MFA-based solution using TOTP (Time-based One-Time Password). Another example could be to fulfill a requirement for new users to accept service terms and conditions before system access is provided. Use this resource for examples of login flows and how to implement them. |
Multi-factor Authentication | MFA | By now, two-factor authentication, or 2FA, should be widely understood as this is commonplace in most organizations. This is based on a principal of your providing two pieces of information in order to complete the login process, namely something you have and something you know. MFA takes this one step further in that you can increase the number of factors required in the login process to be more than two if required. This resource details what you can achieve with Salesforce; be aware that from February 2022 MFA will become a platform requirement. |
So, how important is identity and access management to the success of your project? The answer to this is quite simple: extremely. This is how you, as the custodian of the keys to your castle (sticking with the medieval theme), define the solution pattern your users and your customers will use to access the application resources. We’re talking specifically about authentication and authorization. In this section we cover the concept of authentication services, SSO (or single sign-on), and other important identity-based services that you will need to know to successfully build and expose your application to your customer base. So, what is identity management in the context of Salesforce? Identity defines how we manage the users in the Salesforce org and how those users connect to the resources and services available to or exposed by an application. SSO is essentially the technology solution that enables users to gain access to the application using a set of credentials that are trusted across multiple services.
The good news is that Salesforce supports SSO natively, and there is a plethora of resources available to you to ensure that you get this designed correctly while adhering to your company’s security standards and policies. SSO provides a convenient authentication model that should be secure, protect your resources, and enable access to your applications and systems where the user is privileged to do so. When designing your application, the auth requirements should be your guide for how the solution needs to be architected. Understanding how Salesforce offers authentication and authorization services will be key to the success of the project. Review the following resources to help guide you through these technologies and understand how the various elements work together.
Phase C Standards
For this chapter, the main message is to consider how you document or define your authentication solution. It might seem obvious, but as part of your governance process, you will be in constant review meetings with various stakeholders going over how the auth process will support the requirements for the project, and there will be many iterations of design that will undoubtedly be discussed.
So how can we make the process of reviewing the approach for auth easier to describe, not just for the internal teams, but also for any third-party provider that has a vested interest. For example, you may be working with an external IdP using OAuth 2.0 and OpenID Connect. In this scenario, you will need to have a clearly defined requirements document that describes exactly how the data interaction will flow from one element to another. One option that we would recommend for bringing your authenticating flow to life is to use a sequence diagram.
A sequence diagram is a great way to model the logic flow of a business process or to illustrate how objects or solution elements interact with each other for a specific use case. In the context of the authentication flow, a sequence diagram is a powerful way to illustrate all the actors in the process and highlight all the interactions and ultimately where certain responsibilities lie. If you use a sequence diagram, there are plenty of tools on the Web that use the UML (Unified Modeling Language), which can be used to easily model your process logic.
Sequence diagram example
In this example, the browser is passing an account ID to Salesforce within an ID token. Salesforce then matches the account ID value to an account in Salesforce and sets a field value that controls whether data can be accessed by an external user. We know that the user in this context is accessing the records via an experience site, as access is granted via a sharing set. Sharing sets are a special sharing mechanism that can be used in Salesforce to grant access to records for external users. Of course, this just an example, but you can see the value of using sequence diagrams as all the steps are clearly defined.
Other standards to consider are the naming standards used in your connected apps. It’s good practice to use names that make it easy to identify the application and project that the connected app is related to. There will be apps in your app manager that are created as part of a managed package, but for applications that are created internally by a project, the connected app name must first be unique in the org, contain the namespace of the project, and be descriptive enough to be clear what the connected app is for. The description field should always be used and give a full description of the connected app’s intended use.
Other naming considerations are as follows. Single-letter names are not acceptable. App names should use CapitalizedCamelCase.
In fact, this is just an example of what is advised in the “Naming Conventions” link in Table 12-1 from the Phase A resource base.
Underscores should not be used for any variable name, object name, class name, or method name except as an application prefix. Overriding standard tabs, objects, and names should not be allowed without first seeking approval from your central governance team.
Good | Bad |
|---|---|
<PROJ_Name> Billing Authentication | BAuth |
<Business_Line> Retail Exp Site | CommunityApp |
Checklists
Governance Step | |
|---|---|
Single Sign-On | Pass / Fail |
Govern that the correct SSO components have been used in the overall application (OAuth, connected app) | |
Govern SSO configuration and components (SAML configuration, MyDomain, Scope Parameter Values, OpenID) | |
Govern any App Launcher changes | |
Govern mobile SSO requests | |
Govern OAuth integrating to an external platform | |
Govern SAML integrating to an external platform | |
Govern any multi-factor authentication requirements | |
Identity Management | Pass/Fail |
Govern any customizations of user authentication (login flows) | |
Govern any changes to user provisioning, syncing, and de-provisioning | |