Inhaltsverzeichnis

 

SAML Übersicht

• Komponenten der SAML SSO Lösung.

• Use Cases.

• SAML Logischer Fluss.

• TOOLS.

• SAML Nachrichten.

• • SAML Authentifizierungsanforderung.

  • SAML Authentifizierungsantwort.

  • SAML Abmeldeanforderung.

  • SAML Protokoll-Antwort.

• IdP-Metadaten XML .

• SP Metadaten XML .

 

 

 

SAML Übersicht

 

Security Assertion Markup Language 2.0 (SAML 2.0) ist ein basierter Standard für den XML- Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Sicherheitsdomänen. SAML löst hauptsächlich zwei Anforderungen im Unternehmen: Webbasiertes Single Sign-On über mehrere Entitäten hinweg und Verbundidentität. Single-Sign-On wird erreicht durch den Austausch von Informationen zur Identität zwischen mehreren Organisationen und Anwendungen. Föderierte Identität ermöglicht eine Reihe von Dienstleistern zu vereinbaren eine Möglichkeit, auf einen einzelnen Benutzer zu verweisen, selbst wenn der Benutzer zu den Anbietern in verschiedenen Erscheinungsformen bekannt ist.

 

Komponenten der SAML SSO Lösung

 

In der Regel nehmen drei Entitäten an einer SAML Transaktion teil:

• Prinzipal (Benutzer)
• Dienstleister ( SP )
• Identitätsanbieter (IdP)

 

Der Dienstleister ist in der Regel die Anwendung oder Dienst, der Principal hat beantragte Zugang zu und der Identity Provider ist die Entität, die in die Identität steckt zu speichern, führt die Anmeldeinformationen des Benutzers. SAML definiert nicht die Techniken, die ein IdP verwenden kann, um den Benutzer zu authentifizieren, sondern konzentriert sich auf die Definition des Informationsaustauschs zwischen einem SP und einem IdP, um den Authentifizierungs- und Autorisierungsstatus des Prinzipals anzugeben. Dadurch kann IdP zusätzliche Authentifizierungstechniken (2FA/ MFA , zertifikatbasierte Authentifizierung...) verwenden, um den Benutzer zu authentifizieren. SAML Nachrichten verwenden XML als Datenaustauschformat und werden mit einer starken Anforderung übertragen, HTTP diese Nachrichten mit / ( SSL TLS HTTPS ) zu sichern.

 

SAML Assertion enthält Informationen über die Authentifizierung und den Benutzer. Die Behauptung enthält Informationen, die der Empfänger verwenden kann, um einen Zugriff Steuerelement Entscheidung zu treffen. Es gibt 3 Arten von Assertionsanweisungen:

 

• Die Authentifizierungsanweisung enthält Informationen wie Zeit und Methode, die zum Sicherstellen der Identität des Benutzers verwendet werden.

 

• Attributanweisung enthält Informationen über den Benutzer wie Benutzername, Telefonnummer, Adresse ... Etc.

 

• Die Autorisierungsentscheidungsanweisung bestätigt, ob der Benutzer berechtigt ist, auf eine angegebene Ressource zuzugreifen.

 

SAML verwendet Sicherheitstoken, die Assertionen enthalten, um Informationen über einen Prinzipal (in der Regel einen Endbenutzer) zwischen einer SAML Behörde, d. h. einem Identitätsanbieter, und einem SAML Consumer, d. h. einem Dienstanbieter, zu übergeben. Zum Beispiel behauptet der Identity Provider, dass dieser Benutzer authentifiziert wurde und damit verbundenen Attribute gegeben hat. In SAML werden Identitätsanbieter auch als SAML Behörden und Asserting Partiesbezeichnet. Dienstanbieter werden auch als "Relying Parties" bezeichnet – da sie sich auf Informationen eines Identitätsanbieters (Asserting Party) verlassen. Der Identitätsanbieter leitet Assertionen an den Assertion Consumer Service ( ) ACS URL weiter, und dieser Dienst überprüft die Assertionen, um sicherzustellen, ob der Endbenutzer berechtigt ist, Zugriff auf Anwendungen und andere Ressourcen zu erhalten. ACS URL ist wichtig, da URL der Dienstanbieter die Assertionen erhält und nutzt.

 

