(My colleague Adam Yost who you'll see in previous comments here posted about this, but I can't see the post and I wonder if it's hidden from others as well. He's the original author and I've only made a few editorial additions.)
We use SF Connect for external objects that hit Snowflake. Last year we followed all the steps to set up the connection and it authenticates the principal with a username/password (it must be done manually with a pop-up interface to log in to Snowflake). The service stops working every few months and we have to manually re-authenticate - but that's not today's topic.
Snowflake will remove the password option soon (here's their published schedule) - we have until June 1 to transition to a Programmatic Access Tokens (PAT) - a very long string. We were told this would be easy - just use the PAT in place of the password.
But we have tried this and it doesn't work. We created a PAT in Snowflake. When authenticating the principal in SF the popup takes me to log in to Snowflake. I enter the username and PAT and get an "invalid password" error. I'm told that Snowflake does not accept PATs via the browser login.
Are we supposed to be able to use PATs in the setup for Snowflake connections?
My searches so far seem to imply that Salesforce Connect does not support the use of PATs. If that is true, what are we supposed to do when Snowflake enforces PAT usage?
This Snowflake document mentions "You can also use a programmatic access token as a replacement for a password in the following: Third-party applications that connect to Snowflake (such as Tableau and PowerBI)" but does not mention Salesforce.
*Adam's Disclaimer
: Security language is Greek to me. I don't understand all the terms. Named Creds, External Creds, oAuth - all blur together for me. But for now I'm the developer on the task to move from password to PAT.
CC:
Here are the options I see, in no particular order:
- Our documentation as-is highlights OAuth, lining up to what Snowflake calls Human Users, which will continue to work. (It wouldn't make much sense to cut off all access to Snowflake for human beings.) This is how my demos are configured, even though Snowflake made a change that requires humans to use MFA when they're logging in.
- The PAT option essentially acts as an API key, though they're trickier to create, may involve what Snowflake calls a network policy, and require rotation every year (according to my read of their doc). What I would do in your shoes is generate that token and treat it like an API key using this pattern from Named Credentials. You can try that literally today.
- Looking ahead into future releases, we want to expand the support for JWT in Named Credential to account for what Snowflake calls key-pair rotation. That might even work today, as long as the cert was created by an authority Salesforce trusts.
- The typical challenge there is that the way Snowflake instructs customers to create the certs is essentially by self-signing using command line tools: you're creating both the public and private side yourself. You can't use those certs for inbound scenarios in Salesforce–that's been the case for many years—but that doesn't mean we can't support them for outbound scenarios with Named Credentials. Our goal is to put that in place in the Summer release, giving you 3 different options in total.
cc
@Andrea Guzman
