Configuration Okta (OIDC)
Guide pas-à-pas pour configurer l'authentification unique avec Okta en utilisant OpenID Connect.
Prérequis
- Compte administrateur Okta
- Compte administrateur d'organisation SecureCodingHub
Étape 1 — Créer une application Okta
Allez dans Okta Admin Console → Applications → Create App Integration
Méthode de connexion : OIDC
Type d'application : Web Application
Nom de l'app : SecureCodingHub
URI de redirection de connexion : https://api.limeplate.com/api/sch/auth/sso/callback/oidc
Attributions : attribuez à vos utilisateurs/groupes
Étape 2 — Copier les identifiants
Collectez les valeurs suivantes depuis votre application Okta :
| Paramètre | Où trouver |
|---|---|
| Client ID | General → Client Credentials |
| Client Secret | General → Client Credentials |
| Domaine Okta | Votre URL Okta (par exemple dev-12345.okta.com) |
| URL de découverte | https://{okta-domain}/.well-known/openid-configuration |
Étape 3 — Configurer SSO dans SecureCodingHub
Connectez-vous en tant qu'Administrateur de l'organisation → Paramètres SSO
Protocole : OIDC
Entity ID / Client ID : collez votre Okta Client ID
URL Discovery / Metadata : collez votre URL de configuration OpenID Okta
Client Secret : collez le secret
Activer SSO
Cliquez sur Enregistrer
Étape 4 — Tester
Ouvrez une fenêtre de navigateur incognito/privée
Allez à la connexion SecureCodingHub
Saisissez une adresse e-mail avec le domaine de votre organisation
Vous devriez être redirigé vers la connexion Okta
Après l'authentification, vous devriez être connecté à SecureCodingHub
Pièges SAML Okta courants
Bien que ce guide se concentre sur OIDC, de nombreux tenants Okta exécutent SecureCodingHub sur SAML, et les mêmes problèmes spécifiques à Okta reviennent. Le premier est une non-correspondance d'URI d'audience. Okta appelle ce champ Audience URI (SP Entity ID) dans les paramètres généraux SAML, et la valeur doit correspondre exactement à ce que SecureCodingHub publie comme entity ID. Une erreur courante est de saisir l'URL du site web SecureCodingHub plutôt que l'entity ID de l'API. Vérifiez la valeur par rapport au champ SP Entity ID dans la page des paramètres SSO SecureCodingHub avant d'enregistrer l'application Okta.
Le deuxième piège est la politique de connexion d'application Okta. Okta applique une politique au niveau de l'application qui peut nécessiter des facteurs supplémentaires, restreindre par zone réseau ou refuser entièrement l'accès en fonction de l'appartenance à un groupe. Si un utilisateur final signale que SSO les redirige vers Okta puis rebondit avec une erreur d'accès refusé, la cause est presque toujours une règle de politique de connexion d'application qui ne correspond pas à l'utilisateur. Vérifiez Sign On Policy sous l'application et confirmez la règle qui s'applique à l'utilisateur de test. Le troisième piège courant est un format Name ID non correspondant. Okta utilise Unspecified par défaut, mais SecureCodingHub attend le format emailAddress. Définissez le format Name ID sur EmailAddress dans les paramètres de l'application et confirmez que l'attribut source est user.email ou user.login.
Comment vérifier que SSO fonctionne de bout en bout
La vérification commence dans une session de navigateur incognito pour éviter tout cookie des connexions précédentes. Naviguez vers la page de connexion SecureCodingHub, saisissez une adresse e-mail d'entreprise avec votre domaine vérifié et confirmez que le navigateur redirige vers votre tenant Okta. Après l'authentification chez Okta, la redirection devrait vous amener à SecureCodingHub sur le tableau de bord de la bonne organisation. Si vous atterrissez sur une page d'accueil générique ou un 404, la cause la plus probable est que l'utilisateur n'existe pas encore dans SecureCodingHub et que le provisionnement JIT est désactivé ou a rejeté l'événement de création.
Deuxièmement, vérifiez l'attribution de rôle et de siège. Les utilisateurs provisionnés JIT atterrissent toujours avec le rôle learner — SecureCodingHub ne lit pas les informations de rôle depuis les revendications de groupe Okta aujourd'hui, donc la promotion vers org_admin doit être faite depuis l'interface admin SecureCodingHub après que l'utilisateur existe. Troisièmement, déconnectez-vous, puis reconnectez-vous. La deuxième connexion devrait être quasi-silencieuse grâce au cookie de session Okta. Si la deuxième connexion force une ré-authentification complète, la durée de vie de la session Okta est définie trop courte pour une utilisation normale ; ajustez la politique de session globale ou la politique de connexion d'application en conséquence. Pour les détails au niveau du protocole, voir le Guide de configuration SAML.