SAML Konfiguration mit F5 APM

Hallo liebe Leser,

Federation ist ein Thema, dass ich immer wieder bei sehr vielen Kunden höre. Oft ist SAML ein wichtiger Bestandteil in Ausschreibung oder einfach nur eine wichtige Voraussetzung, dass sich Kunden für ein Produkt entscheiden. Mit der Version 11.3 hat F5 im Access Policy Manager die SAML Unterstützung sowohl als Service Provider als auch Identitiy Provider eingeführt. In der Praxis, obwohl so viele Kunden danach gefragt haben, wurde es meiner Erfahrung nach, aber zunächst gar nicht so oft eingesetzt. Inzwischen hat sich das geändert. In immer mehr Projekten kommt es zur Verwendung. Sowohl Partner als auch Kunden beschäftigen sich zunehmend, im Detail, mit dem Thema und der Konfiguration. Insbesondere liegt das sicher auch daran, dass APM in immer mehr Unternehmen als TMG Nachfolger verwendet wird und Federation in vielen Microsoft Produkten zur Anwendung kommt. Ein gutes, cloud basiertes, Beispiel ist hier sicher O365.

Ich denke, dass ist Gund genug, das Thema SAML heute einmal an einem Beispiel zu besprechen und zu konfigurieren. In der Hoffnung, dass es im „Feld“ hilft, mehr Verständnis für die Einstellungen zu bekommen.

Ziel soll es hierbei sein, den Zugriff auf eine Webseite (Service) durch eine vorgeschaltete Authentifizierung zu sichern. Die Authentifizierung findet dabei gegenüber dem Identity Provider statt, der nach erfolgreicher Anmeldung das entsprechende Token (Assertion) dem Client „mit gibt“, damit dieser auf die zugriffsgeschütze Webseite zugreifen darf.

Wie vorhin schon erwähnt, kann die BIG-IP hierbei beide Funktionen übernehmen: Service Provider und Identity Provider. Beide Funktionen können auf getrennten BIG-IPs laufen, oder auch auf der gleichen. -Das ist vollkommen egal.

Anschliessend werde ich in diesem Beispiel noch ein SSO (Form Based) auf den Backend-Server hinzufügen.

Aber fangen wir nun mit der Konfiguration an. Hier eine kurze Zusammenfassung der einzelnen Punkte, die wir konfigurieren müssen:

1. SAML SP (Service Provider)

2. SAML IdP (Identity Provider)

3. SAML External SP Connector (erstellt durch die exportierten Metadaten der SP)

4. SAML External IdP Connctor (erstellt durch die exportierten Metadaten des IdP)

5. SP Access Profile

6. IdP Access Profile

7. SP Virtual Server

8. IdP Virtual Server

Bevor wir beginnen, mache ich noch ein paar Anpassungen an meiner hosts Datei, da ich zum Testen das ganze ja „nur“ in meiner Lab-Umgebung aufsetze.

Hier füge ich nun folgende Zeilen hinzu:

10.10.81.50 idp.f5demo.com

10.10.81.60 app.f5demo.com

Hinter der ersten Zeile soll sich also nachher mein Identity Provider verbergen und hinter der zweiten meine zu schützende Applikation.

Das sowohl der Zugriff auf den SP als auch auf den IdP verschlüsselt erfolgen soll, erstelle ich nun die entsprechenden Self-Signed SSL Zertifikate:

Einmal für den Identity Provider

Und einmal für den Service Provider, hinter dem sich nachher meine Applikation verbirgt:

Als nächstes möchte ich die beiden virtuellen Server für den Service- und Identity Provider erstellen. Dafür benötige ich aber noch zwei SSL-Profile (Clientseitig), in denen ich die vorhin angelegten Zertifikate binde.

In meinem einfachen Fall, lasse ich alles auf Default-Werten und stelle nur den jeweils entsprechenden Key und Zertifikat ein.

Hier das SSL-Profil für den Service Provider:

Das SSL-Profil für den Identity Provider:

Jetzt folgt die Konfiguration der beiden virtuellen Server. Auch hier ist zunächst noch nichts besonderes zu tun. Sicher kennt jeder der Leser diesen Vorgang, daher fasse ich die Einstellungen nur kurz zusammen:

Für den Identiy Provider virtual Server:

vs_IDP

• Name
• IP
• Port (443)
• Protokoll TCP
  • Client: TCP-WAN-OPTIMIZED
  • Server: TCP-LAN-OPTIMIZED
• Default HTTP-Profile
• Client SSL-Profil (IDP_SSL)
• Kein Pool

In der TMSH sieht die Konfiguration bei mir dann so aus :

# list ltm virtual vs_IDP

ltm virtual vs_IDP {

destination 10.10.81.50:https

ip-protocol tcp

mask 255.255.255.255

profiles {

IDP_SSL {

context clientside

}

http { }

tcp-lan-optimized {

context serverside

}

tcp-wan-optimized {

context clientside

}

}

source 0.0.0.0/0

vs-index 20

}

Nun folgt der virtuelle Server für den Service-Provider, auch hier nur kurz zusammen gefasst:

vs_SP

• Name
• IP
• Port (443)
• Protokoll TCP
  • Client: TCP-WAN-OPTIMIZED
  • Server: TCP-LAN-OPTIMIZED
• Default HTTP-Profile
• Client SSL-Profil (SP_SSL)
• SNAT Automap
• Pool : pool_http (mit dem Backendserver, auf dem die Applikation läuft)

Auf Dinge wie Persistenz habe ich hier der Einfachheit wegen verzichtet. Es geht in diesem Blog ja vor allem um die SAML Konfiguration.

Meine Konfiguration sieht in der TMSH nun so aus:

# list ltm virtual vs_SP

ltm virtual vs_SP {

destination 10.10.81.60:https

ip-protocol tcp

mask 255.255.255.255

pool pool_http

profiles {

SP_SSL {

context clientside

}

http { }

tcp-lan-optimized {

context serverside

}

tcp-wan-optimized {

context clientside

}

}

source 0.0.0.0/0

source-address-translation {

type automap

}

vs-index 21

}

Im Browser rufe ich nun https://app.f5demo.com auf um zu testen, ob ich auf meine Applikation zugreifen kann, was auch funktioniert. –Prima, nun kann es also mit der SAML Konfiguration los gehen:

Ob ich zuerst den IdP oder den SP konfiguiere ist egal.

Ich beginne nun mit dem IdP:

Unter Access Policy / SAML /BIG-IP as IdP erstelle ich nun einen neuen IdP-Service:

In den „General Settings“ trägt man unter „Entity ID“ die URL mit dem FQDN ein, den man für den IdP virtuellen Server konfiguriert hat. In meinem Fall also https://idp.f5demo.com.

Unter „Assertion Settings“ wählen wir als „Assertion Type Value“ „%{session.logon.last.logonname}“ aus. Alles weitere lassen wir auf den Default Werten.

Jetzt kommen noch die Security Settings. Hier wählen wir das Zertifikat und den Key für den IdP aus, die wir vorhin angelegt haben.

Die „SAML Attributes“ lassen wir im ersten Fall erstmal weg, da wir sie zunächst nicht benötigen.

Anschliessend noch „OK“ drücken und weiter gehts mit der SP Konfiguration. J

Unter Access Policy / SAML / BIG-IP as SP erstelle ich nun SAML SP Service.

In den „General Settings“ trägt man unter „Entity ID“ die URL mit dem FQDN ein, den man für den SP virtuellen Server konfiguriert hat. In meinem Fall also https://app.f5demo.com.

Unter den Security Settings wähle ich „Signed Authentication Request“ und „Want Signed Assertion“ aus. Anschliessend dann noch das Zertifikat und den Key für den Service Provider. Beides haben wir ja zu Beginn erstellt.

Nun muss der der SP Connector erstellt werden. Hierfür verwenden wir dessen Metadaten und binden sie an den IdP.

Wir wählen hierfür unter Access Policy / SAML / BIG-IP as SP den gerade erstellen SP aus und klicken auf „Export Metadata“, damit wir diese runterladen können.

