SAML 2.0 Einrichtung
Konfigurieren Sie Single Sign-On mit SAML 2.0 für Identitätsanbieter, die das SAML-Protokoll unterstützen. Diese Anleitung deckt die generische SAML-Einrichtung ab, die auf jeden konformen IdP anwendbar ist.
Voraussetzungen
- Ein SAML 2.0 konform Identitätsanbieter (Okta, Azure AD, OneLogin, PingFederate usw.)
- Administratorzugang zu Ihrem Identitätsanbieter, um Anwendungen zu erstellen und zu konfigurieren
- Ein SecureCodingHub Organisationsadministrator-Konto
Dienstanbieter-Details
Diese Werte werden benötigt, wenn Sie SecureCodingHub in Ihrem Identitätsanbieter konfigurieren:
| Einstellung | Wert |
|---|---|
| SP Entity ID | https://api.limeplate.com |
| ACS URL (Assertion Consumer Service) | https://api.limeplate.com/api/sch/auth/sso/callback/saml |
| SP Metadata URL | https://api.limeplate.com/api/sch/auth/sso/metadata |
| Name ID Format | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
| Binding | HTTP-POST |
Schritt 1 — Ihren Identitätsanbieter konfigurieren
Schritt 2 — SAML in SecureCodingHub konfigurieren
Schritt 3 — Test
Attributzuordnung
SecureCodingHub liest die folgenden Attribute aus der SAML-Behauptung:
| SAML-Attribut | SecureCodingHub-Feld | Erforderlich |
|---|---|---|
NameID (E-Mail-Format) | Ja | |
givenName (…/claims/givenname) | Name (erster Teil — zusammen mit Nachname zu einem einzigen Anzeigenamen verkettet) | Nein |
surname (…/claims/surname) | Name (zweiter Teil — wird zur Bereitstellungszeit mit givenName verbunden) | Nein |
Eine SAML-Antwort in der Praxis lesen
Wenn SAML fehlschlägt, ist der schnellste Weg zur Diagnose, die tatsächliche SAML-Antwort zu prüfen, anstatt das Symptom im Browser. Installieren Sie eine SAML Tracer Browser-Erweiterung, reproduzieren Sie die fehlgeschlagene Anmeldung und schauen Sie sich den POST an, den der IdP an die ACS URL sendet. Drei Felder sagen Ihnen fast alles. Das Issuer-Element sollte der entityID entsprechen, die in Ihren IdP-Metadata veröffentlicht ist. Das Audience-Element, das in Conditions verschachtelt ist, sollte der in SecureCodingHub konfigurierten SP Entity ID entsprechen. Die Subject NameID sollte die E-Mail-Adresse des Benutzers in dem von Ihnen angegebenen Format sein.
Über diese Felder hinaus prüfen Sie die InResponseTo-Kennung, wenn Ihr IdP es unterstützt, bestätigen Sie, dass die Antwort signiert ist (das ds:Signature-Element ist vorhanden), und verifizieren Sie, dass die NotBefore- und NotOnOrAfter-Zeitstempel mit der aktuellen Uhrzeit konsistent sind. Signifikante Uhrenabweichung zwischen IdP und SP verursacht stille Ablehnung sonst gültiger Behauptungen. Wenn die Antwort gut formatiert aussieht, die Behauptung aber dennoch abgelehnt wird, kopieren Sie den base64-kodierten SAMLResponse-Wert aus dem Tracer und dekodieren Sie ihn offline. Das Lesen des rohen XML gegen die SAML 2.0-Spezifikation ist der zuverlässigste Weg, ein fehlendes Attribut oder eine fehlkonfigurierte Aussage zu finden.
Wann das IdP-Team versus das SP-Team um Hilfe gebeten werden soll
Die meisten SAML-Support-Tickets können in unter einer Minute triagiert werden, wenn Sie wissen, auf welcher Seite der Föderation der Fehler liegt. Als Faustregel sind Audience- und Issuer-Diskrepanzen SP-seitige Probleme: Die SecureCodingHub-Konfiguration erwartet Werte, die der IdP nicht produziert, oder sie wurde gegen eine andere SP Entity ID konfiguriert als die, für die der IdP signiert. Diese werden durch Anpassen der SecureCodingHub SSO-Einstellungen oder der SP Entity ID und ACS URL in der IdP-Anwendungskonfiguration gelöst. Wenden Sie sich zuerst an die SecureCodingHub-Seite.
Claim- und Attributzuordnungsprobleme sind normalerweise IdP-seitig. Wenn Benutzer mit fehlenden Vornamen, falschen E-Mail-Adressen oder unerwarteten Rollenzuweisungen in SecureCodingHub landen, gibt der IdP Attribute aus, die der SP nicht konsumieren kann. Der IdP-Administrator muss Claims in der Anwendungskonfiguration hinzufügen oder umbenennen. Zertifikat- und Signaturfehler sind geteilt: Wenn das IdP-Zertifikat abgelaufen ist oder rotiert wurde, ist das eine IdP-seitige Korrektur. Wenn SecureCodingHub aufgehört hat, einer zuvor gültigen Signatur zu vertrauen, sind die auf der SP-Seite gespeicherten Metadaten oder Zertifikate veraltet und müssen aktualisiert werden. Im Zweifelsfall erfassen Sie die SAML Tracer-Ausgabe und teilen Sie sie mit beiden Teams; die Antwort selbst zeigt, welche Seite den nächsten Schritt besitzt. Siehe die SSO-Übersicht für Anleitung zur Protokollauswahl.
SAML 2.0: häufig gestellte Fragen
Was bedeutet "föderiertes SAML" eigentlich?
Föderiertes SAML bezieht sich auf die Vertrauensbeziehung, die zwischen einem Identitätsanbieter (IdP) und einem Dienstanbieter (SP) eingerichtet wird, sodass sich ein Benutzer einmal beim IdP authentifizieren kann und diese Behauptung vom SP akzeptiert wird. Die Föderation ist der signierte XML-Vertrag: Jede Seite vertraut den Metadaten und dem Signierungszertifikat der anderen. SecureCodingHub wird Teil Ihrer Föderation, sobald Sie die IdP-Metadaten hochladen und der IdP die SP Entity ID kennt.
Wie rotiere ich ein SAML-Zertifikat, ohne Anmeldungen zu brechen?
Eine SAML-Zertifikatsrotation wird am besten mit einem kurzen Überlappungsfenster durchgeführt. Wenn Ihr IdP die Veröffentlichung mehrerer Signierungszertifikate in den Metadata unterstützt, fügen Sie das neue Zertifikat hinzu, bevor Sie das alte zurückziehen, und lassen Sie SecureCodingHub die IdP-Metadata erneut abrufen, sodass beide Zertifikate während des Übergangs vertraut werden. Nachdem der IdP begonnen hat, mit dem neuen Schlüssel zu signieren, überwachen Sie Anmeldungen für einen Tag und entfernen Sie dann das alte Zertifikat aus den Metadata. Der häufigste Produktionsausfall ist das Rotieren ohne Überlappung an einem Freitag.
SAML vs OAuth vs OpenID Connect — welches wähle ich?
Wenn Teams SAML vs OAuth vs OpenID Connect vergleichen, lautet die praktische Antwort, dem operationellen Fit zu folgen. SAML 2.0 ist der reife, XML-basierte Föderationsstandard, dominant in Enterprise-IdPs wie ADFS und PingFederate. OAuth 2.0 allein ist ein Autorisierungsframework, keine Authentifizierung. OpenID Connect legt Identität über OAuth 2.0 und ist der moderne Standard für Azure AD und Okta. Sowohl SAML als auch OIDC geben Ihnen gleichwertige SSO-Sicherheit mit SecureCodingHub.
Wie dekodiere ich eine SAML-Antwort, um einen Fehler zu beheben?
Um eine SAML-Antwort zu dekodieren, erfassen Sie den base64-kodierten SAMLResponse-Parameter, den der IdP an die ACS URL postet — eine SAML Tracer-Browsererweiterung ist der einfachste Weg, ihn zu erfassen. Base64-dekodieren Sie den Wert in rohes XML und prüfen Sie Issuer, Audience, NameID und Zeitstempel. Die meisten Fehler werden gelöst, sobald Sie diese vier Felder mit den in den SecureCodingHub SSO-Einstellungen und der Anwendungskonfiguration Ihres IdP konfigurierten Werten vergleichen.