Die Kommunikations- oder Messagingprotokolle auf niedrigerer Ebene (z. B. HTTP oder ), über die die Nachrichten übertragen werden SOAP SAML können, werden durch Bindungen definiert. SAML Bindungen sind Hooks an einem Endpunkt, die diktieren, wie ein SP & ein IdP kommunizieren. Mit HTTP als Transport, typische Bindungen sind REDIRECT ( HTTP 302) und POST ( HTTP POST ). HTTP Redirect Binding: Definiert, wie SAML Protokollnachrichten mithilfe von HTTP Umleitungsnachrichten (302 Statuscodeantworten) transportiert werden können.  SAML Anforderungen oder Antworten, die über Redirect übertragen HTTP werden, verfügen über einen SAMLRequest- bzw. SAMLResponse-Abfragezeichenfolgenparameter. Vor dem Senden wird die Nachricht deflationiert (ohne Header und Prüfsumme), base64-codiert und URL- in dieser Reihenfolge codiert. Nach Erhalt ist der Prozess umgekehrt, um die ursprüngliche Nachricht wiederherzustellen. Sowohl SPs als auch IDPs können Nachrichten mithilfe von Umleitungs- oder Bindungen übertragen und POST empfangen. Aufgrund der Begrenzung der URL Längen in bestimmten Szenarien, HTTP Umleitung wird in der Regel verwendet, wenn kurze Nachrichten übergeben, und HTTP POST wird verwendet, wenn längere Nachrichten übergeben.

 

HTTP POST Bindung: Definiert, wie SAML Protokollnachrichten innerhalb des base64-codierten Inhalts eines Formularsteuerelements transportiert werden HTML können.

Palo Alto SP Networks-Endpunkte können Nachrichten nur SAML akzeptieren, wenn sie mit transportiert HTTP POST werden.

Eine weitere SAML Terminologie, die Sie kennen sollten, ist Metadaten. Es enthält Schema- und Endpunktinformationen über den IdP und den SP . Von jedem IdP und jedem SP idP wird erwartet, dass er über eigene Metadaten verfügt. Vertriebene und SPs in der Regel mit einander mit Metadaten zu registrieren. In der Regel enthalten Metadaten Informationen wie SSO URL , Denername und das Zertifikat, das den PKI "öffentlichen" Schlüssel enthält. Beispielsweise kann a SP diese Informationen verwenden, um einer Assertion zu vertrauen, die von einem IdP kommt, und umgekehrt. SAML 2.0 bietet ein klar definiertes, interoperables Metadatenformat, das Entitäten nutzen können, um den Vertrauensprozess zu booten. Metadaten, die vom IdP bereitgestellt werden, um SP Informationen über IdP (z. B. Entität ID , / SSO SLO URL ... usw.) und umgekehrt.

 

 

Verwendung von Fällen

 

SSO zu Captive Portal:

Kunden möchten unsere Funktion nutzen, um ein Captive-Portal zu starten, wenn ein Benutzer versucht, auf bestimmte HTTP- basierte Ressourcen zuzugreifen. Um zu verringern, dass sich ein Benutzer mehrmals anmelden muss, verlassen sich Kunden auf basisbasierte , wobei sich SAML- der Benutzer einmal bei seinem SSO IdP anmeldet und dann Zugriff auf jeden Dienstanbieter erhält, der bei demselben IdP registriert ist, solange der Benutzer alle erforderlichen Autorisierungsprüfungen besteht. Darüber hinaus verwenden diese Kunden auch das Captive-Portal, um Benutzer transparent zu identifizieren (User- ID ), wenn die /user-Zuordnung des Benutzers IP abgelaufen ist. Captive Portal kann auch verwendet werden, um einen bekannten Benutzer zu authentifizieren, die versucht, auf eine geschützte Ressource zuzugreifen. Diese Funktion bietet das erforderliche Maß an Sicherheit für den Administratoren und bietet eine einfache und unkomplizierte Oberfläche an die Endverbraucher. In einer Organisation können mehrere Anwendungen nutzen die gleichen IdP um den Benutzer zu authentifizieren. Sofern die Anwendungen und derselbe IdP zur Authentifizierung der Benutzer verwendet werden, erhält der Benutzer beim Zugriff auf diese Anwendungen und bei der SAML Authentifizierung eine konsistente Erfahrung.

 

SSO für GlobalProtect :

Kunden möchten SAML based SSO for GlobalProtect verwenden, damit diese Unternehmen eine einzige Architektur SAML für alle Anwendungen und für alle Benutzer auf allen Geräteplattformen verwenden SSO können. Da GlobalProtect läuft auf mehreren Plattformen, und da ist Plattform SAML agnostisch, SAML ist eine perfekte Wahl für Single Sign-On. GP Gateways und Portale fungieren als SAML Dienstanbieter und verschieben den Prozess der Identitätsbehauptung auf einen SAML Drittanbieter.

 

SSO für Firewall / Panorama GUI :