Jetzt gehen wir zu Access Policy / SAML / BIG-IP as IdP und wählen dort den Reiter „External SP Connectors“ aus. Unter „Create“ nun „From Metadata“.

Nun wählen wir die vorhin runter geladene Metadaten Datei aus und vergeben einen Namen.

Anschließend klicken wir auf „Edit“ um die Security Settings des Connector anzupassen: Hier wählen wir nämlich noch die „Must be encrypted“ Box unter „Assertion sent to SP by this device“ aus.

Jetzt klicken wir auf den Reiter „Local IdP Services“ und wählen den eben erstellen IdP aus. Anschließend wählen wir den den Menüpunkt „Bind/Unbind SP Connectors“ aus.

Jetzt können wir den IdP mit dem SP verheiraten.

Fertig. Jetzt fehlt noch die anderes Seite...

In dem Menü (Access Policy / SAML / BIG-IP as IdP) wählen wir nun wieder unseren angelegten IDP aus und exportieren dessen Metadaten durch klicken auf „Export Metadata“.

Nun konfiguieren wir wieder unseren SP (Access Policy / SAML / BIG-IP as SP) und wählen den Reiter „External IdP Connector“. Ein Klick auf „Create“ und in der Auswahl „From Metadata“ ermöglicht es uns nun das eben runter geladene IdP Metadaten-File zu importieren.

Nun klicken wir auf den Reiter „Local SP Services“. Wählen den SP aus, den wir gerade erstellt haben und klicken auf „Bind/Unbind IdP Connector“. Als nächsten drücken wir „Add new Row“ und können nun unseren IdP Connector auswählen.

Anschließend noch „Update“ und die Maske mit „OK“ verlassen.

Schon haben beide ihr „Ja-Wort“ zu „Hochzeit“ gegeben und wir können beginnen die Access Policies zu erstellen, die anschließend an die virtuellen Server gebunden werden.

Hierfür erstellen wir unter Access Policy / Access Profiles List eine neue Policy für den Service Provider.

Hier nehmen wir der einfach halt halber wieder die Standard-Werte und ergänzen die Policy um eine „logout.html“ Seite. Damit wir uns später auch abmelden können.

Nun editieren wir mit Hilfe des Visual Policy Editors die Access Policy und fügen als Authentication „SAML Auth“ hinzu. Der ensprechende AAA-Server wurde bereits beim Anlegen der SP-SAML Konfiguration angelegt und brauch nun nur noch ausgewählt zu werden.

Anschließend setzen wir den Successful-Branch noch auf „Allow“ und fertig.

Jetzt erstellen wir die Policy für den IdP.

Hierfür legen wir als erstes eine SAML Ressource an.

Access Policy / SAML / SAML Ressource. Wichtig ist hierbei, nicht die SSO Konfiguration zu vergessen. Hier wählen wir das SSO Profil aus, das automatisch beim anlegen des IDP Objektes erstellt wurde.

Nun erstellen wir einen Webtop, der unsere Ressource, oder auch vielleicht später auch die Ressourcen darstellt, wenn ein Client direkt den IdP ansteuert (IdP initiierte Verbindung).

Access Policy / Webtops / Create a Full Webtop

Nun können wir die IdP Policy erstellen. Bzw., zur Vorbereitung legen wir noch eine lokale User Database an, gegen die ich die Clients in dieser Demo authentifizieren möchte.

Hierfür legen wir unter Access Policy / Local User DB / Manage Instance eine neue Instanz an:

Unter Access Policy / Local User DB / Manage Users lege ich nun meine User an.

Nun haben wir alle Objekte, die wir für die Access Policy benötigen.

Als nächstes erstellen wir eine Access Policy für den SP. Hier nehmen wir wieder einfach die Default Werte. Im VPE fügen wir eine Logon Page hinzu, anschließend aus der Rubrik Authentication die Authentifizierung gegen die LocalDB_Auth mit der entsprechenden Instanz und im Successful Zweig ein Advanced Ressource Assign mit dem eben angelegten Webtop und der SAML-Ressource.

Das Ending wird dann noch auf Allow gestellt und fertig ist die Policy.

