Nachdem in einem vorherigen Blogeintrag (Wildfly SSO mit Keycloak (SAML,Oauth)) erklärt wurde wie Keycloak genutzt werden kann, soll in diesem Post darauf eingegangen werden wie SSO mit Hilfe von PicketLink realisiert werden kann.
Während Keycloak eine Out-Of-The-Box-Lösung für Security ist, welche auf PicketLink basiert, kann mit PicketLink die Security eigenständig in ein Projekt implementiert werden. PicketLink ist nicht nur ein Framework für SSO sondern bietet auch verschiedene andere Security-Lösungen für REST, LDAP-Anbindungen und vieles mehr.
Zur Beispielhaften Darstellung werden drei Applikationen herangezogen. Der Identity Provider, welcher die Authentifizierung durchführt und zwei Service Provider (SP) auf die nach einmaligen einloggen zugegriffen werden kann. Momentan läuft dieses Projekt nur in einem WildFly 9, die Grundkonfiguration von diesem ist in der GitHub README dieses Projektes beschrieben. Zusätzlich ist dort beschrieben wie PicketLink in den WildFly installiert wird.
Konfiguration der Security-Domains für den WildFly 9
Um SSO mit PicketLink zu realisieren, müssen zu Beginn zwei neue Security-Domains im WildFly eingerichtet werden.
Die erste Security-Domain legt fest wie die Authentifizierung im Identity Provider durchgeführt werden soll. Der Einfachheit werden hier Property-Files verwendet. Alternativ könnten hier auch eine Datenbank, LDAP o.a. verwendet werden.
Die Property-Dateien für die Benutzer und Rollen müssen defaultmäßig in dem resources-Ordner des Identity Provider Projektes abgelegt sein.
Die Security-Domain für die Service Provider legt das von PicketLink verwendete Login-Modul fest.Damit Der Application-Server das Authentifizieren über SAML-Assertions unterstützt und diese auflösen kann.
Erstellen eines Identity Providers
Für den Identity Provider wird ein normales Java-EE-Projekt angelegt. Dieses Projekt muss folgende Deskriptoren im WEB-INF-Order zur Konfiguration enthalten:
- jboss-deployment-structure.xml
- jboss-web.xml
- picketlink.xml
Die Dependency des PicketLink-Moduls muss über die jboss-deployment-structure.xml in das Projekt eingebunden werden damit der Application-Server mit PicketLink arbeiten kann.
In der jboss-web.xml wird festgelegt, welche Security-Domain genutzt werden soll. In diesem Fall ist es die Security-Domain mit dem Namen “idp”, die vorher im WildFly konfiguriert wurde.
Das oben zu sehende Bild zeigt die picketlink.xml. Mit dem Tag <IdentityURL> wird festgelegt über welche URL der Identity Provider angesprochen werden bzw. wo sich der Kontextpfad zur Anwendung auf dem Application Server befindet. In dem <Trust>-Tag können mehrere Domains angegeben werden, diese werden von dem Identity provider als vertrauenswürdig eingestuft. Zusätzlich können verschiedene Handler definiert werden. In diesem Fall sind es Handler, die PicketLink von Haus aus bereit stellt und die für die SAML Authentifizierung genutzt werden können. Darunter befindet sich z.B. der SAML2LogoutHandler, dieser gewährleistet die Möglichkeit von SLO (Single LogOut). SLO ist das Gegenteil von SSO, sodass sich durch einen Logout-Vorgang von allen Applikationen abgemeldet werden kann. Das <PicketLinkSTS>-Tag, das hier nicht mit abgebildet ist, kann genutzt werden um beispielsweise ein Token-Timeout oder Verschiedene Token-Provider festzulegen.
Zum Schluss müssen Anpassungen an der web.xml durchgeführt werden. Die Security-Constraints und Security-Roles werden wie üblich konfiguriert. Auch die Login-Konfiguration ist eine normale Form-Based Authentication. Deshalb wird an diesem Punkt nur auf die PicketLink spezifischen Änderungen eingegangen.
In der web.xml wird der IDPHttpSessionListener definiert. Zudem wird noch der IDPFilter und dessen Filter-Mapping festgelegt.
Erstellen eines Service Providers
Das Erstellen eines Service Providers funktioniert so problemlos wie das Erstellen eines Service Providers. Auch der Service Provider benötigt folgende Deskriptoren:
- jboss-deployment-structure.xml
- jboss-web.xml
- picketlink.xml
Zudem muss in dem Ordner WEB-INF/classes/META-INF/services die Datei “io.undertow.servlet.ServletExtension”mit dem oben abgebildeten Inhalt vorhanden sein. Dies sorgt dafür, dass PicketLink seine eigene ServletExtension nutzt.
Die jboss-deployment-structure.xml hat den selben Inhalt wie schon bei dem Identity Provider. Auch hier wird lediglich die Dependency zum PicketLink-Modul angegeben .
Auch die jboss-web.xml unterscheidet sich kaum, es wird lediglich die Security-Domain der Service Provider angegeben.
Die picketlink.xml nutzt bei den Service Providern das Tag <PicketLinkSP> hier stehen zwei weitere Attribute zur Verfügung. Mit ErrorPage kann festgelegt werden wohin weitergeleitet wird, wenn eine Authentifizierung scheitert. LogOutPage hingegen bestimmt wohin nach einem Logout navigiert wird. Werden diese beiden Konfigurationen nicht vorgenommen wird zu den Seiten /error.jsp bzw. /logout.jsp navigiert. Zwischen den IdentityURL-Tags wird die URL zum Identity Provider angegeben, der für die Authentifizierung genutzt werden soll. Zu dieser URL wird beim Zugriff auf einen SP weitergeleitet, wenn noch keine Authentifizierung durchgeführt wurde. Die darauf folgende ServiceURL gibt den Kontext-Pfad des Service Providers an. Der Rest der picketlink.xml ist identisch mit der des Identity Providers. Ein <PicketLinkSTS>-Tag zur weiteren Konfiguration wie bei einem Identity Provider steht nicht zur Verfügung.
In der web.xml des Service Providers muss die login-config ebenfalls vorhanden sein. Außerdem können in der web.xml die Security-Constraints des jeweiligen Service Providers konfiguriert werden. Ansonsten befinden sich hier keine PicketLink spezifischen Definitionen.
Es ist zu sehen, dass es außer ein wenig Aufwand kein Hexenwerk ist seinen eigenen Identity Provider zu erstellen und verschiedene Service Provider mit SSO zu versehen.
Leider ist die Frage wie es momentan mit PicketLink weiter geht nicht ganz klar. PicketLink soll in nächster Zeit mit Keycloak gemerged werden, dass PicketLink Projekt soll dennoch als Branch weiter bestehen und kann von der Community weiterentwickelt werden. Red Hat will aktiv nicht an diesem Branch weiterentwickelt, wollen der Community aber mit Rat und Tat zur Seite stehen. Evtl. könnte nach dem Merge auch die PicketLink API aus Keycloak nutzbar sein, doch dazu gibt es noch keine weiteren Informationen.
Lassen wir uns überraschen.
Das komplette Beispiel-Projekt mit einem Identity Provider und zwei Service Providern kann unter https://github.com/GEDOPLAN/sso-picketlink-saml-demo betrachtet werden.
