Digital transformation is driving teams of all shapes and sizes to modernize their applications and move to the cloud in order to prepare for the next wave of growth and change. This megatrend leads to accelerated adoption of both public cloud and hybrid solutions, creating challenges for IT leaders looking to connect an ever-increasing number of systems together in a secure manner.
Salesforce-based applications play a key role here, as enterprises build customer-centric automated workflows powered by the #1 CRM platform. We’re excited to move this forward by expanding our connectivity capabilities with a new generation of named credentials that give developers greater extensibility and security for HTTP-based integrations.
Named Credentials 101
If you’re not familiar with Named Credentials, think of it as a subsystem that handles HTTP callouts with built-in support for popular authentication protocols needed to make those callouts successfully. System administrators can create credentials with a point-and-click UI, and developers can reference them with a syntax resembling a variable or merge field. This keeps secret values out of your source code and allows endpoints and authentication details to be updated without changing the code itself.
Named Credentials has been a part of the Salesforce Platform for many years, helping developers save time with tricky protocols like OAuth that have a number of different moving parts. It also makes web service integrations available to no-code administrators by enabling callouts through External Services and Flow. As technology has evolved, certain patterns have emerged around these use cases, prompting us to make a number of improvements that we are excited to share with you.
What’s new
In the Winter ‘23 release, we’ve added the following capabilities to Named Credentials:
- Custom headers: Define arbitrary name/value pairs (e.g., API keys) passed along with the HTTP callout as headers
- Permission Set assignment: Grant users explicit access to make callouts using a specified set of credentials by linking it to a permission set
- Temporary access and role assumption for Amazon IAM: Use Amazon STS to assume an IAM role for temporary access to resources hosted on AWS
- Reuse across endpoints: Reuse credentials across different API endpoints protected by the same authentication system (e.g., Google Drive and Google Calendar)
- Support for custom setup UIs: ISVs and other development teams can use a new Connect API in Apex to build custom setup UIs to improve the user experience for administrators
This is the first batch of enhancements that we’re delivering on an all-new architecture that evolves Named Credentials from a small set of callout features into an extensible credentialing framework capable of handling sophisticated enterprise security requirements.
What follows is a quick overview of the new capabilities generally available now.
Custom headers and API keys
Custom headers provide a means for a remote system to define the parameters it needs as input to respond to a request. Using a custom header is similar to having a function in a piece of code and defining arguments that allow the caller to provide input. This release provides the option to add custom headers to named credentials, which is particularly useful when an external service uses an API key as a simple form of authentication.
Sensitive values are stored in an encrypted manner, and are available for use in formulas via a merge field syntax. This allows administrators to create credentials compatible with popular protocols like Basic authentication.
Permission set assignment
Since Salesforce is secure by default, administrators explicitly grant access to credentials by way of permission sets, allowing different groups of Salesforce users access to different credentials — even if they are used for the same endpoint. Sales reps, for example, might have a basic level of access to a remote system, and sales managers might have elevated access that allows them to override decisions when required.
A related capability protects named credentials created by administrators by explicitly allowing certain ISV managed packages to use them for callouts, if appropriate.
Role assumption for Amazon IAM
For the many customers looking to build integrations with Amazon Web Services (AWS), we’ve expanded our support for the AWS Signature V4 protocol to include temporary access and IAM role assumption via Amazon STS. Salesforce can request temporary, expiring access from the STS service, which assumes a role defined in IAM. This helps AWS administrators manage their infrastructure more effectively while they meet security and compliance requirements.
Additionally, this paves the way for compatibility with Amazon’s new RolesAnywhere capability in a future release, which allows these integrations to be secured via client/server certificate pairs.
Reuse across endpoints
The newly expanded architecture allows administrators to define authentication details in a single place, even if the same authentication is used against multiple API endpoints. Integrations with more sophisticated application stacks often require the use of multiple API endpoints that share one authentication mechanism. This way, sensitive credentials are not duplicated in Salesforce.
Support for custom setup UIs
ISV partners who are delivering their innovations via the AppExchange often seek to optimize the user experience associated with their setup process, both to reduce friction and lower support costs. In this release, named credentials distributed in a managed package using the OAuth protocol can be authenticated within a custom setup UI designed and branded by an ISV partner. This is enabled by a new Connect API with Apex access that will be expanded as new authentication protocols are supported.
We’re just getting warmed up
This release is exciting both in terms of the new features available now, and the capabilities enabled by the new architecture that is just around the corner. We’re planning JWT support, advanced OAuth flows, RolesAnywhere, and more.
Take a look at the documentation for the Winter ’23 release and dive in!
About the author
Ross Belmont is a Director of Product Management covering Platform Data Services. He has more than a decade of experience with the Salesforce ecosystem.