Single Sign On bei Outlook Web Access – Sicherheit- und Performancesteigerung inklusive

Hallo liebe Leser,

heute möchte ich gerne einen ersten typischen APM-Anwendungsfall vorstellen und konfigurieren.

Hierbei handelt es sich um ein Reverse-Proxy Szenario, dass man in sehr vielen Datacenters

vorfindet. Der Zugriff von extern (typischerweise Internet) auf Outlook-Web-Access.

Zunächst einmal stellt sich die Frage, wieso sollte ich einen Reverse-Proxy davor stellen? Die Antwort ist recht einfach: Sicherheit! Aber auch Performance!

Wann immer ich einen Dienst zur Verfügung stelle und das gilt insbesondere, wenn über das Internet auf diesen zugegriffen werden kann, ist dieser potentiell gefährdet. Die Motive der Angreifer können dabei ganz unterschiedlicher Natur sein. Für den Administrator gilt jedenfalls die Aufgabe, den Zugriff so sicher wie möglich zu gestalten. Erfolgt der Zugriff auf die Applikation personalisiert, dass heisst der Nutzer muss sich authentifizieren, so wird genau das, auf einem ReverseProxy durchgeführt. Schliesslich will man den Angreifer so früh wie möglich abfangen und dies eben auf einem entsprechenden gehärteten und dafür konzipierten „Box“. APM (Access Policy Manager) bietet uns sehr elegant eben genau die Möglichkeiten.

Bevor ich nun aber mit der Erstellung einer APM-Policy beginne, möchte ich eine ganz kurze Erläuterung des Prinzips der Konfiguration einer BIG-IP vorschieben.

Typischerweise konfiguriert man einen so genannten virtuellen Server (VS). Das ist im Grunde nichts spektakuläres, da er im einfachsten Fall nur aus einer IP-Adresse und einen Port besteht. Damit das Konstrukt auch überhaupt einen Sinn ergibt, zeigt dieser letztendlich auf eine Ressource, also z.B. einen Pool, indem sich die Backend-Server befinden. Der Pool definiert sich zumeist noch aus einem Verteil- und einem Persistenzverfahren, sowie einem Monitor zum Überwachen der Appliaktion auf den Servern. Damit haben wir eine wirklich einfache Konfiguration, die nicht viel mit Security und Performance zu tun hat. Eher entspricht es, ich wage es mal zu sagen, dem „alten, klassischen“ Loadbalancing. Heute wollen wir aber viel mehr: Applikationen müssen vor Angriffen geschützt werden und schnell Ihre Daten zum Client ausliefern. Damit wir diese Anforderungen erfüllen können, haben wir die Möglichkeit entsprechende Profile, die die unterschiedlichsten Themen adressieren, einem virtuellen Server zuzuweisen. So wird aus dem einfachen Konstrukt ein intelligenter und mächtiger Dienst.

Hier ein Bild, dass den Aufbau vielleicht ein wenig verständlicher macht.

Aus der Sicht von F5 konfigurieren wir übrigens auch keine virtuellen Server sondern Applikationen. Das soll bedeuten, dass wir die Sicht von weiter „oben“ haben. Natürlich sind es letztendlich die virtuellen Server mit deren Profilen, die verwendet werden. Aber heutzutage sind Applikationen oft so komplex, dass es hier nicht mit einem VS getan ist, sondern es gehören viele VS mit unterschiedlichen Eigenschaften zu einer Applikation und das ist ein ganz wichtiger Aspekt. Sehr deutlich wird dies beispielsweise, wenn man Applikationen mit Hilfe von iApps anlegt. Hier bekommt man anschließend die Hierarchie mit all ihren Ebenen angezeigt und in der Wurzel befindet sich der Applikationsname.

Zusammengefasst bedeutet dies nun für unseren Fall, in dem wir unseren OWA Zugriff durch eine vorgeschaltete Authentifizierung schützen wollen, eine APM-Policy erstellen, die anschließend dem virtuellen Server, als „Eigenschaft“, zugewiesen wird.

Was benötigen wir nun für diese Policy? Damit eine Authentifizierung gegen das Active Directory funktioniert, müssen wir dieses natürlich als Objekt anlegen.

Im Menü „Access Policy“ wählen wir hierfür unter „AAA Servers“ den Punkt „Active Directory“ aus.

Hier ist vor allem der Domain-Name wichtig, der bei Anfragen an das AD als Default-Realm immer an den Benutzernamen angehängt wird. Also z.B. sven.mueller@mydomain.de

