Correctly grant access to packaged Named Credentials

Question

My Managed Package uses External APIs and packages External Credential and Named Credential artifacts.

I also have packaged a Permission Set, and I tried hard to make use those packaged Credentials. But it seems like this is not possible.

The users still get this error when my managed code uses the Named Credential.

The callout couldn't access the endpoint. You might not have the required permissions, or the named credential "namespace__OpenAi" might not exist.

Even if I create a new Permission Set after installation and assign it, it fails with the same error.

Answer 1

The "new" External Credentials are not supported for 2GP packaging per the Metadata Coverage report:

https://developer.salesforce.com/docs/metadata-coverage/58

Legacy Named Credentials are generally inappropriate for Managed Package usage because they can be used by any code in the subscriber org. Said differently: If you're shipping a secret in your managed package, you should use a Protected Custom Metadata Type record. (This recommendation was provided by Salesforce Security Review Office Hours)

For secrets that vary from subscriber to subscriber and need to be provisioned into each org, that's where a Protected Custom Setting (and UI to allow the subscriber to set it) or providing them with laborious instructions for creating a Named Credential (new or legacy) may be appropriate.

A separate, but related, thread was created which suggests against using Named Credentials in managed packages due to their brittleness when it comes to being updatable in a subscriber org. The PM for Named Credentials (Ross Belmont) said:

The first blocker teams tend to face is the inability to include secret values in metadata; that will never be workable from a security standpoint since metadata can be accessed in plain text XML. Something would need to be done post-deploy to fill in the missing piece of configuration. 🧐

Separately, we see that a surprisingly large percentage of the time, the full details about a remote endpoint can’t be known at packaging time. Sometimes, there’s a dynamic or custom subdomain, similar to how we have My Domain in our platform. A variation of this same idea is that the endpoint used in sandbox for testing is very often not the same endpoint in production. (Remote systems can have their own concept of sandbox or test environments.) These factors make adoption of Named Credentials among our AppExchange ISVs in particular lower than we’d like it to be. 😕

https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000JgiQmSAJ

Lastly, IIRC, you can't grant access to the "new" External Credentials via Permission Set -- it can only be granted by Profile which seems to be absolutely backward with regard to Salesforce's recommendation to stop using Profiles to provide access.

Answer 2

I've been looking to do this for the last 24 hours, and I've somewhat inadvertently stumbled over something that works at last.

The situation is as follows. I want to call some Google Cloud services. I am authenticating to them using OAuth 2.0 with the JWT flow, signing the requests with a certificate extracted from Google Cloud. As the certificate can't be packaged, I was struggling because it seemed like a turtles-all-the-way-down sort of thing: can't package the certificate, but the External Credential needs that, so I can't package that, but then the Named Credential needs that, so I can't package those, but then the Apex in my package can't call a NC that I create manually post installation...

Anyway, I have just found an approach that works, with the majority of components inside the 2GP package, and Google is very definitely being called. Here's what I did:

• remove the whole <externalCredentialParameters> block from the External Credential where <parameterType>SigningCertificate</parameterType>. I wasn't really expecting that to work because it's a mandatory field in the UI, but Salesforce seems to understand that you can't package certificates, so the package upload of this doesn't error.
• as the External Credential is now in the package, the Named Credentials which refer to it need to have the package namespace prefix added in their <externalCredential> elements.
• the permission set granting the access to the external credential also needs the namespace prefix in the <externalCredentialPrincipal> element.
• the Apex code where the named credentials are used also seems to need the prefix...I changed to 'callout:prefix__credentialname'
• the package uploaded successfully
• I uploaded the certificate from GCloud to the target org, applied that manually to the External Credential, invoked the code...and success.

Once I was chopping the XML manually to get rid of the certificate in the External Credential, I just carried on. I'm not sure how much of this you'll get automatically from retrieving from even a namespaced scratch org (because that's what I created my solution in, and I still wasn't set up correctly).