Azure AD (OIDC) Einrichtung
Schritt-für-Schritt-Anleitung zur Konfiguration von Single Sign-On mit Microsoft Entra ID (Azure AD) mittels OpenID Connect.
Voraussetzungen
- Azure AD Tenant mit Administratorzugang
- SecureCodingHub Organisationsadministrator-Konto
- Organisationsdomain in SecureCodingHub verifiziert
Schritt 1 — Eine Anwendung in Azure AD registrieren
Gehen Sie zu Azure Portal → Microsoft Entra ID → App-Registrierungen → Neue Registrierung
Name: SecureCodingHub SSO
Unterstützte Kontotypen: Nur Konten in diesem Organisationsverzeichnis
Weiterleitungs-URI: Web → https://api.limeplate.com/api/sch/auth/sso/callback/oidc
Klicken Sie auf Registrieren
Schritt 2 — Ein Client Secret erstellen
Gehen Sie zu Zertifikate & Secrets → Neues Client Secret
Beschreibung: SecureCodingHub
Ablauf: Wählen Sie Ihre Richtlinie (empfohlen: 24 Monate)
Kopieren Sie den Secret-Wert sofort — er wird nur einmal angezeigt
Schritt 3 — Ihre IDs notieren
Sammeln Sie die folgenden Werte aus Ihrer Azure AD-Anwendung. Sie benötigen sie im nächsten Schritt.
| Einstellung | Wo zu finden |
|---|---|
| Anwendungs- (Client-) ID | Übersichtsseite |
| Verzeichnis- (Tenant-) ID | Übersichtsseite |
| Client Secret | Zertifikate & Secrets |
| Discovery URL | https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration |
Schritt 4 — SSO in SecureCodingHub konfigurieren
Melden Sie sich als Organisationsadministrator an → SSO-Einstellungen
Protokoll: OIDC
Entity ID / Client ID: fügen Sie Ihre Anwendungs-ID ein
Discovery / Metadata URL: fügen Sie Ihre OpenID-Konfigurations-URL ein
Client Secret: fügen Sie das Secret ein
SSO aktivieren
Klicken Sie auf Speichern
Schritt 5 — 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 Microsoft-Anmeldung umgeleitet werden
Nach der Authentifizierung sollten Sie bei SecureCodingHub angemeldet sein
Häufige Azure AD SAML-Fallstricke
Wenn SAML mit Azure AD anstelle von OIDC verwendet wird, machen drei Fehlermodi die meisten Produktionsvorfälle aus. Der erste ist eine nicht übereinstimmende Entity ID. Azure AD akzeptiert jeden String im Identifier-Feld des SSO-Blades, aber wenn er nicht genau mit der in SecureCodingHub konfigurierten SP Entity ID übereinstimmt, wird die SAML-Antwort mit einem Audience Restriction-Fehler abgelehnt. Kopieren Sie den Identifier direkt von der SecureCodingHub SSO-Einstellungsseite, tippen Sie ihn nicht ein. Abschließende Schrägstriche und Protokoll-Diskrepanzen (http vs. https) sind häufige stille Fehler.
Der zweite Fallstrick ist eine Diskrepanz im Claim Issuer URI. Azure AD signiert Behauptungen mit der Föderations-Metadata-URL, die er veröffentlicht, und SecureCodingHub validiert, dass der Issuer in der SAML-Antwort dem Issuer in den Metadata entspricht. Wenn Sie Tenants tauschen, Zertifikate neu generieren oder eine Metadata-URL von einer anderen Anwendung kopieren, divergiert der Issuer und jede Anmeldung schlägt mit einem Ungültige-Signatur-Fehler fehl. Der dritte Fallstrick ist die Gruppen-Claim-Größe. Azure AD kürzt Gruppen-Claims, wenn die Behauptung die maximale Nutzlast überschreitet, und ersetzt Gruppen durch eine Graph-Endpoint-Referenz. Wenn Sie sich auf Gruppen-Claims für nachgelagerte Rollenzuordnung verlassen, konfigurieren Sie Azure AD so, dass nur die der Anwendung zugewiesenen Gruppen ausgegeben werden, anstatt alle Gruppen, zu denen der Benutzer gehört.
Wie Sie verifizieren, dass SSO End-to-End funktioniert
Die End-to-End-Verifizierung hat drei Phasen. Öffnen Sie zuerst ein Inkognito-Fenster und starten Sie die Anmeldung von der SecureCodingHub-Anmeldeseite mit einer Unternehmens-E-Mail-Adresse. Der Browser sollte zu login.microsoftonline.com umleiten, die Microsoft-Anmeldeerfahrung präsentieren und dann zurück zu SecureCodingHub umleiten. Wenn die Rückumleitung fehlschlägt, erfassen Sie die URL-Leiste zum Zeitpunkt des Fehlers. Der Fehlercode im Query-String ist der nützlichste Beweis.
Bestätigen Sie zweitens, dass der Benutzer in der richtigen Organisation und im richtigen Dashboard landet. Eine erfolgreiche Anmeldung mit einer leeren Startseite oder einer falschen Organisationsumleitung weist normalerweise auf eine fehlende Organisations-Domain-Zuordnung hin. Drittens, melden Sie sich ab, melden Sie sich erneut an und verifizieren Sie, dass die zweite Anmeldung still oder nahezu still ist. Das Microsoft-Sitzungs-Cookie sollte den zweiten Ablauf nahezu unsichtbar machen. Wenn beide Anmeldungen eine vollständige erneute Authentifizierung erfordern, verwendet Ihre IdP-Anwendung eine Sitzungsrichtlinie, die die Wiederverwendung von Single-Sign-On-Cookies verhindert. Für gemeinsame Fehlerbehebungsschritte siehe die SAML-Einrichtungsanleitung.