Based on a number of comments I’ve added test coverage for the Azure Client Credentials Auth. Provider I pushed to Github on Friday. See that post (Custom Salesforce Auth. Provider for Microsoft Azure client_credentials flow) for links to Github.
Month: May 2021
Custom Salesforce Auth. Provider for Microsoft Azure client_credentials flow
When doing integrations from Salesforce you sometimes need to do this using single identity instead as in the context of the current user. Salesforce supports both through Named Credentials i.e. both working as the current user or as a Named Principal. Through the Named Credentials and Auth. Provider concepts from Salesforce you can setup a connection between Salesforce and an OAuth 2.0 enabled endpoint such as Microsoft Azure i.e. if needing the access the Microsoft Graph API. This can however be an issue as the target system (i.e. Microsoft Azure in this case) may not use a user that is able to login or you may not want to use a user license in the target system.
In this case you might want to use the client_credentials OAuth flow as that identifies the caller using a client_id and a client_secret instead of a user id. Unfortunately that OAuth flow type is not supported out-of-the-box with Salesforce. The reason is that the Auth. Providers in Salesforce usually deals with a user behind the keyboard. Due to this the OAuth 2.0 Auth. Provider flows was designed for a access_token / refresh_token World. This makes it impossible to use the built in capabilities for the client_credentials flow.
The solution is to write a custom Auth. Provider in Apex and use that from your Named Credential. To make this easier I’ve already implemented this for you. The code is available on Github in my salesforce-azure-clientcredentials-authprovider repo. This implementation just plays along with the access_token / refresh_token requirements and just requests a new access_token using the client_credentials flow whenever a (new) access_token is needed and hence do not need a user behind the keyboard.
The README.md in the repo has instructions for installing and configuring the code in the org. Once deployed you can create an Auth. Provider and a Named Credential. Please note you also need to create an App Registration in Azure Active Directory with the required Application Permissions.
Remove all padding in a Salesforce Experience Cloud Site
Note to self. When building non-LWR based Experience Cloud sites there is some padding that needs to be removed to make your site fill the entire display port. Put the following CSS classed in custom CSS for the Site to remove it.
.cCenterPanel {
padding: 0px;
margin: 0px;
}
.contentRegion {
padding: 0 !important;
}
YMMV
Minimum access to create/delete Salesforce scratch orgs
Working with scratch orgs in Salesforce requires that the DevHub feature is enabled in a non-sandbox (i.e. Production, Developer or Trial) org and that you’ve authenticated to the org. Normally from your Salesforce CLI or CI/CD pipeline.
Since the DevHub is required to be enabled in Production this has led to some concern from some customers I’ve spoken to. Following up on this with a customer who now really needed the scratch org capability I set out to figure out the least amount of access required to the DevHub Salesforce org.
It’s important to remember that license is one thing another is object access. If you are out of licenses Salesforce
Well one thing is license another is access. License seems well described but not so access. Played a bit around with access and was able to get it working with minimum access to an org. I started with a no-access profile and added API access and then figured out object access required. Minimum access required to create a scratch org is:
Read, Create on ScratchOrgInfos
Read on ActiveScratchOrgsTo delete a scratch org you need:
Read, Create, Edit on ScratchOrgInfos
Read, Create, Edit, Delete on ActiveScratchOrgs