What I learned this week: Providers & Self-Signed Certificates

I would say that about once a month I have a client or coworker sending me an email that looks like this and asking “what do I do?”

I remember getting my first one of these and panicking, and the documentation available for admins with little knowledge of single sign-on is poor. I am pretty sure that we have all found the answer via the Answers section of Salesforce’ Help, as opposed to actual documentation.

I have kept a link on hand to share for just this occasion (it’s here, in case you need it).

Fast forward a few years, and I’m studying security and identify more in-depth than I have in the past, and much like data skew, that involves learning the correct terms for what used to sound like jargon.

As the link above to Salesforce’s help article states, this Self-Signed certificate is most commonly used for Single Sign-On settings, but…what does that mean? As with anything else, stating the purpose or cause of something doesn’t always answer a person’s question. Many people much smarter than me have rightly pointed out that if you cannot explain a concept to a child, you do not truly understand that concept. And Salesforce’s Help Articles aren’t always great for that level of explanation.

So let’s start with the basics: Single Sign-On.

If you work for a company in an office, you may already experience this everyday. You log into your computer, and doing so logs you into other company services – an extranet, your inbox, etc. To varying degree, the idea is in the name – you sign in once to multiple platforms.

Ultimately this works because there are two entities working together to allow this to happen.

The Service Provider is the system you’re being logged into secondarily – let’s say JIRA. This is the platform that is requesting your login credentials. Normally this request looks like a login screen, but for single sign-on the whole point is that you bypass that screen. So instead of asking YOU, it asks the system you’re logging in through.

This initial system is the Identity Provider. It is helpfully passing along your credentials to the system that needs the information.

Salesforce, as you can imagine, can be both. And the self-signed certificate is sort of like your global permission slip. And like a permission slip it needs to be updated every once in a while.

“But I don’t have single sign-on enabled!” you cry.

Well sure, that makes sense. That means that Salesforce may not be a Service Provider in your org.

Have you installed any connected apps, though? Many connected apps walk you through a setup process that includes a handy UI that takes on the heavy lifting of setting up your API connection. During this process, some of those apps may create a certificate, which you’ll see by reviewing your connected apps link to that certificate. Sometimes these will take care of themselves – the third party companies you’re working with KNOW about this, and they plan accordingly, but at the least, you’ll know.

And if you’ve enabled Salesforce as an Identity Provider, even if you’re not using it that way…well, there you go.

Long story short: if you don’t remember setting this up, it’s very unlikely to cause issues, but it’s also very easy to update. Bookmark that link, and next year when you get that email, you’ll be ready.