Self-Service SSO: Connect Okta, Azure AD, or Google Workspace in Minutes

SSO is a top-3 checkbox on every enterprise evaluation scorecard. And on most platforms, enabling it means filing a support ticket, scheduling a call with a solutions engineer, and waiting 3-5 business days for someone to flip a switch on your behalf.

Enterprise IT teams don’t want to wait. They want to open a settings page, paste a metadata URL, test the connection, and move on. That’s what JieGou’s self-service SSO configuration does.

7 identity providers, 2 protocols

JieGou supports 7 identity provider presets out of the box:

| Provider | Protocols | |---|---| | Okta | SAML 2.0, OIDC | | Azure AD (Entra ID) | SAML 2.0, OIDC | | Google Workspace | SAML 2.0, OIDC | | OneLogin | SAML 2.0, OIDC | | Auth0 | SAML 2.0, OIDC | | Ping Identity | SAML 2.0, OIDC | | Custom Provider | SAML 2.0, OIDC |

The Custom Provider option works with any SAML 2.0 or OIDC-compliant identity provider. If your IdP speaks one of those protocols, it works with JieGou.

Protocol details

SAML 2.0

Enter a metadata URL and JieGou auto-fetches the XML document, extracting the entity ID, SSO URL, and X.509 certificate automatically. No manual copy-pasting of certificates.

Configuration options:

• 4 Name ID formats — email, persistent, transient, unspecified
• Auth request signing — sign SAML authentication requests for providers that require it
• Certificate fingerprint — SHA-256 fingerprint validation for the IdP’s signing certificate

OpenID Connect (OIDC)

Enter a discovery URL and JieGou auto-normalizes it — appending /.well-known/openid-configuration if needed — then fetches the discovery document to populate endpoints automatically.

Configuration options:

• Client ID + encrypted client secret — the client secret is encrypted via key-vault before storage
• Configurable scopes — default: openid profile email groups
• 3 token endpoint auth methods — client_secret_basic, client_secret_post, private_key_jwt

The setup flow

Configuration takes 9 steps:

1. Navigate to account settings — SSO configuration lives under your account’s security settings
2. Select protocol — SAML 2.0 or OIDC
3. Pick provider preset — choose from the 7 presets, or select Custom
4. Enter email domain — uniqueness enforced across all accounts, so no two organizations can claim the same domain
5. Fill provider-specific fields — metadata URL for SAML, discovery URL for OIDC, plus any provider-specific configuration
6. Configure provisioning — toggle auto-provisioning on or off, set the default role for new users
7. Set up group-to-role mappings — map IdP groups to JieGou roles
8. Save configuration — validates all fields before persisting
9. Test connection — run diagnostics, review results, then enable

Steps 1-8 are configuration. Step 9 is where you verify everything works before going live.

Connection testing with diagnostics

The test button runs a full diagnostic suite against your IdP configuration. One click, and you see per-check pass/fail indicators with color-coded results.

SAML diagnostics:

• Metadata document fetched successfully?
• SSO URL reachable?
• X.509 certificate valid and not expired?

OIDC diagnostics:

• Discovery document fetched successfully?
• Token endpoint reachable?
• Group claim found in token response?

Each check shows a clear pass or fail. If something breaks, you see exactly which step failed — not a generic “SSO configuration error” message. Test results are stored for your audit trail, so you have a record of when the connection was validated and by whom.

Group-to-role mapping

JieGou has a 6-role hierarchy: Owner, Admin, Dept Lead, Member, Auditor, and Viewer. SSO group-to-role mapping lets you connect your IdP’s group structure to these roles directly.

The mapping works like this:

| IdP Group | JieGou Role | |---|---| | engineering-leads | Dept Lead | | engineering | Member | | finance-auditors | Auditor | | executives | Admin | | contractors | Viewer |

You can also assign departments from groups. If your IdP has groups like dept-engineering or dept-marketing, map those to JieGou departments so users land in the right organizational context automatically.

Users without a matching group get the default role — typically Member. This means every SSO user gets access, even if your IdP group structure doesn’t perfectly mirror JieGou’s role model.

Just-in-Time provisioning

When JIT (Just-in-Time) provisioning is enabled, new users don’t need a separate invite. Here’s what happens:

1. A user authenticates via SSO
2. Their email domain matches your configured SSO domain
3. JieGou auto-creates their account membership with the configured default role
4. Group-to-role mappings apply, upgrading or specifying the role if a match is found
5. Department assignments from group mappings are applied
6. The user is routed through the onboarding flow

No admin action required. No invite links to manage. A new hire logs in on day one, and their access is configured by whatever groups they belong to in your IdP.

Login flow

From the user’s perspective, SSO login is 3 clicks:

1. Click “Sign in with SSO” on the login page
2. Enter their email address
3. The system performs a domain lookup — a public, unauthenticated endpoint that checks if the email domain has an SSO provider configured
4. If a provider is found, a “Sign in with [Provider Name]” button appears
5. Click it, authenticate with the IdP via signInWithPopup, and land in JieGou

The domain lookup endpoint is intentionally public. It doesn’t reveal whether a specific email address exists — only whether a domain has SSO configured. This is the standard pattern used by most SSO implementations to route users to the correct IdP.

Security

Domain uniqueness — Each email domain can only be claimed by one account. This prevents a malicious account from configuring SSO for a domain they don’t own and intercepting authentication flows.

Audit logging — Every configuration change is audit-logged: who changed what, when, and the before/after values. SSO setup, modification, testing, enabling, and disabling are all tracked.

Admin-only access — SSO configuration requires the account:admin permission. Regular users can authenticate via SSO but cannot view or modify the configuration.

Encrypted secrets — OIDC client secrets are encrypted via key-vault before being written to the database. They’re decrypted in memory only when needed for token exchange.

Availability

Self-service SSO/SAML configuration is available on Enterprise plans. Includes all 7 identity provider presets, SAML 2.0 and OIDC support, group-to-role mapping, JIT provisioning, connection diagnostics, and full audit logging. Learn more about enterprise features or start a trial.