Skip to content
FortressFlag Docs

Connect Okta

If your company runs on Okta (or another SAML identity provider), FortressFlag can hand sign-in to it entirely — and let your directory drive who has an account and what role they hold. This guide connects the three layers in the order that keeps you signed in the whole time: SSO first, then provisioning, then group-to-role mapping, then — once everything works — the policy switch.

You’ll need to be the Owner on the FortressFlag side, and an Okta admin on the other. FortressFlag speaks SAML for sign-in and SCIM 2.0 for provisioning. (OIDC isn’t supported.)

1. Connect SSO

Section titled “1. Connect SSO”

In Admin → Authentication, set up the SSO connection: paste your identity provider’s metadata, and FortressFlag gives you back the two values Okta’s SAML app setup asks for — the service-provider entity ID (its metadata URL) and the ACS URL.

Create a SAML app in Okta with those values, assign yourself to it, and test the sign-in: your organization’s login screen gains a single sign-on path alongside the password form. At this point SSO works but isn’t required — password sign-in still functions, which is exactly where you want to stay while testing.

2. Turn on provisioning (SCIM)

Section titled “2. Turn on provisioning (SCIM)”

Also under Admin → Authentication, mint a SCIM token. Like an SDK key, it’s shown once — copy it straight into Okta’s provisioning configuration as the bearer token, and point Okta at your FortressFlag SCIM endpoint (the /scim/v2 path on your FortressFlag address).

With provisioning on, Okta creates and removes FortressFlag accounts as people join and leave your directory:

  • A provisioned person starts as a Viewer with no project access — safe by default; you grant from there (or let group mapping do it, next section).
  • Deprovisioning removes their access and signs them out — offboarding in your directory is offboarding here, sessions included.
  • Changes made by provisioning show up in the audit log attributed to the provisioning token — your directory’s actions, recorded as such.
  • One guardrail: provisioning can never remove your organization’s last Owner.

A note your legal team will ask about: people created by provisioning never saw a signup form, so an administrator accepts the service terms on their behalf — the dashboard prompts for this, and the acceptance is recorded like any other.

3. Map groups to roles

Section titled “3. Map groups to roles”

Push your Okta groups over SCIM, and the group mapping panel in Admin → Authentication lets you say this group ⇒ this role: eng-leads ⇒ Admin, engineering ⇒ Developer. From then on, directory membership drives FortressFlag roles:

  • A person in several mapped groups gets the most senior mapped role.
  • Mapped members’ roles show as managed by your identity provider in the dashboard — the role control there is disabled, because your directory would just overwrite it.
  • Unmapped groups do nothing, and mapping never demotes below Viewer.

4. Require SSO — after everything works

Section titled “4. Require SSO — after everything works”

Back in Admin → Authentication, switch the organization’s policy to SSO. From here, password sign-in is off for everyone: the identity provider is the only door.

Flip this switch last, and read this first: once SSO is required, undoing it also requires a working SSO sign-in. If your identity provider breaks while SSO is required — an expired certificate, a deleted app — nobody can sign in, including you, and recovery is a support conversation rather than a settings page. So: confirm SSO sign-in works, confirm a second person can get in, then require it. (The dashboard also won’t let you require SSO before a connection exists, or delete a connection while SSO is required — the guardrails point the same direction.)

Where to next

Section titled “Where to next”