Firewall und Panorama Administratoren versuchen, auf den Administrator zuzugreifen, ohne sich GUI manuell bei ihm anmelden zu müssen. Wenn autorisierte Administratoren direkt auf unsere in einem Unternehmen zugreifen können, GUI das als Standard bereitgestellt SAML SSO wurde, wird der Fürstand der Benutzer für die Anmeldung reduziert und die firewall Panorama /, sich auf ein zentralisiertes Authentifizierungsmodul für die Identitätsbehauptung zu verlassen.

 

 

 

SAML Logischer Fluss

 

Im folgenden Beispiel wird die Authentifizierungsablauf für einen Benutzer mit captive Portal hervorzuheben. Es wird die Interaktion zwischen dem Benutzer, der Ressource firewall (Dienstanbieter) und dem IdP hervorgehoben. Der Authentifizierungsablauf ist für andere Endpunkte ähnlich SP (Admin UI , GlobalProtect Portal/Gateway, GlobalProtect Clientless SSL VPN )

 

 Authentifizierungsfluss

 

1. Der Benutzer stellt eine Anforderung an eine Ressource (entweder auf einem Dienstanbieter, z. Firewall Panorama GUI B. oder auf einem anderen Webserver – z. B. bing.com )
2. Wenn eine Anforderung an eine Ressource nicht an / ist Firewall Panorama GUI und wenn eine Authentifizierungsregel vorhanden Policy ist, wird sie ausgeführt und der Benutzer wird an ein captive Portal URL umgeleitet.
3. Der Browser des Benutzers greift auf das Captive Portal zu URL
4. Der Dienstanbieter erstellt ein AuthnRequest-Objekt, das angibt, wie der SP Benutzer authentifiziert werden soll. Die AuthnRequest ist codiert und wird über den Browser des Benutzers über die Methode "Redirect" an den HTTP POST HTTP Identitätsanbieter gesendet. Details zu SAML AuthnRequest, Response etc... werden in der zweiten Hälfte des Dokuments erläutert.
5. Wenn IdP zuvor der Benutzer authentifiziert hat, sendet der IdP ein Cookie, der den Benutzer identifiziert. Dieses Cookie wird im Browser gespeichert. Wenn der Benutzer mit der IdP, zusammen mit der AuthnRequest zuvor authentifiziert hat, wird Cookie im Browser gespeichert in Fortsetzung zum vorherigen Schritt (Schritt 4) auch an IdP per Browser des Benutzers gesendet. IdP prüft, ob es ein gültiges Cookie. Wenn ein gültiges Cookie nicht existiert, oder wenn ein Cookie nicht vorhanden ist, die IdP den Benutzer authentifiziert. IdP präsentieren Anmeldeanforderung an den Browser und basierend auf den Authentifizierungsmechanismus konfiguriert, wird der Benutzer authentifiziert werden. Beispielsweise kann eine einfache formularbasierte Authentifizierung konfiguriert werden, und ein LDAP Server kann abgefragt werden, um die Benutzersuche durchzuführen. Der Benutzer wird mit eine Anmeldeanforderung und im Browser, Benutzer Anmeldeinformationen eingibt und sendet sie zurück an IdP. Der IdP sendet die Anmeldeinformationen an den LDAP Server. LDAP Server überprüft die Anmeldeinformationen und sendet den Validierungsstatus an den IdP zurück.
6. Der IdP erstellt eine SAML Assertion, signiert sie mit ihrem privaten Schlüssel und leitet den Benutzer über die Methode einschließlich der Assertion zurück zum HTTP POST SAML Dienstanbieter. Unter Verwendung der in der Assertion bereitgestellten Informationen trifft der geeignete Entscheidungen, z. B. SP die Bereitstellung des Zugriffs des Benutzers auf die geschützte Ressource.
7. Der Dienstanbieter überprüft die SAML Assertion und XML signatur, die vom IdP bereitgestellt wird. Es extrahiert den Benutzernamen aus der SAML Assertion über die Benutzernamenattribute und überprüft den Benutzer und die Benutzergruppe mit der Zulassungsliste. Wenn Access Pass ankreuzt, wird die Ressource an den Browser zurückgegeben. Der Browser schließt die Verbindung mit Ressourcen wie bing.com

 

TOOLS

 

Es gibt einige DevTools, die auf den Browser geladen werden können (z. B. Chrome), die beim Debuggen von Nachrichten helfen SAML können. Einige der beliebten Chrome-Erweiterungen sind:

• SAML Chrome-Panel
• SAML DevTools-Erweiterung

 SAML DevTools-Erweiterung

 

 

 

SAML Nachrichten

 

SAML Authentifizierungsanforderung

 

