Ga naar inhoud

Koppel Okta

Draait je bedrijf op Okta (of een andere SAML-identityprovider), dan kan FortressFlag het aanmelden er volledig aan overdragen — en je directory laten bepalen wie een account heeft en welke rol die persoon houdt. Deze handleiding verbindt de drie lagen in de volgorde die je de hele tijd aangemeld houdt: eerst SSO, dan provisioning, dan groep-naar-rol-mapping, en dan — zodra alles werkt — de beleidsschakelaar.

Je moet aan de FortressFlag-kant Owner zijn, en aan de andere kant Okta-admin. FortressFlag spreekt SAML voor aanmelden en SCIM 2.0 voor provisioning. (OIDC wordt niet ondersteund.)

Stel in Admin → Authentication de SSO-verbinding in: plak de metadata van je identityprovider, en FortressFlag geeft je de twee waarden terug waar de SAML-appsetup van Okta om vraagt — het serviceprovider-entity-ID (zijn metadata-URL) en de ACS-URL.

Maak in Okta een SAML-app met die waarden, wijs jezelf eraan toe, en test het aanmelden: het aanmeldscherm van je organisatie krijgt een single sign-on-pad naast het wachtwoordformulier. Op dit punt werkt SSO maar is het niet vereist — aanmelden met wachtwoord functioneert nog, en dat is precies waar je wilt blijven zolang je test.

Munt, ook onder Admin → Authentication, een SCIM-token. Net als een SDK-sleutel wordt hij één keer getoond — kopieer hem direct naar Okta’s provisioningconfiguratie als bearer token, en wijs Okta naar je FortressFlag-SCIM-endpoint (het /scim/v2-pad op je FortressFlag-adres).

Met provisioning aan maakt en verwijdert Okta FortressFlag-accounts terwijl mensen je directory in- en uitgaan:

  • Een geprovisioneerd persoon start als Viewer zonder projecttoegang — veilig als standaard; jij kent van daaruit toe (of laat groepsmapping het doen, volgende sectie).
  • Deprovisioning haalt de toegang weg en meldt de persoon af — offboarden in je directory is offboarden hier, sessies inbegrepen.
  • Wijzigingen door provisioning verschijnen in het auditlog toegeschreven aan het provisioningtoken — de acties van je directory, als zodanig vastgelegd.
  • Eén vangrail: provisioning kan nooit de laatste Owner van je organisatie verwijderen.

Een notitie waar je juridische team naar zal vragen: mensen die via provisioning worden aangemaakt hebben nooit een aanmeldformulier gezien, dus een beheerder accepteert de dienstverleningsvoorwaarden namens hen — het dashboard vraagt hierom, en de acceptatie wordt vastgelegd als elke andere.

Push je Okta-groepen over SCIM, en het groepsmapping-paneel in Admin → Authentication laat je zeggen: deze groep ⇒ deze rol: eng-leads ⇒ Admin, engineering ⇒ Developer. Vanaf dan stuurt directorylidmaatschap de FortressFlag-rollen:

  • Iemand in meerdere afgebeelde groepen krijgt de meest seniore afgebeelde rol.
  • De rollen van afgebeelde teamleden tonen als beheerd door je identityprovider in het dashboard — het rolbedieningselement is daar uitgeschakeld, omdat je directory het toch zou overschrijven.
  • Niet-afgebeelde groepen doen niets, en mapping degradeert nooit onder Viewer.

Zet, terug in Admin → Authentication, het beleid van de organisatie op SSO. Vanaf hier staat aanmelden met wachtwoord voor iedereen uit: de identityprovider is de enige deur.

Zet deze schakelaar als laatste om, en lees dit eerst: zodra SSO vereist is, vraagt het ongedaan maken ervan óók een werkende SSO-aanmelding. Breekt je identityprovider terwijl SSO vereist is — een verlopen certificaat, een verwijderde app — dan kan niemand zich aanmelden, ook jij niet, en is herstel een supportgesprek in plaats van een instellingenpagina. Dus: bevestig dat SSO-aanmelden werkt, bevestig dat een tweede persoon binnenkomt, en vereis het dan pas. (Het dashboard laat je SSO ook niet vereisen voordat er een verbinding bestaat, of een verbinding verwijderen terwijl SSO vereist is — de vangrails wijzen dezelfde kant op.)