Salta ai contenuti

Connetti Okta

Se la tua azienda gira su Okta (o su un altro identity provider SAML), FortressFlag può affidargli del tutto l’accesso — e lasciare che la tua directory decida chi ha un account e quale ruolo ha. Questa guida collega i tre livelli nell’ordine che ti tiene connesso per tutto il tempo: prima l’SSO, poi il provisioning, poi la mappatura da gruppo a ruolo, e infine — quando tutto funziona — l’interruttore della policy.

Devi essere l’Owner sul lato FortressFlag, e un amministratore Okta sull’altro. FortressFlag parla SAML per l’accesso e SCIM 2.0 per il provisioning. (OIDC non è supportato.)

In Admin → Autenticazione, configura la connessione SSO: incolla i metadati del tuo identity provider, e FortressFlag ti restituisce i due valori che la configurazione dell’app SAML di Okta richiede — l’entity ID del service provider (l’URL dei suoi metadati) e l’ACS URL.

Crea un’app SAML in Okta con quei valori, assegnati a essa e prova l’accesso: la schermata di login della tua organizzazione acquisisce un percorso single sign-on accanto al modulo con la password. A questo punto l’SSO funziona ma non è richiesto — l’accesso con password funziona ancora, che è esattamente dove vuoi restare mentre fai le prove.

Sempre in Admin → Autenticazione, genera un token SCIM. Come una chiave SDK, viene mostrato una volta sola — copialo direttamente nella configurazione del provisioning di Okta come bearer token, e punta Okta al tuo endpoint SCIM di FortressFlag (il percorso /scim/v2 sul tuo indirizzo FortressFlag).

Con il provisioning attivo, Okta crea e rimuove gli account FortressFlag man mano che le persone entrano ed escono dalla tua directory:

  • Una persona creata dal provisioning parte come Viewer senza accesso ai progetti — sicuro per impostazione predefinita; da lì concedi tu (o lasci che lo faccia la mappatura dei gruppi, prossima sezione).
  • Il deprovisioning rimuove il suo accesso e la disconnette — l’offboarding nella tua directory è offboarding anche qui, sessioni incluse.
  • Le modifiche fatte dal provisioning compaiono nel log di audit attribuite al token di provisioning — le azioni della tua directory, registrate come tali.
  • Una salvaguardia: il provisioning non può mai rimuovere l’ultimo Owner della tua organizzazione.

Una nota su cui il tuo ufficio legale farà domande: le persone create dal provisioning non hanno mai visto un modulo di registrazione, quindi un amministratore accetta i termini di servizio per loro conto — la dashboard lo chiede, e l’accettazione viene registrata come qualsiasi altra.

Invia i tuoi gruppi Okta via SCIM, e il pannello mappatura dei gruppi in Admin → Autenticazione ti permette di dire questo gruppo ⇒ questo ruolo: eng-leads ⇒ Admin, engineering ⇒ Developer. Da quel momento, l’appartenenza alla directory guida i ruoli in FortressFlag:

  • Una persona in più gruppi mappati riceve il ruolo mappato più alto.
  • I ruoli dei membri mappati compaiono come gestiti dal tuo identity provider nella dashboard — il controllo del ruolo lì è disabilitato, perché la tua directory lo sovrascriverebbe comunque.
  • I gruppi non mappati non fanno nulla, e la mappatura non retrocede mai sotto Viewer.

Di nuovo in Admin → Autenticazione, imposta la policy dell’organizzazione su SSO. Da qui, l’accesso con password è disattivato per tutti: l’identity provider è l’unica porta.

Aziona questo interruttore per ultimo, e prima leggi questo: una volta che l’SSO è richiesto, anche annullarlo richiede un accesso SSO funzionante. Se il tuo identity provider si rompe mentre l’SSO è richiesto — un certificato scaduto, un’app eliminata — nessuno può accedere, te compreso, e il ripristino è una conversazione con il supporto invece di una pagina di impostazioni. Quindi: conferma che l’accesso SSO funziona, conferma che una seconda persona riesce a entrare, poi richiedilo. (La dashboard inoltre non ti lascia richiedere l’SSO prima che esista una connessione, né eliminare una connessione mentre l’SSO è richiesto — le salvaguardie puntano nella stessa direzione.)