SSO / SAML Single Sign-On

Connect your identity provider (Okta, Microsoft Entra/Azure AD, Google Workspace, OneLogin, JumpCloud, Auth0, custom) so your team signs into AegisRunner with their existing corporate credentials. Just-in-time provisioning means new hires get accounts automatically when they first sign in.

How it works

1. You configure SAML in your IdP, pointing at AegisRunner's ACS URL.
2. You add the IdP's metadata (or paste in the certificate, SSO URL, entity ID) into AegisRunner's settings.
3. Users go to aegisrunner.com/login and click Sign in with SSO, enter their work email — they're redirected to your IdP, authenticate, and bounce back signed in.
4. If a user doesn't have an AegisRunner account yet, JIT provisioning creates one with the role you've configured for new SSO users.

SP-initiated flow only. AegisRunner doesn't currently support IdP-initiated sign-ins.

Setting up SSO (general flow)

1. Go to Settings → SSO & SAML in AegisRunner.
2. Click Configure SSO. You'll see your AegisRunner SP details:
   • ACS URL — where the IdP posts SAML responses (https://aegisrunner.com/api/v1/sso/acs).
   • Entity ID / Audience — your unique tenant identifier.
   • Sign-in URL — where to point users for SP-initiated sign-in.
3. Configure these in your IdP. Most IdPs let you upload an XML metadata file; ours is downloadable from the same page.
4. From the IdP, copy the IdP signing certificate, IdP SSO URL, and IdP entity ID.
5. Paste them into AegisRunner. Save.
6. Click Test SSO. A test sign-in opens; verify it lands you back signed in.

IdP-specific guides

Okta

1. In Okta admin, Applications → Create App Integration → SAML 2.0.
2. Single Sign-On URL: paste AegisRunner ACS URL.
3. Audience URI: paste AegisRunner entity ID.
4. Name ID format: EmailAddress.
5. Attribute statements (recommended): email, name, given_name, family_name.
6. Save, assign users/groups, then download the IdP metadata XML.
7. Upload the metadata in AegisRunner's SSO config.

Microsoft Entra (Azure AD)

1. In Entra, Enterprise applications → New application → Create your own → Non-gallery.
2. Single Sign-On → SAML.
3. Identifier (Entity ID): AegisRunner entity ID.
4. Reply URL (ACS): AegisRunner ACS URL.
5. User attributes & claims: ensure email and name are sent.
6. Download the federation metadata XML and upload to AegisRunner.
7. Assign users/groups in the Users and groups blade.

Google Workspace

1. In Workspace admin, Apps → Web and mobile apps → Add app → Add custom SAML app.
2. Download the IdP metadata.
3. ACS URL and Entity ID: from AegisRunner.
4. Name ID: Primary email.
5. Attribute mapping: email, first name, last name.
6. Turn on for the right org units.
7. Upload metadata to AegisRunner.

Other IdPs

OneLogin, JumpCloud, Auth0, Ping, custom — all support SAML 2.0 SP-initiated sign-in. The metadata format is standardized, so the steps are roughly the same as the IdP-specific guides above.

Just-in-time provisioning

When a user signs in via SSO and doesn't have an AegisRunner account yet, JIT creates one automatically. By default they're created as a Member in the org with no project memberships.

You can change the default role under SSO settings → Default role for new users:

• Member (default) — they can be added to specific projects manually.
• Admin — auto-promoted into all projects.
• Viewer — read-only across the workspace.

Group-based role assignment Enterprise

Enterprise plans can map IdP groups to AegisRunner roles. In the SAML response, the IdP includes a groups attribute; AegisRunner translates that into project access:

Mappings are defined under SSO settings on Enterprise. Re-evaluated on every sign-in — moving someone out of aegis-qa downgrades their access on next sign-in.

Enforcing SSO

Once SSO is working, you can require it for all org members:

1. Go to SSO Settings → Enforcement.
2. Toggle Require SSO for sign-in.
3. Email + password sign-in is disabled for everyone except Org Owners (Owners can always sign in directly to recover from a broken IdP).

Confirm the IdP is working before enforcing. Locking out the team because of a misconfigured IdP is the worst possible morning.

Common configuration issues

What we store

• Your IdP's signing certificate (encrypted with AES-256).
• SSO URL, entity ID, attribute mappings.
• A SAML session record per user — used to validate single logout (SLO) requests.

We don't proxy or impersonate your IdP. SSO sessions are validated against the cert on every sign-in.

Single Logout (SLO)

If you configure SLO in your IdP, signing out of AegisRunner can also sign the user out of your IdP (and vice versa). Optional — most teams leave SLO off and let session expiry handle things.

Related

• Two-Factor Authentication — for non-SSO accounts.
• Roles & Permissions — what each role can do.
• Team Management — adding seats and members.