AuthnRequest ist eine SAML Nachricht, die SP an IdP sendet, um die Authentifizierung zu initiieren. Diese Meldung ist Base64-codiert und die IdP an. Zusammen mit der Base64-codierten SAML Authnrequest wird ein Relaystate-Token an IdP gesendet. Relaystate-Token ist ein undurchsichtiger Bezeichner, der auf Statusinformationen verweist, die beim Dienstanbieter verwaltet werden. Dieses Token wird wieder von der IdP in ihrer Antwortnachricht widergehallt.

 

 

SAML AuthnRequest

Die wichtigen Elemente in der oben genannten AuthnRequest sind:

• Assertion Consumer Service URL
• Ziel URL
• Uhrzeit der Serveranfrage (Ausgabe instant)
• ID des Antrags
• Emittenten

 

Assertion Consumer ServiceURL ist die Adresse des Dienstanbieters, an die die Antwortnachricht vom IdP gesendet wird, nachdem eine Authentifizierung abgeschlossen ist.

 

Das Ziel URL wird vom IdP überprüft, um zu überprüfen, ob die Authentifizierungsanforderung tatsächlich für sie bestimmt ist. Dies ist nützlich, um zu verhindern, dass bösartige Weiterleitung von Anfragen an unerwünschte Empfänger.

 

Die Uhrzeit der Anforderung wird vom IdP überprüft, um zu überprüfen, ob die Anforderung nicht zu alt war.

IDder Anforderung ist eine generierte Zufallszahl, und es ist wichtig, dass sie mit der Antwort der Anforderung übereinstimmt.

 

Aussteller identifiziert die Entität, die die Anforderungsnachricht generiert hat. In der Regel enthält jede Anforderung und Antwort eine Entität ID des Absenders.

 

Andere Elemente, die beachtet werden müssen, sind die folgenden:

 

• Protokoll-Bindung
• Unterschrift
• Digest-Wert
• X509 Zertifikat

 

Protokollbindung ist der Verweis, der eine URI SAML Protokollbindung identifiziert, die beim Zurückgeben der Antwortnachricht verwendet werden soll.

 

Signatur und Digestwert werden verwendet, um die Nachrichtenintegrität der Anforderungs- und Antwortnachrichten sicherzustellen. Dieser Wert wird auf der empfangenden Seite mit derselben Digest-Methode (z. B. SHA1) überprüft und validiert, um die Integrität der Nachricht sicherzustellen.

 

X509-Zertifikat: In SAML tauschen der und der SP IdP den öffentlichen Zertifikatsschlüssel untereinander aus. Die Zertifikate dann installiert und explizit vertrauen. Um das Vertrauen des Ursprungs des Schlüssels zu etablieren, kann die Zertifizierungsstelle verwendet werden. Der öffentliche Schlüssel in der AuthnRequest oder Response-Nachricht enthalten ist der Partner darauf hin, dass die Entität mit den entsprechenden privaten Schlüssel die Nachrichten signiert. Es bestimmt nur, dass der Schlüssel der anderen Partei gehört.

 

Abb.: SAML AuthnRequest ( FW GUI und Chrome Dev Tool)

 

SAML AuthnRequest

Abb.: RelayState

 

RelayState

 

SAML Authentifizierungsantwort

 

Nachdem der IdP den Benutzer authentifiziert hat, erstellt er eine Base64-codierte Antwort und leitet sie an den SAML Dienstanbieter weiter.

Als Antwort auf die AuthnRequest sendet der IdP SP Status- und Sicherheitsassertionen an . Die Antwort wird Erfolgsstatus und Behauptungen enthalten, für den Fall, dass der Benutzer durch die IdP erfolgreich authentifiziert ist. Im Falle einer anderen Störung die Antwort enthält den Status unter Angabe der Gründe scheitern und keine Behauptungen enthält. IdP authentifiziert den Benutzer, und der SP ist an diesem Prozess nicht beteiligt. SP erhält nur den Status der Authentifizierung.

 

SAML Antwort 

 

Die meisten Elemente, die in der Antwort angezeigt SAML werden, ähneln denen, die unter AuthnRequest beschrieben werden. Diejenigen, die nicht in AuthnRequest fallen werden nachfolgend erläutert.

 

• Status
• Name ID
• Sitzung-Index
• Attribut-Anweisung und Attributwert
• Authentifizierung-Anweisung

 

Statuselement beschreibt, ob der Benutzer erfolgreich authentifiziert wurde oder nicht

 

NameID ist ein eindeutiger Bezeichner erstellt von IdP, der Lebenszyklus des Benutzerprinzipals/Sicherheits-Session nach einer erfolgreichen Authentifizierung Steuern (in diesem Fall IdP gilt als Session-Behörde)

 

