Decoding Common Customer Questions About Enterprise SSO
Congratulations, you’re on track to close your first Enterprise customer!
But… they’re starting to ask a bunch of questions about user management you don’t quite understand. Acronyms like SAML, SCIM and OIDC are flying around, and you want to make sure you’re giving the right answers.
To answer those questions with confidence, let’s start with the basics: What is Enterprise SSO, and why do big customers care about it so much?
What is Enterprise SSO?
Large companies (also known as “enterprises”) have a lot of employees and a lot of software to manage. They also often have additional restrictions and policies around who can have access to what.
It’s nearly impossible to keep an eye on things if you’re managing all of this access in each individual product, so a product category called “Identity Providers” or IdPs was created. You may be familiar with some of them already: Okta, Entra (from Microsoft) and JumpCloud are all common IdPs.
Among other things, IdPs enable companies to get a unified view of all of their employees, and all of the things those employees have access to. Onboarding and offboarding employees becomes much simpler when using an IdP.
Okay, so why do I need to support Enterprise SSO?
In order for a company to be able to use their IdP with your product, a special integration is needed. There are multiple forms of these integrations, the most common being SAML, OIDC and SCIM. We’ll get into those later.
Some companies choose to build these integrations from scratch but some auth providers, such as PropelAuth, offer these integrations out of the box so no additional work is needed.
I don’t think I’ve ever heard anyone ask about Enterprise SSO…
Most customers won’t explicitly ask for Enterprise SSO - it’s more of a catchall term to describe the entire category. Instead, most customers will ask something more directly about their own setup. For instance:
- Do you support log in with Okta/JumpCloud/Entra ID?
- Do you support log in with SAML/OIDC?
- Do you support SCIM syncing?
You’ve mentioned SAML, OIDC and SCIM a few times now… what are those?
To put it simply:
- SAML and OIDC make it possible to authenticate users via an IdP. Essentially, they pass information to you so you can log users in and collect some information. A key thing to note is that you only get updated information about a user when they log in (this is also known as just-in-time provisioning), as opposed to all of the time.
- SCIM is a more constant sync between your customer’s IdP and you. Information will be shared in real time (or as often as SCIM is configured to share that information). SCIM makes it possible to do things like quickly revoke access to an employee that has been offboarded. Many larger companies require their vendors offer SCIM due to its quick syncing capabilities.
I already use an auth provider that provides Enterprise SSO support out of the box… what else do I need to know?
Quite a bit, actually. Since there are many IdPs, there can be some variance in what your customers are expecting. So let’s get to the next section…
Common Customer Questions
In this section, we’ll discuss common questions you might get from your customers once you answer “yes” to “Do you support Enterprise SSO?” Please note that these are written from a fairly general point of view, so you should always check with your individual auth provider for details.
Which IdPs do you support?
Okay, so you might not hear it phrased exactly like this, but your customer will need to know if you support their Identity Provider of choice. Many auth providers do have a Generic connection option available, but it’s always nice for your customer to hear that there’s a more first-class integration.
Common IdPs include:
- Okta
- Entra ID (note: this used to be called Azure Active Directory, some customers may still refer to it that way)
- JumpCloud
- OneLogin
- Ping Identity
Do you support just-in-time provisioning?
If a customer is asking about this, they are asking about SAML or OIDC support - the ability to log users in via their IdP.
Do you support SP initiated logins or IdP initiated logins?
This refers to where the user will start the login process.
SP initiated logins mean they start the login process on YOUR login page. SP stands for Service Provider and, well… that’s you!
IdP initiated logins means they start the login process in their Identity Provider. The user doesn’t need to navigate to your product first, they click on your application in their IdP and they’ll automatically be logged in. This is relatively common for SAML, but isn’t a first class concept for OIDC.
Can we manage our roles via our IdP?
If your product has some kind of concept of roles to provider granular access, your customers may want to manage them via their IdP for the same reason that they want to manage the rest of the process there - it’s a unified view.
Each IdP has slightly different ways of supporting role management, and some even have a couple different options (some have first-class role support, some require you to use groups instead). If you plan to support this, you’ll likely want to provide some additional instructions to help your customers. At PropelAuth, we’ve built guides and wizards for the major IdPs to keep things as friction-free as possible
Can we provision by groups?
To help keep everything organized, IdPs allow companies to create groups of users. These can be anything they want, but most commonly they will correlate to a team, title or seniority.
At larger companies, it’s often preferable to be able to provision an entire team at once instead of having to worry about adding individual permissions to access your application.
This is generally supported by default for most IdPs and isn’t something that you have to worry about.
What are your ACS URL, Audience URI, and Entity ID?
If your customer is asking about these - congratulations! They are likely pretty committed to using your product and getting connected with your IdP. Some are values that you provide to your customer and some are values that your customer provides to you - if you don’t already know how to find them, ask a member of your development team.
Can you hop on a call to help us get onboarded?
Because Enterprise SSO can be so varied, it can be common for there to be some back and forth between you and your customers during the initial set up. Offering a call can definitely be a good idea, though at PropelAuth we’ve found that our guides make it easy for customers to self-serve and significantly reduce the amount of back and forth needed.
Conclusion
Enterprise SSO is an extremely useful service to provide to your customers. It encourages them to onboard to your product faster, and can often make it easier to pass the security part of a vendor evaluation process… as long as you can answer all of their questions!
In short: Enterprise SSO might feel complicated, but it’s one of the simplest ways to win trust and close deals faster.