Jetzt brauchen wir nur noch die beiden Policies den jeweiligen virtuellen Server hinzu zu fügen und den ersten Tests steht nichts mehr im Wege.

Für den vs_IDP

Für den vs_SP

Ruft man nun im Browser https://app.f5demo.com auf, wird man zu https://idp.f5demo.com redirected und bekommt eine Login Seite zu sehen. Gibt man hier nun die richtigen Credentials an, wird man wieder zu https://app.f5demo.com weitergeleitet und bekommt die Seite des Backend-Servers zu sehen. Unsere Konfiguration ist also richtig.

Wie sieht es nun aber mit einem Single-Sign-On zu Backend-Server aus?

Ggf. muss man sich hier ja auch noch einmal anmelden. In meinem Beispiel hier, möchte ich die gleichen Credentials verwenden, die auch der IdP benötigt. Das bedeutet, der SAML Assertion, die der IdP mit sendet müssen wir nun noch Benutzername und Passwort hinzufügen, damit der SP diese Werte für das SSO verwenden kann. Gleiches gilt natürlich auch, wenn wir möglicherweise weitere Informationen des User, auf der Backend-Server Seite, bräuchten. Ein Szenario könnte ja durchaus sein, dass diese Daten in einem Active Directory hinterlegt sind. Der IdP könnte dann diese Daten aus den AD auslesen und ebenfalls mit der Assertion an den SP senden.

Zurück zu unserem Fall. Ich habe auf meiner Webseite eine Unterseite, auf die man nur kommt, wenn man sich vorher erfolgreich angemeldet hat. Also die Seite login.html, die einen Usernamen und ein dazugehöriges Passwort abfragt. Jetzt musss also ein SSO konfiguriert werden und im Vorfeld muss ich dem IdP noch sagen, dass er den Usernamen und das Passwort in der Assertion mitschicken soll. Genau damit fangen wir nun an:

In der IdP Access Policy fügen wir vor unserem Ressource Assign nun ein Credential Mapping hinzu.

Achtung, bitte nicht die „-secure“ Option vergessen. Das Passwort ist ist auf der Logon-Seite als Typ Passwort definiert und muss daher, wenn es verwendet wird auch die entschlüsselt werden. Genau das kann mit dem „-secure“ Parameter gemacht werden.

Somit sieht die Policy nun so aus:

Nun müssen wir der SAML-IdP Konfiguration noch mitteilen, welche Informationen die Assertion enthalten soll.

Das machen wir hier: Access Policy / SAML / BIG-IP as IdP / Ressource auswählen und diese dann editieren.

Unter SAML Attributes fügen wir nun den Usernamen und das Passwort hinzu (Add). Da wir die Attribute verschlüsselt übertragen wollen, setzen wir auch den Haken bei encrypt.

Auf der SP Seite werden die SAML Assertions in „SAML Variablen“ abgespeichert:

session.saml.last.attr.name.username

und

session.saml.last.attr.name.password

D.h. wir können mit diesen nun wieder arbeiten. –Wir fügen der SP-Policy nun auch ein Credential Mapping hinzu, dürfen dabei aber nicht wieder das –secure vergessen.

Somit sieht die Policy für den SP nun so aus:

Jetzt fehlt nur noch das SSO zum Backend-Server.

Ein Blick in den Source-Code der Login Seite zeigt uns die notwendigen Parameter:

„username“ und „password“

Diese verwenden wir nun um das Form based SSO-Objekt zu erstellen.

Nachdem dies getan ist, brauchen wir es nur noch der SP-Policy hinzuzufügen:

Nun können wir unsere Konfiguration erneut testen und tatsächlich es funktioniert. Nicht nur die Anmeldung an unserer Webseite durch die vorgeschaltet IdP-Authentifizierung, sondern auch das SSO zu unserer Backend-Login-Seite.

Ich hoffe die Anleitung hilft dabei, die ersten Schritte mit der BIG-IP und SAML erfolgreich umzusetzen. In meinem nächsten Blog werde ich noch ein paar weitere Debugging Tips geben, falls es denn doch noch zu Schwierigkeiten kommt, helfen diese hoffentlich.

Ihr F5-Blogger, Sven Müller