Set up SAML SSO
Let your team sign in to Hyperping through your identity provider. SAML SSO works with Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin, Auth0, JumpCloud, and any SAML 2.0 compliant provider.
What SAML SSO covers
SAML SSO controls how your teammates log in to the Hyperping dashboard. It is available on the Business plan. Users sign in through your IdP, and Hyperping trusts the assertion, which gives you centralized offboarding and aligns with SOC 2 and ISO 27001 access-control requirements.
SAML sits alongside the two other login methods. Sign in with Google is available on all plans and combines with SAML when your policy is set to allow both. Email and password stays available for the Owner as a lockout fallback, so you can never lock yourself out of the account. See Login methods for a full comparison of the three.
This guide covers dashboard login for your team. To put a status page behind SAML for your end users, see Private status pages. The two are configured separately.
Prerequisites
- A Hyperping Business plan. See pricing for plan details.
- Admin access to your identity provider so you can create a SAML application.
- The Owner account in Hyperping. Only the Owner can configure SSO and authentication settings. See Roles and permissions.
Step 1: Get the ACS URL and entity ID from Hyperping
- Go to the Teammates section and open the Authentication tab.
- Click Setup Authentication Provider (SSO).
- The setup wizard shows Hyperping's ACS URL and entity ID. Keep this tab open, your IdP needs both values in the next step.
Step 2: Create the SAML application in your IdP
Every provider asks for the same two values, but labels them differently:
| Provider | Create the app under | ACS URL field | Entity ID field |
|---|---|---|---|
| Okta | Applications → Create App Integration → SAML 2.0 | Single sign-on URL | Audience URI (SP Entity ID) |
| Microsoft Entra ID | Enterprise applications → New application → Create your own application | Reply URL (Assertion Consumer Service URL) | Identifier (Entity ID) |
| Google Workspace | Apps → Web and mobile apps → Add custom SAML app | ACS URL | Entity ID |
In your IdP, configure the application to send each user's work email address as the name identifier, then assign the users or groups who should have access. The setup wizard in Hyperping indicates any additional field it needs.
Once the application is created, copy its metadata URL or download the metadata XML. If your provider is not in the table above, any SAML 2.0 compliant provider works with the generic SAML configuration in the wizard.
Step 3: Paste the IdP metadata into Hyperping
Back in the Hyperping setup wizard, paste the metadata URL or XML from your IdP. The wizard walks through each field.
Step 4: Test the connection
Run the built-in test login before enforcing anything. Once a test login succeeds, SAML is live and teammates can pick it on the login screen.
Choose an enforcement mode
After testing, decide whether SSO is optional or mandatory for non-Owner users:
| Mode | Behavior | Use when |
|---|---|---|
| Allow SSO and email/password | Users pick either method at the login screen. Sign in with Google also stays available. | During rollout, or when you need a break-glass path outside the IdP. |
| Require SSO | Non-Owner users must sign in through your IdP. The Owner keeps email and password as a lockout fallback. | Once rollout is done. Aligns with SOC 2 and ISO 27001 controls. |
Provision teammates and roles
The provisioning policy decides what happens when someone signs in through your IdP without an existing Hyperping account:
| Policy | Behavior |
|---|---|
| Invite-only | SSO login fails unless an admin already invited the user. Most secure. |
| Request access | New users land on a pending screen. Admins get notified and approve or deny from the Teammates page. |
| Auto-provision | Anyone with a matching email domain joins automatically. Best when your IdP is the source of truth for employment. |
Provisioned users get a role like any other teammate. New invites default to Member, and you can change roles from the Teammates section. See Invite teammates for the invite flow and Roles and permissions for what each role can do.
You can also restrict SSO users to a selected set of projects with the SSO access scope setting, which is useful for contractors or per-client segregation. See Login methods for the details.
SAML for private status pages
Protecting a status page with SAML is a separate feature aimed at your end users, not your teammates. You create reusable connections under Status Pages → SSO Connections, and each connection can protect multiple status pages. Connections are billed per month: $49 for Azure AD (Direct SAML) and $99 for other providers such as Okta and Google.
See Private status pages for the full setup, including password protection and email access codes.
Troubleshooting
The test login fails with "user not found." Your provisioning policy is set to Invite-only and the user has no account yet. Invite them from the Teammates page first, or switch provisioning to Request access or Auto-provision.
I enabled "Require SSO" and locked myself out. Owner accounts are exempt by design and can always sign in with email and password. Log in as the Owner, go to Teammates → Authentication, and relax the policy.
My IdP is not listed in this guide. Any SAML 2.0 compliant provider works through the generic SAML configuration in the setup wizard. If you hit a snag, contact us with your IdP's metadata.
Related
- Login methods, the full comparison of SAML, Google, and email login.
- Invite teammates, how to add people and transfer ownership.
- Roles and permissions, what each role can see and do.
- Private status pages, SAML-protected status pages for your end users.