Eine Frage, die ich immer wieder gestellt bekomme ist, ob man den Admin Name und das Passwort auch ausfüllen muss. Nein, wenn man nur überprüfen möchte, ob der User und das Passwort gültig ist, dann nicht. Möchte man aber Attribute, Gruppenrechte,... des Users abfragen, so benötigt man einen User, der berechtigt ist, diese Informationen abzufragen und genau den würde man in diese Feldern eintragen.

In unserem Beispiel nun, wollen wir nur eine Authentifizierung durchführen. Also reicht uns diese einfache Einstellung.

Natürlich wollen wir nicht, dass der Nutzer, wenn er sich erfolgreich authentifiziert hat und dann auf unseren OWA-Server zugreift, dort nocheinmal seine Credentials in das Webinterface eingeben muss. Um das zu verhindern, konfigurieren wir noch ein Single-Sign-On Objekt.

Ein „Klick“ auf Access Policy/SSO Configurations/Forms ermöglicht uns ein Form-Based SSO anzulegen:

Im Falle von OWA ist es sogar sehr einfach, die Konfiguration vorzunehmen, da sie bereits als Template abgelegt ist und man nur noch den Namen und das Ziel, also den OWA-Server eintragen muss.

Was aber, wenn es für die eigene Applikation kein Template gibt. Wie finde ich heraus, welche Felder und Parameter ich in die SSO-Konfiguration eintragen muss? Nun, ganz einfach, man weiss es ;-) oder man findet es heraus: Die BIG-IP macht ja nichts anderes als den gleichen Aufruf wie ein Benutzer. Das bedeutet, man schaut sich einfach an, was denn der Client zu dem Server schickt, wenn kein APM davor geschaltet ist.

Hierfür gibt es eine Reihe von nützlichen Tools, oder Browser-Plugins, die einem das schön darstellen. Ein Beispiel-Werkzeug ist HTTP-Watch. Diese starte ich einfach und melde mich an meiner Applikation an.

Okay und schon kann ich alles ausfüllen. Ich gehe mal kurz auf die Felder und deren Bedeutung ein.

Die Credentials Source: Alle Informationen, über den Client, Eingaben,.... werden beim APM in Variablen abgespeichert. Das macht es sehr flexibel, da man immer auf diese zugreifen, oder diese auch ändern kann, so wie man es eben benötigt. Genauso kann man sich aber auch eigene neue Variablen anlegen..

Hat man sich an einer Logon-Maske angemeldet, so steht in der Variablen „session.logon.last.username“ der eingegeben Username und in „session.logon.last.password“ das Passwort. Apropos Passwort, dieses kann man sich nicht anzeigen lassen. Es wird AES verschlüsselt mit einem Key der nicht auf der Box abgespeichert ist. Aber das nur am Rande, ohne weiter darauf einzugehen.

Jetzt könnten wir hier eben diese beiden Variablen einfach eingeben. Lassen wir die Default-Einstellung also „session.sso.token.last.username“ und „session.sso.token.last.password“, dann müssten wir diese vorher noch mit Inhalten füllen. Dafür verwenden wir im VPE (Visual Policy Editor) nachher das Objekt „SSO Credential Mapping“.

Start URI: Hier tragen wir die URI ein, die unser APM dazu veranlassen soll, dass der SSO-Prozess gestartet wird. HTTP-Watch sagt uns, dass es sich um eine POST-Request handelt. Naja und der richtet sich an: /owa/auth/owaauth.dll. Als Parameter werden „username“ und „passwort“ mit übertragen. Deren Werte werden aus unseren im „Credentials Source“ angegeben Variablen genommen. Aber dann sehen wir, dass ja noch eine Reihe weitere Parameter übertragen werden. Diese fügen wir einfach unter Hidden Form Parameters/Values hinzu. Hierbei bitte beachten, dass Parameter und Wert von einem Leerzeichen getrennt sind!

Hier kann man natürlich auch die Werte aus Variablen nehmen. Also könnte man z.B. schreiben: „domain %session.logon.last.domain“. Das bedeutet, dass dem POST der Parameter „domain“ mit dem Wert des Inhaltes aus der Variablen „session.logon.last.domain“ angefügt wird.

Unter Successful Logon Detection Match Type und Value teilen wir unserem APM mit, woran es erkennen soll, dass die Authentifizierung am Server erfolgreich war. Also z.B. durch eine Recirect URL auf https://owa.mydomain.de/owa/ …und Fertig ist schon unsere SSO-Form.

