Identity and Access Management
Identity and Access Management provides you with an upgraded version of the Multi-Factor Authentication Assistant, which includes a step that helps you preview multi-factor authentication (MFA) during your evaluation period. Other improvements include updates to OAuth 2.0 flows and connected app access to Customer Data Platform (CDP) ingest API services. And you can secure email address updates by requiring password resets. Customer 360 Identity provides extra customer protection with secure Embedded Login redirects and verification of email address updates. We‘re deprecating Identity Connect 2.1 and Identity Connect 3.0.1.2. You can upgrade to Identity Connect 7 when it’s released later this spring. In the Winter ‘22 release, Salesforce is increasing the length of one-time passwords to improve security.
- Manage Your Customer Identities in a Central Location with Salesforce Customer Identity Plus
Salesforce Customer Identity Plus brings together the power of Salesforce and Auth0’s identity-as-a-service SaaS to deliver our latest consumer identity and access management (CIAM) solution. With Customer Identity Plus, connect to all of your customers, apps, and products by managing customer identities centrally for Commerce Cloud, Sales Cloud, and third-party applications. Customer Identity Plus makes identity configuration easy through simple clicks and SDKs that can seamlessly integrate an identity layer into existing applications. And if you want customization capabilities, Customer Identity Plus gives you full control over design and authentication flows. - Get More Guidance from the Multi-Factor Authentication Assistant
The Multi-Factor Authentication Assistant now includes a step that helps you preview multi-factor authentication (MFA) during your evaluation period. While you’re getting ready to roll out MFA for Salesforce, we recommend turning it on for a few of your Salesforce champions. Conducting a preview or pilot with some trusted users lets you test the rollout process and collect early feedback on the MFA user experience. Use these insights to ensure there are no gaps in your rollout or change management plans. You can also determine the kinds of onboarding materials your users need when you’re ready to launch MFA more broadly. - Get Assigned Scopes with Access Tokens in the OAuth 2.0 JWT Bearer Flow
With the OAuth 2.0 JWT bearer flow, for connected apps that are preauthorized, standard and custom scopes are automatically returned with an access token. Previously, only standard scopes or scopes issued with former access tokens were returned. - Improve Performance Times of the OAuth 2.0 Hybrid App Flows
Improve performance times of the OAuth 2.0 hybrid app flows by directly bridging an access token into a web session without using frontdoor.jsp. With the hybrid app token flow, a hybrid app sets the domains’ associated SIDs in the session cookies. It then directly bridges its own web session. During the hybrid refresh token flow, when a new access token is granted, the hybrid app receives updated domain SIDs. It can directly reset the session cookies and avoid interruptions. - Give Authorized Access to Salesforce CDP Ingestion API Data
To authorize a connected app to access Salesforce CDP Ingestion API data, assign it the new OAuth scope: Access and manage your Salesforce CDP Ingestion API data. Customers can use the associated external app to upload and maintain external data sets in the Salesforce CDP platform. - Redirect Expired Tabs to a Custom Logout URL
For Salesforce sessions, you can now redirect all expired tabs in your browser to a custom logout URL. Previously, the redirect URL wasn’t applied to all expired tabs. Instead, only one tab was being redirected correctly, and the other tabs were redirected to Salesforce.com. - Require Password Changes for Email Address Updates
You can now require a user to change passwords before an admin-initiated email address update is approved. To quickly update your users' email addresses, you can change email addresses without requiring a password reset. But, for better security, you can require users to change their passwords before email address updates are approved. - Require Verification When Experience Cloud Users, Partners, and Customers Change Their Email Address (Update, Enforced)
To protect user accounts against security threats, Salesforce now requires Experience Cloud users, partners, and customers to verify their email address changes. This update, first available in Winter ’21, was scheduled for auto-enforcement in Spring ’21, but was postponed to and is enforced in Summer ’21. - Block Customer Redirects to Unknown URLs
Protect your customers with a new Embedded Login setting that blocks redirects to unknown URLs. After customers successfully log in to your Experience Cloud site with Embedded Login, they’re redirected to URLs that are located in the same host or domain as the site or that are allow-listed. - Identity Connect 2.1 and Identity Connect 3.0.1.2 Are Being Deprecated
As of the Winter ’22 release, we’re deprecating Identity Connect 2.1 and Identity Connect 3.0.1.2, and you can no longer download these versions of the product. We recommend that you upgrade to Identity Connect 7 when it becomes available. - One-Time Passwords Are Getting Longer in Winter ’22
In Winter ’22, to improve security, Salesforce is increasing the length of one-time passwords (OTPs) used for identity verification from five digits to six digits. If you have customizations that rely on six-digit OTPs, such as custom Apex implementations for multi-factor authentication (MFA) or passwordless login, change them before the Winter ’22 release.
Security and Identity
Preview Multi-Factor Authentication Assistant behavior before you deploy it. URL redirects and OAuth 2.0 flows are more secure and efficient. You can now update users’ email addresses more easily and securely. HTTPS is required for Salesforce domains, and enhanced domains meet browser security requirements. Encrypt the User Email field (beta). Learn more about API version use with the new API Total Usage event type. Security Center now integrates with Threat Detection (beta). For sites, improve page load times with caching and update guest user licenses.
https://help.salesforce.com/s/articleView?id=release-notes.rn_security.htm&release=232&type=5
Convert the Read Only Standard Profile to a Custom Profile (Update, Enforced)
This update converts the Read Only standard profile to a custom profile, which allows you to edit permissions in this profile as your business needs require. This update was first available in Spring ’21 and is enforced in Summer ’21.
Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
When: This update was first available in Spring ’21 and is enforced in Summer ’21. To get the major release upgrade date for your instance, go to Trust Status, search for your instance, and click the maintenance tab.
Why: The Read Only standard profile allowed assigned users to view setup, run and export reports, and to view, but not edit, other records. As Salesforce products and offerings expanded, permissions that grant implicit or explicit edit access were added to this profile to allow Salesforce features to function.
To let you customize the Read Only profile to fit your risk tolerance and definition of read only, this update converts the Read Only standard profile to a custom profile. After this update is enforced, you can edit the Read Only custom profile to remove or add permissions as your business needs require. You can also rename the profile, for example, to reflect what it permits or who it’s assigned to.
As part of this change, Essentials editions can create up to two custom profiles and Professional editions can create up to three custom profiles. The converted custom Read Only profile counts towards this limit.
How: Before this update is enforced, review the permissions included in the Read Only profile. Evaluate whether you want the users assigned to the Read Only profile to continue to have the included permissions. You can see a full list of included permissions in the knowledge article, Read Only Profile Conversion to Custom Profile.
After you review the permissions, decide whether to reassign your users to a new profile or to use the existing Read Only profile without reassigning your users. If you continue to use the existing Read Only profile, update your custom code to reference the correct name of the Read Only standard profile after it’s converted to make sure that your configurations and deployments remain intact.
To review this update, from Setup, in the Quick Find box, enter Release Updates, then select Release Updates. For Convert the Read Only Standard Profile to a Custom Profile, follow the testing and activation steps.
New Salesforce orgs created in Spring ’21 and later don’t have the Read Only profile. We recommend that you start with the Minimum Access standard profile as a least-privilege profile base, and assign custom permission sets to grant this user the Read access required by your business needs.
Enable Permission Set Group Assignments with Expiration Dates (Beta) Option
Enable Permission Set Group Assignments with Expiration Dates (beta) to use an updated user interface that includes an assignment expiration option. The option appears on the User Management Settings page in Setup.
Where: This change applies to Lightning Experience and Salesforce Classic in Essentials, Contact Manager, Professional, Group, Enterprise, Performance, Unlimited, Developer, and Database.com editions.
Set Expirations for Assignments on Permissions in Permission Sets and Permission Set Groups (Beta)
When assigning users to a permission set or permission set group, select expiration dates that you specify. Control when a user's permissions expire based on your business requirements.
Where: This change applies to Lightning Experience and Salesforce Classic in Essentials, Contact Manager, Professional, Group, Enterprise, Performance, Unlimited, Developer, and Database.com editions.
Why: Suppose a sales manager needs consultants to evaluate language used in sales contracts. You give the consultants access to the Contracts object and other permissions via a permission set group so that they can perform their work. The project has an end date, so you don’t want contractors to access sales contracts after that date. Set the expiration date and time zone for the permission set group when you assign it to users.
How: You can set an expiration date for a permission set or permission set group using the API.
To use the user interface with assignment expiration options for permission set groups, enable Permission Set Group Assignments with Expiration Dates (Beta) in User Management Settings. Then, when you assign users to a permission set group, select the expiration options that you want. You can also select no expiration date as an option.
Profiles and Permissions
Working with permissions keeps getting better and more flexible with user assignments that expire. And the Read Only standard profile is converted to a custom profile now.
Control Access to Sensitive Data with Restriction Rules (Beta)
Secure your data and boost productivity by permitting your users to see only the records necessary for their job function. Create restriction rules to control which subset of records you allow specified groups of users to see. Restriction rules are available for custom objects, contracts, tasks, and events. You can create and manage restriction rules via the Tooling and Metadata APIs. They provide another layer of access control on top of your existing sharing settings and let you configure truly private visibility.
Where: This change applies to Lightning Experience in Enterprise, Performance, Unlimited, and Developer editions.
When: The timeline for the rollout of this feature is published in the Restriction Rules group in the Trailblazer Community.
Why: Without restriction rules, users with access to an account can see its contracts, tasks, and events, even when the organization-wide default is set to Private. For custom objects, users can see all detail records. Restriction rules let you configure truly private access for these objects.
How: For information on enabling this feature, contact Salesforce. You can create and modify restriction rules using the Tooling or Metadata API. See the Restriction Rules Developer Guide (Beta) for more information.
Share Records Owned by High-Volume Users with Unauthenticated Guest Users
Select whether to include records owned by high-volume community or site users when you create guest user sharing rules. By default, guest user sharing rules include only records that match the rule’s criteria and are owned by authenticated users, guest users, and queues. Because of recent security improvements, this setting is the only way to grant guest users access to records owned by high-volume users. This option isn’t available for owner-based or criteria-based sharing rules.
Where: This change applies to all Aura, LWR, and Visualforce sites accessed through Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.
See Record Access Reasons in Lightning Experience
A user has access to a record, but why? Is it because of their role? Their territory? From a sharing rule? Now you can see why a user has the access they do, right from Record Sharing Hierarchy in Lightning Experience. Previously, you switched to Salesforce Classic to see this information. Sharing Hierarchy is now available on the action menu, not just in the Share window.
Where: This change applies to Lightning Experience in Professional, Enterprise, Performance, Unlimited, and Developer editions
How: Select Sharing Hierarchy from the action menu on the record. Click View next to a user’s name. You see the record access the user has, and the reason for the access in the displayed table.
Sharing
See why a user has access to a record in Lightning Experience, and choose whether to include records owned by high-volume community or site users in guest user sharing rules.