SAML SSO

On the Enterprise plan, your team can sign in to MITRITY through your SAML 2.0 identity provider (IdP), such as Okta, Microsoft Entra ID or Google Workspace. The first time someone signs in this way, MITRITY creates their account for them (just-in-time provisioning).

How Sign-In Works

1. On the MITRITY login page, the user enters their work email address and clicks Continue with SSO.
2. MITRITY finds the SSO connection for the address's domain and opens your IdP's sign-in page in a new window.
3. The user signs in at your IdP, with your password policy and MFA. The IdP sends a SAML assertion back to MITRITY.
4. MITRITY verifies the assertion with your IdP's signing certificate and signs the user in. On their first sign-in, it creates their account.

Sign-in starts on the MITRITY login page (service-provider-initiated SSO). Starting it from a tile in your IdP's app dashboard (IdP-initiated SSO) is not supported.

If the browser blocks the sign-in window, click Continue with SSO again, or allow pop-ups for mitrity.com.

Prerequisites

• You have the Owner role in your MITRITY tenant.
• Your tenant is on the Enterprise plan.
• You have administrative access to your IdP.
• You know the email domain that signs in through the IdP (for example company.com). A tenant has one SAML connection: one IdP and one email domain. People with addresses in other domains sign in with email and password or Google.

Setup

Setting up SSO takes four steps. In step 2, MITRITY registers your IdP and sends you your connection's provider ID.

Step 1: Create a SAML Application in Your IdP

Create a SAML 2.0 application for MITRITY with these service provider settings:

MITRITY takes the user's email address from the Name ID, so the Name ID must be the address the user signs in with, in the domain you configure. No other attributes are required. MITRITY's sign-in requests are not signed: leave any "require signed requests" option of your IdP off.

Assign the users or groups who may sign in to MITRITY, then note three values of your IdP for step 2:

• its entity ID (also called issuer),
• its SSO URL, where sign-in requests are sent,
• its X.509 signing certificate, in PEM format.

Okta

1. In the Okta admin console, go to Applications > Applications > Create App Integration, select SAML 2.0 and name the app MITRITY.
2. Set Single sign-on URL to the ACS URL and Audience URI (SP Entity ID) to the SP entity ID above.
3. Set Name ID format to EmailAddress and Application username to Email.
4. Finish the wizard. On the app's Sign On tab, open the SAML setup instructions for the issuer, the SSO URL and the certificate.
5. Assign users or groups on the Assignments tab.

Microsoft Entra ID

1. In the Microsoft Entra admin center, go to Enterprise applications > New application > Create your own application, name it MITRITY and choose the non-gallery option.
2. Under Single sign-on, choose SAML and edit Basic SAML Configuration: set Identifier (Entity ID) to the SP entity ID and Reply URL to the ACS URL above.
3. Under Attributes & Claims, set the Unique User Identifier (Name ID) to user.mail with the Email address name identifier format.
4. From SAML Certificates, download Certificate (Base64). From Set up MITRITY, copy the Login URL (the SSO URL) and the Microsoft Entra Identifier (the entity ID).
5. Assign users or groups under Users and groups.

Google Workspace

1. In the Google Admin console, go to Apps > Web and mobile apps > Add app > Add custom SAML app and name it MITRITY.
2. On Google Identity Provider details, copy the SSO URL and Entity ID and download the certificate.
3. Under Service provider details, set ACS URL and Entity ID to the values above, Name ID format to EMAIL and Name ID to Basic Information > Primary email.
4. Finish, then set the app's User access to ON for everyone or for the organizational units that use MITRITY.

Step 2: Send Your IdP Details to MITRITY

Email MITRITY support your tenant's name, the email domain, and your IdP's entity ID, SSO URL and signing certificate. MITRITY registers your IdP for your tenant and replies with your provider ID, for example saml.company-okta.

Step 3: Turn On SSO in MITRITY

1. In the dashboard, go to Settings > SSO.
2. Turn on Enable SAML SSO.
3. Enter the details:

