SAML SSO for SMBs — getting started without an IT department

SAML is one of those acronyms that sounds enterprise-only. It isn't. A 50-person company with Google Workspace can have SAML SSO into their HR portal in 20 minutes. A 200-person company with Okta can do the same in 10. The reason most SMBs don't is they don't know that, not that it's actually hard.

This piece is the missing manual: what SAML is in plain terms, the four steps to enable it, and the gotchas that make first-time setup slightly trickier than docs admit.

What SAML actually does

When you sign into a SaaS app today, you probably type a password (or click "Sign in with Google" / "Sign in with Microsoft"). SAML is the third option: "Sign in with your company's identity provider".

The flow:

1. You visit dtpulse.yourcompany.com.
2. The portal sees you're not signed in. It redirects your browser to your identity provider (Okta, Google Workspace, Azure AD, etc.).
3. The IdP authenticates you (password, MFA, etc.) — using whatever method your company has standardized.
4. The IdP redirects your browser back to the portal with a cryptographically signed "assertion" saying "yes, this is [email protected], she's in the Engineering group."
5. The portal trusts the assertion (it verified the signature against a certificate it has on file), creates a session, you're in.

You never typed a password into the portal. The portal never stores a password for you. When you leave the company, IT disables your Okta account; the portal's no longer accessible to you the next time you try to sign in. No "ask the SaaS vendor to remove a user" step.

Why SMBs should care

Three reasons SMBs should bother with SAML, even if they're 30 people:

1. Offboarding hygiene. When someone leaves, you turn off their Okta/Google account. They lose access to every SAML-integrated app instantly. Without SAML, every SaaS tool needs to be manually deprovisioned, and one of them always gets missed. The HR system specifically is the WORST one to miss — that's where personal data lives.

2. MFA gets free. Set up MFA in your IdP once; every SAML app inherits it. Without SAML, each app has its own MFA settings, and your weakest app's MFA story is the company's MFA story.

3. Password reuse stops being your problem. SAML moves password entropy into one place where you can enforce password policies properly. The HR system, the project tracker, the design tool — none of them ever see a password.

The cost? A one-time 20-minute setup per app. After that the IdP team manages everything.

The 4-step setup

Whatever IdP you use, the setup follows the same shape. I'll use Okta as the example; Google Workspace and Azure AD differ in UI labels only.

Step 1: In your IdP, add a new SAML application

In Okta: Applications → Browse App Catalog → search for DTPulse (or whatever portal you're integrating). If your portal isn't in the catalog: Applications → Add Application → "Create New App" → SAML 2.0.

The IdP will ask you for:

• Single sign-on URL (sometimes called "ACS URL" or "Reply URL"): the URL on the portal where SAML assertions get posted. The portal's docs tell you this. For DTPulse: https://yourtenant.dtpulse.com/api/auth/callback/saml.
• Audience URI (sometimes "SP Entity ID"): an identifier for your portal in the IdP. Usually the portal URL: https://yourtenant.dtpulse.com.

Save the app. The IdP gives you back:

• A SSO URL (the IdP endpoint your portal redirects users to).
• A public certificate (used by the portal to verify the IdP's signatures).
• An IdP Entity ID (the IdP's own identifier).

Step 2: In your HR portal, paste those three values

The portal's SSO admin page has fields for "IdP SSO URL", "IdP certificate" (paste the X.509 PEM block), "IdP Entity ID". Save.

If the portal supports it, also turn on:

• Just-in-time (JIT) provisioning: when a new user authenticates via SAML and doesn't exist in the portal yet, create them automatically. Saves manual user-creation work.
• Group → role mapping: e.g. "users in the Okta group 'HR' get the ADMIN role in the portal." If you skip this, every user comes in as a regular employee and you assign roles manually.

Step 3: Assign users in the IdP

In Okta: the new app has an "Assignments" tab. Add users or groups (entire groups is usual). The users you assign here will be able to sign in via SSO.

Assignment is enforcement: people NOT assigned to the app in the IdP can't sign in even if they have a portal account. This is what makes offboarding clean.

Step 4: Test, then enable

Test:

1. Sign in as yourself (you should be assigned).
2. Sign out.
3. Visit the portal URL → you should get redirected to the IdP login page → after authenticating you should land in the portal.

Once that works, in the portal: turn on "SSO required" (different portals call this differently). This disables password login for the SAML-managed users; they MUST go through SSO from now on.

Keep at least one admin account with password login as a break-glass — in case the IdP itself is down or misconfigured later.

The four gotchas first-time setup hits

1. Clock skew. SAML assertions are signed and timestamped. If your portal's server clock and your IdP's server clock differ by more than a couple of minutes, assertions get rejected as expired or future-dated. Modern hosts auto-sync NTP and this isn't usually an issue, but if you self-host the portal on a VM that nobody patches, verify NTP is running.

2. The certificate eventually expires. The IdP cert you pasted in step 2 has an expiry date — typically 1–3 years out. The day it expires, your SSO breaks with cryptic "signature invalid" errors. Mitigate: when you save the cert, also set a calendar reminder 60 days before expiry to rotate it. The good portals show the expiry date and email admins when it's approaching.

3. Name ID format mismatch. SAML assertions identify the user by a "name ID" which can be email, username, or various other forms. The IdP and portal need to agree. If your portal expects nameIDFormat=emailAddress and your IdP sends nameIDFormat=persistent, the portal won't recognize the user. Both sides usually have a "name ID format" dropdown that needs to match.

4. Group claims need to be configured separately. Just enabling SAML auth doesn't automatically send group memberships. You usually have to add a "group attribute statement" in the IdP app config that includes a groups claim. Without it, your "Okta HR group → portal ADMIN role" mapping has nothing to map from.

When you DON'T need SAML

A reasonable threshold: if you're under 15 people and don't use an IdP for anything else, SAML is overkill. Use the portal's built-in password auth (with MFA on) and revisit when you onboard your 20th person.

Above 25 people, the offboarding-hygiene argument starts to dominate. Above 50 people without SSO, you almost certainly have some former employee whose account in some tool isn't disabled.

What we ship

DTPulse SAML integration: paste IdP SSO URL + cert + entity ID, optional JIT provisioning, optional group-to-role mapping, supports Okta / Google Workspace / Azure AD / OneLogin / Keycloak / generic SAML 2.0. Certificate expiry warning 30 days out via email. Per-tenant config (multi-tenant SaaS deployment) so each customer manages their own IdP setup independently. Break-glass admin account always retains password fallback.

20-minute setup is what we aim for. If it takes longer on your setup, that's almost always one of the four gotchas above.

Related reading

• Self-hosted HR software: when to go on-prem (and when not to)
• What is an employee portal — and when does a company really need one