This phase of the Salesforce Platform Governance Method focuses on the identity and access management solution that the project team you are governing intends to put in place for its application.
Overview
Phase C should be governed by team members who understand the security controls available within the Salesforce platform as well as your company’s internal security policies.
As the governing team, you should ensure that the Salesforce platform, first and foremost, is kept secure and that the correct level of access is applied to every end user of the application under governance.
The Salesforce Platform Governance Method: Phase C
“Identity and access management (IAM) is the discipline that enables the right individuals to access the right resources at the right times for the right reasons.
IAM addresses the mission-critical need to ensure appropriate access to resources across increasingly heterogeneous technology environments, and to meet increasingly rigorous compliance requirements. IAM is a crucial undertaking for any enterprise. It is increasingly business-aligned, and it requires business skills, not just technical expertise.
Enterprises that develop mature IAM capabilities can reduce their identity management costs and, more importantly, become significantly more agile in supporting new business initiatives.”
—Gartner1
Authentication vs. Authorization
Authentication | Authorization |
|---|---|
Verifies who the user is | Determines what resources a user can access |
Uses passwords or other information provided by the user | Implemented through settings that are project and/or application specific and maintained at that level |
First step in provided access to an application | Takes place after authentication |
Visible and changeable by the user (for example, change password) | Invisible to the user; they can access what someone has deemed acceptable for them to access |
As Salesforce provides a platform that is designed with the customer in mind, access to your application may not be restricted to just employees. You can allow access to your customers as well as your employees for the right business reasons; for example, a customer portal where they can raise support cases.
The Salesforce platform provides a lot of flexibility when it comes to identity and access management, but it cannot control giving access to the wrong resources at the wrong time for the wrong reasons. That responsibility sits firmly with the project team and the governing team.
A prerequisite to governing the IAM aspects of a project’s Salesforce application is having an initial view of what is acceptable to your organization. This usually takes the form of technical standards and policies that lay out guidance for determining what solution provides the identity solution and what solutions can provide services to users via that identity solution.
If you are an organization that has no identity provider solution, then Salesforce could deliver that for you, in which case you may look to your project team or your company’s security team to define those technical standards and policies, as it is the initial project requiring them.
Single Sign-On
Phase C: identity & access management - single sign-on
“When you set up SSO, you configure one system to trust another to authenticate users, eliminating the need for users to log in to each system separately. The system that authenticates users is called an identity provider. The system that trusts the identity provider for authentication is called the service provider.”
—Salesforce
The role of the governance team is to determine whether the project has adhered to the technical standards and policies for single sign-on defined within your organization. Alternatively, the project may be setting the technical standards and policies for future projects if they are the first of that type within your organization. The governance team should clearly understand what part the Salesforce platform will play in the overall SSO landscape—that of service provider or identity provider (and potentially both in some cases)—and then consider the project’s role within this.
If the project’s application being governed adheres to existing technical standards and policies, the governance team should be aware that the application may require changes to those standards and policies.
For example, a “connected app” may be required that can only support a specific authentication solution. That solution may not be part of the technical standards already defined. This may raise questions regarding the suitability of the “connected app,” but it could be the case that the “connected app” is a legacy application that has not been updated or replaced in line with the current technical standards and policies of your organization. This will more than likely be out of the project’s scope of influence or even desired scope of activity, but nevertheless the team must provide a connected experience for users.
Govern whether the correct SSO components have been used in the overall application (OAuth, connected app).
Governing the use of the correct SSO configuration is very much driven from the perspective of whether Salesforce is the service provider or identity provider.
As the service provider, it will be assumed by your project that an identity provider is already in place within your organization that may offer a supported single sign-on option that uses SAML (Security Assertion Markup Language), OpenID, or the creation of a custom authentication solution.
Using SAML, authenticated users flow from the identity provider into Salesforce. Identity providers such as Microsoft’s Active Directory use SAML. Users continue to use the Salesforce login page, but behind the scenes the Salesforce platform sends the users to the identity provider using a SAML request, which is then responded to by the identity provider with a SAML response containing the SAML assertion that authenticates the user.
Using OpenID, a user would select the appropriate identity provider, such as Facebook, from the options provided to the user from the Salesforce login page. This would redirect the user to the identity provider’s login page. The user would then enter their login credentials into that page, and once authenticated the user would be taken back to the Salesforce platform. Salesforce supports several predefined authentication providers, such as Apple and Google.
The final option is to use Apex to create a custom authentication provider. From a governance perspective, this option would need to be carefully considered as it falls into a few governance phases, such as technical design review and approval, as well as code quality checks.
As the identity provider, Salesforce can authenticate on behalf of third-party service providers by implementing SAML or OpenID. Third-party applications need to be configured as connected apps.
If Salesforce is used as a SAML identity provider for your connected app, the project’s users will log in to the third-party application using their Salesforce credentials. If Salesforce is used as an OpenID identity provider for your connected app, the Salesforce login page will be presented to the users of that third-party app for authentication.
If Salesforce is selected as the identity provider, have you the resources to manage and support the predicted user base and connected apps within your Salesforce resource pool at an operational level?
If Salesforce is selected as a service provider, have you the resources to manage and support the predicated user base within your operational identity management team and considered any Just-in-Time (JIT) requirements?
Have you automated as much as possible to allow your user base to “self-serve” for basic identity management issues, such as forgotten passwords?
Have all parties been involved and agreed upon the solution regarding authentication across multiple applications?
The project should provide evidence that service provider–initiated SSO is working.
The project should provide evidence of successful SSO implantation on desktop before attempted on mobile.
The project should clearly communicate your MyDomain URL to users and provide clear instructions.
The project should consider any impacts of IP restrictions.
The project should have considered the look and feel of the login page when using SAML.
The project should consider the data that is passed in the OpenID token, as this could contain sensitive information that pertains to the user. You do not want this information to be accessible, so content (key–value pairs) and connection security will be a critical factor.
Govern SSO configuration and components (SAML configuration, MyDomain, Scope Parameter Values, OpenID).
Once the project’s single sign-on requirements are understood and governed, the governance team can review in more detail how the project configures each SSO component.
If Salesforce is the service provider, the project will need to work with the identity provider to gain access to the SAML information and assertion parameters. This information will include an authentication certificate and the SAML assertion parameters.
Some identity providers offer the SAML setting via an XML file or URL pointing to the file.
The project may also need to implement its own Just-in-Time provisioning, which will automatically create a corresponding user within the Salesforce platform for the authenticated user. This is required because Salesforce will need to reference a record in the User object with which to associate permissions, sharing, and ownership, among several other things. As the governance team, you will need to understand the parameters being sent within the SAML assertion from which the users will be created.
Just-in-Time provisioning can be used to perform the same function for your project’s customer and partner bases if the project is to support a customer and/or partner portal of some kind. Your governance team will need to focus on the gaps in what the user-creation process delivers versus what is really required to provision a user within the Salesforce platform. Additional permission sets and other user-level configuration may need to be carefully considered.
If Salesforce is the identity provider, the project will need to configure the connected apps for each of the third-party applications or service providers where Salesforce is used for authentication.
Before Salesforce is configured as the identity provider, MyDomain should be configured. MyDomain uses Salesforce domain suffixes such as company.salesforce.com for Salesforce orgs’ URLs. This domain affects all applications within the Salesforce org; as such, the governance team should review this implementation with the view that all projects within the organization are affected. While the impact of the change may have no effect whatsoever on some projects, it is something that is org-wide.
Changes to MyDomain will interrupt your Salesforce users briefly, so the governance team should review the schedule for this change with the project team to make sure that this change is done at a convenient time for all applications and users on the Salesforce platform.
The governance team may offer guidance as part of the security policy of your organization regarding the use of certificates. As the identity provider, Salesforce will need a certificate, either self-signed or provided by your certificate authority. Typically, the use of self-signed certificates is reserved for sandboxes, while your certificate authority is used for your production org.
Finally, as the governing team, you will need to review the scope parameter values to determine if the correct scope is being used. This could be important in terms of the data you are looking to gain access to from your identity provider.
Govern any App Launcher changes.
App Launcher provides a convenient landing page that offers your users the applications they have access to. Users will only see the applications that they are authorized to see based on their profile and permission sets.
Changes to the App Launcher should be reviewed by your governance team so that users are not surprised by any changes made. Communications may be required to prepare your users for upcoming changes. This should include connected apps that they will gain access to and any they will lose access to.
Govern mobile SSO requests.
The Salesforce mobile application will only work with service provider–initiated setups.
Salesforce recommends that single sign-on servers support TLS 1.2.
SAML configuration needs to be added within the Authentication Configuration section of MyDomain.
As with all Salesforce org-wide configurations introduced by a single project, the governance team will need to explore the provisions being made over the lifespan of the application being deployed and then any ongoing change impacts for future application deployments. Additionally, once Salesforce has been integrated into an identity provider, any changes to that identity provider will need to consider the Salesforce platform(s) that it serves.
Govern OAuth integrating to an external platform.
Your governance team will need to have a thorough understanding of the OAuth capabilities of the Salesforce platform. OAuth can be used for several inbound and outbound integrations with external platforms.
Integration Authentication
Direction | Configuration | Code | |
|---|---|---|---|
HTTP Callouts | Outbound | Named credential | Apex |
Authentication via OpenID Connect | Outbound | Connected app, authentication provider | Registration handler for authentication provider |
Mobile App, Web App, Smart Devices, Middleware | Inbound | Connected app | None |
Salesforce supports the following flows for OAuth authentication:
Web Server Flow for Web App Integration
User-Agent Flow for Desktop or Mobile App Integration
Refresh Token Flow for Renewed Sessions
JWT Bearer Flow for Server-to-Server Integration
OpenID Connect Dynamic Client Registration for External API Gateways
Device Flow for IoT Integration
Asset Token Flow
Username–Password Flow for Special Scenarios
SAML Bearer Assertion Flow for Previously Authorized Apps
SAML Assertion Flow for Accessing Web Services API
Your governance team will need to identify any potential vulnerabilities as well as adhere to your organization’s security policies and technical standards. For example, your organization may not permit username–password integrations.
Govern SAML integrating to an external platform.
SAML can be used to provide your users with automatic authentication into your Canvas apps. SAML is an XML-based standard for user authentication on the Web.
The governance team will need to take a deep look into the implementation of any Canvas and Mobile SDK usage.
Govern any multi-factor authentication requirements.
Multi-factor authentication (MFA) is a solution to increase protection for user accounts. When enabled, MFA requires a user to provide two or more pieces of evidence that they are who they say they are. In most cases, two pieces of evidence or factors are used.
Traditionally, two-factor authentications were based on a factor the user knows and a factor the user owns. The factor the user knows was typically a password, and the factor the user owns was typically a token device that would provide a series of numbers that the user would type in when prompted. These numbers would change every sixty seconds.
Salesforce, as of February 2022, will enforce the use of multi-factor authentication, deeming it a necessary tool in creating a platform of trust.
What solution will be rolled out to users to support multi-factor authentication? There are many options, such as the Salesforce Authenticator app or the Google Authenticator app. Some are free to use (such as the Salesforce and Google solutions), while others may have financial implications.
If a user forgets or loses their device that has the authenticator app installed, how will the user gain access? What operational solutions will be in place to facilitate this? Are your Salesforce administrators prepared for this additional workload?
Identity Management
As shown in Figure 4-3, identity management is the second sub-phase on which your governance team should focus.
Phase C: identity & access management – identity management
The Salesforce platform overcomes the requirement to create a user account for every user that logs in with single sign-on (SSO) with a solution called Just-in-Time (JIT) provisioning.
JIT provisioning works with your identity provider to pass user information to Salesforce so that when a new user logs in via SSO, the JIT provisioning method automatically creates their account.
Without the use of JIT provisioning, your Salesforce administrators would need to create each user manually.
Govern any changes to user provisioning, syncing, and de-provisioning.
Your governance team will need to look at the project’s requirements for changing the way users are provisioned on the Salesforce platform. This will include the de-provisioning of a user.
As users come and go from an organization, and given that Salesforce is an internet-based SaaS (Software as a Service) platform, it is important that you have not only a streamlined user provisioning solution, but also a streamlined de-provisioning solution.
When a user leaves your organization, it is imperative that their access to your systems is revoked. This is even more important for platforms such as Salesforce that are accessible from anywhere in the world (albeit other configurations could restrict this; for example, with the use of SSO). Your governance team will need to review the processes that your project is going to employ to support this, as well as any third-party products. Additionally, active users on the Salesforce platform where no actual user is present pose the risk of data’s being inadvertently allocated to that user.
Your governance team may also need to review how a user’s permissions are set. Some complex user provisioning solutions can be taken into account; for example, when using Active Directory, the groups the user belongs to can drive the permissions the user is provided on the Salesforce platform. Any such solutions should be governed, with your governance team playing a part in building your organization’s maturity in this area.
Method
Single Sign-On
Identity Management
Approach
This phase is focused on the identity and access management aspects of the application. These will form part of the technical standards and policies, but it is possible for an application to seek changes to these. For example, a connected app (external to Salesforce) may be required that can only support a specific authentication solution that is not part of the technical standards. This may raise questions regarding the suitability of the connected app, but it could be a case where the legacy application has not been replaced or updated in line with the current technical standards and policies.
Where a core org (or number of them) has been used the standards for SSO should be well defined, but it is possible for an application to specify a dedicated org where requirements dictate the need; for example, where sensitive data resides. In this case, this phase will focus on the adherence to standards for the new org.
More likely, the application being governed will be looking to use external platforms and to modify any App Launcher configurations, especially where an organization has implemented the App Launcher as the standard home page for a user and has multiple orgs in which the applications can reside. The App Launcher configuration may be a centralized task; however, this will be governed in exactly the same way as any other application/configuration change.
It is envisaged that the majority of this phase can be automated with the correct tooling, as specific configurations can be checked against the standards using static source code analysis. However, there may be a need for a subjective review, especially regarding connected apps where the configuration can be checked automatically but the requirement cannot.
Inputs
Application configuration and source (or the repository, in the instance of using a source control system) where appropriate
Custom settings used or created
Steps
The steps to govern the identity and access management phase will help the project team understand how users will authenticate with the Salesforce platform on which their application resides as well as the lifecycle that needs to be considered. The governance team should look to gain confidence that the identity and access management proposal works across the entire organization.
Single Sign-On
- 1.
Govern whether the correct SSO components have been used in the overall application (OAuth, Connected App, etc.).
- 2.
Govern SSO configuration and components (SAML configuration, MyDomain, Scope Parameter Values, OpenID).
- 3.
Govern any App Launcher changes.
- 4.
Govern mobile SSO requests.
- 5.
Govern OAuth’s integrating to an external platform.
- 6.
Govern SAML’s integrating to an external platform.
Identity Management
- 1.
Govern any changes to user provisioning, syncing, and de-provisioning.
Outputs
Not Applicable – Project team has no intention of utilizing platform feature.
Remediate – The governance team requests that the project remediates its design to accommodate the issues raised during the governance review.
Pass – The input provided has passed this governance phase.
Review – The input cannot be objectively measured and therefore a subjective view has been made, which will lead to a discussion with the development team to reach consensus. Although undesirable, this could be a consequence of unclear standards and policies.
Scenario
Govern whether the correct SSO components have been used in the overall application (OAuth, Connected App, etc.).
Govern any App Launcher changes.
Returning to our fictitious company, Bright Sound Guitars Ltd., you may recall Hanna, the project’s architect. Hanna wants to introduce single sign-on for the users of the application she and her team are building. Hanna wants her users to only sign in once, and then have access to several services that she intends to leverage that are already in place at Bright Sound.
The most notable of these services is access to the stock system used at Bright Sound. Hanna introduced the stock system during her application architecture review, where she needed to create an interface between Salesforce and the stock system. However, since then her thinking has matured in the use of the stock system and she feels that for some users, it will be useful to log in to both the Salesforce platform and the stock system with the same credentials.
Bright Sound Guitars single sign-on architecture
Hanna explains that Salesforce will become the identity provider at Bright Sound Guitars, as they currently do not have one. Every system that a user requires access to needs a separate set of credentials for that user. Hanna explains that this is leading to a lot of effort for the system administrators who are helping users with login issues.
Hanna highlights that her project will configure the Salesforce platform as the identity provider. Then, she will configure a connected app for the stock system so that users will simply log in once to Salesforce and will be trusted by the connected app.
Hanna then goes on to explain that she will add the stock system into the App Launcher configuration of the Salesforce platform and make that the home page for each of her users. This way, each user will see the application they have access to whether they are part of the Salesforce platform or not.
Hanna explains that the stock system used at Bright Sound Guitars accepts identity using SAML, so this should be straightforward to configure.
They mention that Hanna’s team will need to review IP enforcement, which they know is in place for the Salesforce platform. Hanna didn’t realize that IP enforcement was in place, so must look at how this might affect the connected app.
The governance team also mentions that they like the idea of using the App Launcher, as it’s a convenient way of providing users with access to the systems they can use. However, the governance team raises a concern that not everyone at Bright Sound Guitars uses the Salesforce platform, and therefore not everyone would benefit from this feature, leaving several users accessing systems as they do today. Hanna responds with the idea that perhaps she could find a way to provide all users at Bright Sound access to Salesforce.
Summary
Phase C looks at identity and access management, with a view of simplifying life for your users by integrating the Salesforce platform into your organization’s identity management solution or becoming that solution. Typically, identity and access management are driven by security policy, where your organization may have views on what is acceptable in terms of systems trusted by other systems. In the main, however, single sign-on is widely accepted in today’s enterprises.