4. Click Save.

The saved values are not displayed again. To change one, enter all of them again and save.

Step 4: Test the Sign-In

Open the MITRITY login page in a private window, enter the address of a user of your domain, and click Continue with SSO. Keep at least one Owner who signs in with email and password or Google, in case your IdP is unavailable.

Via the API

SSO settings are part of the tenant, and only an Owner can change them. Your tenant's ID is the tenant.id that GET /api/v1/tenants returns.

curl -X PUT https://api.mitrity.com/api/v1/tenants/6b1f3d0e-8c2a-4f5e-9d7b-2a1c3e4f5a6b \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "saml_enabled": true,
    "saml_entity_id": "http://www.okta.com/exk1company",
    "saml_sso_url": "https://company.okta.com/app/company_mitrity/exk1company/sso/saml",
    "saml_certificate": "-----BEGIN CERTIFICATE-----\nMIIC...\n-----END CERTIFICATE-----",
    "saml_email_domain": "company.com",
    "saml_provider_id": "saml.company-okta"
  }'

Enabling SAML on a tenant that is not on the Enterprise plan returns 402 with "code": "plan_upgrade_required".

Response: the tenant. It reports whether SAML is enabled and for which domain; the IdP details, the certificate and the provider ID are not returned.

{
  "id": "6b1f3d0e-8c2a-4f5e-9d7b-2a1c3e4f5a6b",
  "name": "Company",
  "slug": "company",
  "plan": "enterprise",
  "subscription_status": "active",
  "signup_source": "platform",
  "has_stripe_subscription": true,
  "max_agents": 100,
  "max_users": 100,
  "max_policies": 200,
  "saml_enabled": true,
  "saml_email_domain": "company.com",
  "created_at": "2026-01-15T10:00:00Z",
  "updated_at": "2026-03-01T10:00:00Z"
}

Configuration Fields

Send only the fields to change. When saml_enabled is true, all of the other fields must be set — in this request or already stored on the tenant.

JIT Provisioning

Just-in-time (JIT) provisioning creates a MITRITY account the first time someone signs in through your IdP, so you do not have to invite every user.

The new account has:

• the email address from the SAML assertion,
• the Member role,
• tenant-wide (all) access scope.

Owners and Managers adjust a provisioned user's role and access scope afterwards. To control who can sign in at all, assign users to the MITRITY application in your IdP.

MITRITY does not create the account when one of these holds. The login page then shows "SSO sign-in was refused" with the reason:

MFA with SAML SSO

SSO users set up MITRITY's multi-factor authentication like everyone else: after they sign in, MITRITY asks them to add an authenticator app. Once they have one, MITRITY asks for its code after each sign-in through your IdP, in addition to any MFA your IdP enforces.

Leaving the Enterprise Plan

If your tenant leaves the Enterprise plan while SSO is on, people who already have a MITRITY account keep signing in through your IdP, and MITRITY creates no new accounts through it: a first sign-in is refused with SAML SSO requires an enterprise plan. An Owner can turn SSO off in Settings > SSO.

Troubleshooting

Best Practices

Keep a Break-Glass Account

Keep at least one Owner who signs in with email and password or Google, with an address outside the SSO domain, in case SSO fails (IdP outage, certificate expiration).

Renew Certificates Ahead of Time

IdP signing certificates typically expire every one to three years, and an expired certificate stops every SSO sign-in. Before your IdP switches to a new certificate, send it to MITRITY support, then update it in Settings > SSO.

Review JIT-Provisioned Users

New users start as Members. Review them regularly and change roles as needed.

Enforce MFA at the IdP

MITRITY's MFA adds a second factor on top of your IdP's sign-in; enforcing MFA at the IdP as well protects every application that uses it.

Related Documentation

• RBAC — Role-based access control and user management
• Environments — Environment access for JIT-provisioned users
• API Keys — Programmatic access (not SSO-dependent)
• Billing — SAML SSO requires the Enterprise plan