Okta (OIDC) Einrichtung
Schritt-für-Schritt-Anleitung zur Konfiguration von Single Sign-On mit Okta mittels OpenID Connect.
Voraussetzungen
- Okta-Administratorkonto
- SecureCodingHub Organisationsadministrator-Konto
Schritt 1 — Eine Okta-Anwendung erstellen
Gehen Sie zu Okta Admin Console → Anwendungen → App-Integration erstellen
Anmeldemethode: OIDC
Anwendungstyp: Webanwendung
App-Name: SecureCodingHub
Anmelde-Weiterleitungs-URI: https://api.limeplate.com/api/sch/auth/sso/callback/oidc
Zuweisungen: Weisen Sie Ihren Benutzern/Gruppen zu
Schritt 2 — Anmeldedaten kopieren
Sammeln Sie die folgenden Werte aus Ihrer Okta-Anwendung:
| Einstellung | Wo zu finden |
|---|---|
| Client ID | Allgemein → Client-Anmeldedaten |
| Client Secret | Allgemein → Client-Anmeldedaten |
| Okta-Domain | Ihre Okta-URL (z.B. dev-12345.okta.com) |
| Discovery URL | https://{okta-domain}/.well-known/openid-configuration |
Schritt 3 — SSO in SecureCodingHub konfigurieren
Melden Sie sich als Organisationsadministrator an → SSO-Einstellungen
Protokoll: OIDC
Entity ID / Client ID: fügen Sie Ihre Okta Client ID ein
Discovery / Metadata URL: fügen Sie Ihre Okta OpenID-Konfigurations-URL ein
Client Secret: fügen Sie das Secret ein
SSO aktivieren
Klicken Sie auf Speichern
Schritt 4 — Test
Öffnen Sie ein Inkognito-/privates Browserfenster
Gehen Sie zur SecureCodingHub-Anmeldung
Geben Sie eine E-Mail-Adresse mit der Domain Ihrer Organisation ein
Sie sollten zur Okta-Anmeldung umgeleitet werden
Nach der Authentifizierung sollten Sie bei SecureCodingHub angemeldet sein
Häufige Okta SAML-Fallstricke
Obwohl diese Anleitung sich auf OIDC konzentriert, führen viele Okta-Tenants SecureCodingHub über SAML aus, und dieselben Okta-spezifischen Probleme treten immer wieder auf. Das erste ist eine Audience URI-Diskrepanz. Okta nennt dieses Feld Audience URI (SP Entity ID) in den SAML General Settings, und der Wert muss genau dem entsprechen, was SecureCodingHub als seine Entity ID veröffentlicht. Ein häufiger Fehler ist es, die SecureCodingHub-Website-URL anstelle der API Entity ID einzugeben. Überprüfen Sie den Wert gegen das SP Entity ID-Feld auf der SecureCodingHub SSO-Einstellungsseite, bevor Sie die Okta-Anwendung speichern.
Der zweite Fallstrick ist die Okta App Sign-On Policy. Okta wendet eine Richtlinie auf Anwendungsebene an, die zusätzliche Faktoren erfordern, nach Netzwerkzone einschränken oder den Zugriff basierend auf Gruppenmitgliedschaft vollständig verweigern kann. Wenn ein Endbenutzer meldet, dass SSO ihn zu Okta umleitet und ihn dann mit einem Zugriff-verweigert-Fehler zurückwirft, ist die Ursache fast immer eine App Sign-On Policy-Regel, die nicht zum Benutzer passt. Überprüfen Sie Sign On Policy unter der Anwendung und bestätigen Sie die Regel, die auf den Testbenutzer angewendet wird. Der dritte häufige Fallstrick ist nicht übereinstimmendes Name ID Format. Okta standardmäßig auf Unspecified, aber SecureCodingHub erwartet emailAddress-Format. Setzen Sie Name ID Format auf EmailAddress in den Anwendungseinstellungen und bestätigen Sie, dass das Quellattribut user.email oder user.login ist.
Wie Sie verifizieren, dass SSO End-to-End funktioniert
Die Verifizierung beginnt in einer Inkognito-Browsersitzung, um Cookies von vorherigen Anmeldungen zu vermeiden. Navigieren Sie zur SecureCodingHub-Anmeldeseite, geben Sie eine Unternehmens-E-Mail-Adresse mit Ihrer verifizierten Domain ein und bestätigen Sie, dass der Browser zu Ihrem Okta-Tenant umleitet. Nach der Authentifizierung bei Okta sollte die Umleitung Sie in SecureCodingHub auf dem Dashboard für die richtige Organisation landen lassen. Wenn Sie auf einer generischen Landing-Page oder einem 404 landen, ist die wahrscheinlichste Ursache, dass der Benutzer in SecureCodingHub noch nicht existiert und die JIT-Bereitstellung deaktiviert ist oder das Erstellungsereignis abgelehnt hat.
Verifizieren Sie zweitens die Rollen- und Sitzplatzzuweisung. JIT-bereitgestellte Benutzer landen immer mit der Rolle learner — SecureCodingHub liest heute keine Rollinformationen aus Okta-Gruppen-Claims, sodass die Beförderung zu org_admin aus der SecureCodingHub-Administrator-UI erfolgen muss, nachdem der Benutzer existiert. Melden Sie sich drittens ab und melden Sie sich dann erneut an. Die zweite Anmeldung sollte dank des Okta-Sitzungs-Cookies nahezu still sein. Wenn die zweite Anmeldung eine vollständige erneute Authentifizierung erzwingt, ist die Okta-Sitzungslebensdauer für den normalen Gebrauch zu kurz eingestellt; passen Sie die globale Sitzungsrichtlinie oder die Anwendungs-Sign-On-Policy entsprechend an. Für Protokoll-Details siehe die SAML-Einrichtungsanleitung.