Connectez Okta

Si votre entreprise fonctionne avec Okta (ou un autre fournisseur d’identité SAML), FortressFlag peut lui confier entièrement la connexion — et laisser votre annuaire décider qui a un compte et quel rôle il détient. Ce guide connecte les trois couches dans l’ordre qui vous garde connecté tout du long : le SSO d’abord, puis le provisionnement, puis le mappage des groupes vers les rôles, puis — une fois que tout fonctionne — l’interrupteur de politique.

Vous devez être l’Owner côté FortressFlag, et administrateur Okta de l’autre côté. FortressFlag parle SAML pour la connexion et SCIM 2.0 pour le provisionnement. (OIDC n’est pas pris en charge.)

1. Connectez le SSO

Dans Admin → Authentification, configurez la connexion SSO : collez les métadonnées de votre fournisseur d’identité, et FortressFlag vous rend les deux valeurs que la configuration de l’app SAML d’Okta demande — l’identifiant d’entité du fournisseur de service (son URL de métadonnées) et l’URL ACS.

Créez une app SAML dans Okta avec ces valeurs, assignez-vous à elle, et testez la connexion : l’écran de connexion de votre organisation gagne un chemin authentification unique à côté du formulaire de mot de passe. À ce stade, le SSO fonctionne mais n’est pas exigé — la connexion par mot de passe fonctionne encore, ce qui est exactement là où vous voulez rester pendant les tests.

2. Activez le provisionnement (SCIM)

Toujours sous Admin → Authentification, créez un jeton SCIM. Comme une clé SDK, il est affiché une seule fois — copiez-le directement dans la configuration de provisionnement d’Okta comme jeton bearer, et pointez Okta vers votre point de terminaison SCIM FortressFlag (le chemin /scim/v2 sur votre adresse FortressFlag).

Avec le provisionnement activé, Okta crée et supprime les comptes FortressFlag au fur et à mesure que les personnes rejoignent et quittent votre annuaire :

• Une personne provisionnée commence comme Viewer sans accès à aucun projet — sûr par défaut ; vous accordez à partir de là (ou laissez le mappage des groupes le faire, section suivante).
• Le déprovisionnement retire son accès et la déconnecte — l’offboarding dans votre annuaire est l’offboarding ici, sessions comprises.
• Les changements faits par le provisionnement apparaissent dans le journal d’audit attribués au jeton de provisionnement — les actions de votre annuaire, enregistrées comme telles.
• Un garde-fou : le provisionnement ne peut jamais retirer le dernier Owner de votre organisation.

Une note que votre équipe juridique vous demandera : les personnes créées par le provisionnement n’ont jamais vu de formulaire d’inscription, donc un administrateur accepte les conditions de service en leur nom — le tableau de bord vous y invite, et l’acceptation est enregistrée comme n’importe quelle autre.

3. Mappez les groupes vers les rôles

Poussez vos groupes Okta via SCIM, et le panneau mappage des groupes dans Admin → Authentification vous permet de dire ce groupe ⇒ ce rôle : eng-leads ⇒ Admin, engineering ⇒ Developer. À partir de là, l’appartenance à l’annuaire pilote les rôles FortressFlag :

• Une personne dans plusieurs groupes mappés reçoit le rôle mappé le plus élevé.
• Les rôles des membres mappés apparaissent comme gérés par votre fournisseur d’identité dans le tableau de bord — le contrôle de rôle y est désactivé, parce que votre annuaire l’écraserait de toute façon.
• Les groupes non mappés ne font rien, et le mappage ne rétrograde jamais en dessous de Viewer.

4. Exigez le SSO — après que tout fonctionne

De retour dans Admin → Authentification, basculez la politique de l’organisation sur SSO. À partir de là, la connexion par mot de passe est désactivée pour tout le monde : le fournisseur d’identité est la seule porte.

Actionnez cet interrupteur en dernier, et lisez ceci d’abord : une fois le SSO exigé, l’annuler exige aussi une connexion SSO qui fonctionne. Si votre fournisseur d’identité tombe en panne pendant que le SSO est exigé — un certificat expiré, une app supprimée — personne ne peut se connecter, vous compris, et la récupération est une conversation avec le support plutôt qu’une page de paramètres. Donc : confirmez que la connexion SSO fonctionne, confirmez qu’une seconde personne peut entrer, puis exigez-le. (Le tableau de bord ne vous laissera pas non plus exiger le SSO avant qu’une connexion existe, ni supprimer une connexion pendant que le SSO est exigé — les garde-fous pointent dans la même direction.)

Où aller ensuite

• Exigez l’authentification à deux facteurs — la politique plus légère, si le SSO est plus que ce dont vous avez besoin
• Rôles et sécurité — ce que ces rôles mappés accordent
• Invitez votre équipe — le chemin manuel, toujours là pour les prestataires hors de votre annuaire