Sitzungsindex ist der eindeutige Bezeichner, der von IdP erstellt wurde, um nachzuverfolgen, was SP der Benutzer/Prinzipal tut SAML SSO (in diesem Fall SP wird er als Sitzungsteilnehmer betrachtet).

 

Die Attributanweisung enthält Attribute, die einem Benutzer zugeordnet sind. Im obigen Beispiel wird der samAccountName des Benutzers vom IdP an SP gesendet.

 

Die Authentifizierungsanweisung enthält Informationen wie Zeit und Methode, die verwendet werden, um die Identität des Benutzers sicherzustellen.

 

Abb.: SAML Antwort FW GUI (und Chrome Dev Tool)

 

SAMLAntwort Abb: RelayState

 

RelayState

 

SAML Abmeldeanforderung

 

Wenn sich der Benutzer bei Firewall GUI abmeldet, erstellt der Dienstanbieter eine SAML Abmeldeanforderung, um die Benutzersitzung zu beenden. Die SLO Anforderung wird an den IdP gesendet. NameID und Sitzungsindex werden vom IdP verwendet und SP beenden die Benutzersitzung. Der IdP sendet idealerweise eine SLO Anforderung an alle anderen SP Anwendungen, bei denen sich der Benutzer angemeldet hat. Also, beim Anmelden des Benutzers aus einer Anwendung versucht die IdP der Benutzer aus anderen Anwendung anmelden.

 

SAML LogoutRequest

 

Wenn Redirect als Bindung für ausgewählt SAML HTTP SLO ist, wird die Signatur der SAML Abmeldeanforderung angezeigt, die SP im URL Antrag signiert GET ist.

 

Abb.: SAML LogoutRequest FW GUI (und Chrome Dev Tool)

 

SAML LogoutRequest

SAML Logout-Antwort

 

Für die SLO Anforderung, die von der an IdP gesendet SP wird, sendet IdP eine Protokollierungsantwort, die auf Erfolg oder Fehler hinweist. Die Reaktion wird durch die IdP unterzeichnet. Der SP führt die erforderlichen Bereinigungen durch, bevor der Benutzer protokolliert wird. Der SP wird Sitzungscookies löschen, die er für den Benutzer hat. Wenn der Benutzer das nächste Mal versucht, sich anzumelden, wurde der gesamte SAML Prozess erneut gestartet. Der SP kann auch Sitzungscookies für den Benutzer basierend auf dem Zeittimeout für den Sitzungsablauf löschen und den SAML Authentifizierungsprozess neu starten, wenn der Benutzer erneut versucht, auf die Anwendung zuzugreifen.

 

SAML LogoutResponse

 

Abb.: SAML LogoutResponse FW GUI (und Chrome Dev Tool)

 

SAML LogoutResponse

 

IdP-Metadaten XML

 

Die gemeinsame Nutzung von Vertrauen zwischen IdP SP kann durch die Metadaten leicht erleichtert werden.

Im SP Firewall Panorama IdP-Serverprofil ( oder ) kann mithilfe der bereitgestellten IdP-Metadatendatei erstellt XML werden. Die in den Metadaten bereitgestellten Informationen werden analysiert und im Panaroma oder in der Firewall Konfiguration gespeichert. IdP-Metadaten können folgende Informationen enthalten:

 

• IdP-Entität ID
• Idp SSO URL
• SSO Bindungsformat ( SAML HTTP Bindung – POST /Redirect)
• Idp SLO URL
• SLO Bindungsformat ( SAML HTTP Bindung – POST /Redirect)
• SAML Attribute
  • Benutzername-Attributname
  • Usergroup-Attributnamen
  • Admin-Rolle-Attributnamen
  • Zugang-Domain-Attribut-Namen
• IdP-signing-Zertifikat
• IdP WantAuthnRequestsSigned Flagge

 EntityDescriptor

 

SP Metadaten XML

 

SP Metadaten können aus dem SAML Authentifizierungsprofil von / exportiert Panorama Firewall werden.Wenn IdP eine Option SP zum Hochladenvonmet adatabietet, können die SP exportierten Metadaten in IdP hochgeladen und Die Anwendung einfach erstellt SAML werden. Wie bereits erwähnt, können Metadaten genutzt werden, um den Vertrauensprozess zu starten.

 

Die SP Metadaten können Folgendes enthalten:

 

• ACS URL
• ACS Bindungsformat
• SLO URL
• SLO Bindungsformat
• Entität ID
• Signaturzertifikat

 

EntityDescriptor