Nun setzen wir unsere Objekte mal in einer Access-Policy zusammen:

Dafür erstellen wir unter Access Profiles eine neue Policy mit z.B. dem Namen „OWA“. Wenn wir das Formular ausfüllen, dürfen wir nicht vergessen unter „SSO Configuration“ unser SSO-Objekt auszuwählen. Dann fehlt noch die Sprache und für einen ersten Test soll das auch schon reichen. Die Timeout-Werte kann man nachher noch individuell anpassen. Da wir mit HTTPS auf unseren virtuellen Server zugreifen werden, muss unter Cookie Options der Hacken „Secure“ ebenfalls gesetzt bleiben. Unter „Logout URI“ tragen wir die URI ein, die APM veranlassen würde die Session zu löschen, wenn diese aufgerufen wird. Fertig ist die Policy!

Aber im Moment würde sie niemanden auf den Backend-Server lassen, denn wenn wir nun den Visual Policy Editor (VPE) aufrufen, sehen wir, dass jeder Aufruf in ein „Deny“ läuft.

Also erweitern wir die Policy ein wenig. Als erstes soll ein nicht angemeldeter User eine Logon Page bekommen. Durch ein „klick“ auf das Plus-Zeichen können wir eine Logon Page hinzufügen. Für unseren Fall reichen die „default“-Einstellungen. Eine Bemerkung aber noch zu den „Post“ und „Session“- Variable Name. Hier kann man bestimmen, wie die Variablen heissen sollten, also was vom Browser gesendet (Post) werden soll und unter welchem Variablen Namen die Information auf dem APM abgespeichert werden sollen.

Natürlich kann man auch weitere Felder hinzufügen. Sehr oft sieht man hier dann noch das Feld „Token“ für ein OneTimePasswort oder ähnliches.

Zurück zur unserer Policy....Wenn wir nun also die Logon-Page hinzugefügt haben, müssen wir die vom User beim Aufruf der Seite eingegeben Credentials von unserem AD überprüfen lassen. Also nach der Logon-Page wieder ein „klick“ auf das Plus-Zeichen und „AD Auth“ unter Authentication auswählen. Unter Server nehmen wir nun unser zu Beginn angelegten Active-Directory Server. Alle anderen Optionen lassen wir so.

Jetzt sehen wir zwei „Endings“. Im Moment stehen beide noch auf „Deny“. Für den oberen Zweig ändern wir dies nun auf „Allow“, schließlich kommt der User ja nur dort hin, wenn unser AD „sagt“, dass die Eingabe von Username und Passwort richtig war.

Also klicken wir auf „Deny“ und ändern es auf „Allow“.

Jetzt sind wir fast fertig, dürfen aber nicht vergessen, dass unser „SSO Credential Mapping“ noch fehlt, denn schließlich haben wir in unserer SSO-Konfiguration die „default“-Werte gelassen. Also entsprechendes Objekt mit „Plus“ hinzufügen und fertig.

Hier sehen wir auch schön, dass mit „mcget {session.logon.last.username}“ der Inhalt an unser SSO Token Username übergeben wird. Hier könnten wir auch auf beliebige andere Variablen zugreifen.

So sieht nun unsere Policy aus:

Jetzt dürfen wir nur nicht vergessen, diese zu „applyen“. Dafür klicken wir einfach auf den oben links, gelb leuchtende „Apply Access Policy“ Schriftzug. Das muss man übrigens immer machen, wenn man etwas an der Policy ändert. Vergisst man gerne mal.... die Änderungen gelten natürlich immer nur für neue Sessions. Das heisst manchmal ist es hilfreich unter „Manage Sessions“ im APM Menü die entsprechende Session zu löschen.

Damit die Policy aber überhaupt Verwendung findet, müssen wir diese natürlich noch dem virtuellen Server für unser OWA hinzufügen. Fertig!

Jetzt haben wir unsere erste APM-Policy erstellt, die User über eine Login-Seite nach den Credentials fragt und die eingegebenen Daten an ein Active Directory zur Überprüfung weiterreicht.

Sofern diese korrekt sind, wird ein SSO an die Backend-Server durchgeführt, damit der User hier nicht ein weiteres Mal seine Daten eingeben muss.

Ich hoffe das Beispiel hilft Ihnen, auch bei anderen Applikationen, eine Policy mit Form-based SSO durchzuführen.

Ihr F5-Blogger, Sven Müller