Als Identity und Accessmanagement Engineer habe ich schon die eine oder andere Federated Authentication eingerichtet. Dabei gibt es einige mögliche Ursachen, weshalb die Authentifizierung in der Applikation nicht klappt. Eine häufige davon ist, dass die Assertion falsche, fehlende oder nicht richtig formattierte Claims enthält. Um dies zu debuggen gibt es verschiedene Möglichkeiten wie zum Beispiel ClaimsXRay von Microsoft, OpenID Connect debugger von Nate Barbettini oder die Browser Erweiterung SAML-tracer. Da ich ohnehin etwas tiefer in die Materie von SAML/OIDC/OAuth2 einsteigen wollte habe ich mich dazu entschlossen selber einen Microservice zum Visualisieren von Claims zu erstellen. Als Programmiersprache entschied ich mich für Go, weil ich mein Wissen darin ebenfalls vertiefen möchte und sie für mich schon fast der de facto Standart für Web Services, insbesondere Microservices geworden ist.
In einer ersten Version habe ich auf existierende Module für SAML und OIDC von anderen Entwicklern zurückgegriffen. Dadurch konnte ich mich vor allem auf den Flow und das Session Handling konzentrieren, welche integrale Bestandteile der Authentifizierung sind. Bei diesem Projekt handelt es sich um eine überschaubare Grösse und darum entschied ich mich das Ganze mit Golang HTML Templates und ohne JavaScript Framework für das Frontend umzusetzten.
Die folgende Grafik visualisiert die beiden Flows.
Der Cat - cloud authentication tester ist übrigens das Projekt, über das ich im Artikel CI/CD Pipeline mit Gitea und Drone berichtet habe.
SAML Workflow mit ADFS
Als erstes muss in Cat die Metadata URL von ADFS angegeben werden, diese lautet:
https://<adfs-url>/federationmetadata/2007-06/federationmetadata.xml
Anschliessend wird die Konfiguration mit Create Service Provider in Cat erstellt. Als nächstes muss die Service Provider Metadata URL kopiert werden.
Anschliessend wird ADFS konfiguriert. Wichtig dabei ist, dass der Name ID Claim im urn:oasis:names:tc:SAML:2.0:nameid-format:transient Format geschickt wird (letzter Screenshot)
Mit dem Klick auf Start wird der Authentication Flow mit SAML gestartet und am Schluss sollte die SAML Assertion mit den erstellten Claims sichtbar sein.
OIDC Workflow mit ADFS
Beim OIDC Workflow muss zuerst der IdP, in diesem Fall ADFS, konfiguriert werden. Dazu wird die Redirect URI von Cat kopiert. Ich erstelle eine OIDC Applikation (durch das Aktivieren des Scopes allatclaims, Screenshot 6) für einen Confidential Client mit einem Shared Secret (Screenshot 3). Es gäbe noch etliche andere Konfigurationsmöglichkeiten wie zum Beispiel einen Public Client oder einen OAuth2 Flow (mit Userinfo Endpoint), welche Cat testen kann aber ich beschränke mich hier auf das Testen der Claim Rules.
SAML Workflow mit Keycloak
Das Setup mit Keycloak als IdP ist ähnlich einfach wie mit ADFS. Die Metadata URL ist in den Realm Settings unter dem Punkt Endpoints ersichtlich und kann von dort kopiert werden. Sie sieht folgendermassen aus: https://<keycloak-url>/auth/realms/<realm>/protocol/saml/descriptor
Diese URL wird in Cat wieder im Feld Metadata URL eingefügt und anschliessend auf Create Service Provider geklickt. Dadurch wird in Cat ein Service Provider erstellt und die entsprechenden Metadaten unter der angegebenen Service Provider Metadata URL publiziert. Die Service Provider Metadata URL wiederum wird in Keycloak unter Clients -> Create eingegeben.
Auf der nächsten Seite muss die Option Client Signature Required deaktiviert werden, weil die SAML Library den SAML Request nicht signiert. Als Root URL wird die Basis Adresse des Service Providers (in meinem Fall https://cat.irbe.ch) angegeben und als erlaubte Redirect URI muss /saml/acs hinzugefügt werden.
Unter dem Reiter Mappers erstelle ich ein Claim Mapping für das Attribut Email
Mit dem Button Start wird der Login Prozess in Gang gesetzt und nachdem ich mich erfolgreich angemeldet habe kann ich den Inhalt meiner SAML Assertion mit dem definierten Claim email anschauen.
OIDC Workflow mit Keycloak
Auch hier kopiere ich als erstes die Redirect URI von Cat. In der Keycloak Admin Console erstelle ich einen neuen Client, diesmal mit dem Protokoll openid-connect
Den Access Type ändere ich auf confidential und als Valid Redirect URIs füge ich /oidc/callback hinzu.
Nun muss die Konfiguration gespeichert werden um das Client Secret von Keycloak generieren zu lassen. Dieses ist anschliessend im Reiter Credentials ersichtlich, der ebenfalls erst nach dem Speichern erscheint.
Mit der URL (welche in den Realm Settings -> Endpoints ersichtlich ist), der ClientID und dem Secret kann der Flow gestartet werden.
SAML Workflow mit AzureAD
Für eine SAML Anbindung muss in Azure Active Directory eine Enterprise Application erstellt werden.
In der Gallery wird Create your own application ausgewählt und als Typ (Rechts) wird Non-gallery ausgewählt.
Nachdem die Applikation erstellt wurde muss sie einem Benutzer (oder Gruppe) zugewiesen werden, für den/die das Login erlaubt werden soll.
Anschliessend geht es an die SAML Konfiguration. Dazu muss unter dem Reiter Single sign-on als Methode SAML ausgewählt werden.
In der Basic SAML Configuration auf das Bleistift Symbol klicken und die Werte gemäss Screenshot eintragen.
Zum Schluss muss die Metadata URL für den IdP kopiert werden, diese ist auf der Single Sign On Seite im Schritt SAML Signing Certifcate unter App Federation Metadata Url zu finden. Diese URL muss in Cat bei Metadata URL eingefügt werden, anschliessend kann mit Create Service Provider die Konfiguration in Cat erstellt werden und mit Start den Workflow in Gang setzten.
OIDC Workflow mit AzureAD
Eine OIDC Anbindung an AzureAD wird über App registrations gemacht.
Als Redirect URI wird diejenige welche in Cat im OIDC Workflow ersichtlich ist eingetragen.
Anschliessend wird unter Certificates & secrets ein Client Secret mit einer frei wählbaren Beschreibung und Ablauf Datum erstellt.
Und zum Schluss werden alle benötigten Daten in Cat eingetragen.
Die Provider URL entspricht dem Federation metadata document (ohne /.well-known/openid-configuration), die Application ID ist die Application (client) ID in Azure und das Client Secret dasjenige welches vorhin generiert wurde.
Der OIDC Workflow mit AzureAD kann gestartet werden
Wie weiter
Mein ursprüngliches Ziel, ein Werkzeug zu schaffen welches Tokens visualisiert und vertieftes Wissen zu sammeln im Bereich von Cloud Authentication, habe ich abgeschlossen. Damit ist dieses Projekt für mich aber noch nicht abgeschlossen, es gibt noch viele zusätzliche Features welche hinzugefügt werden können.
- SAML Metadata als File Upload
- Manuelles Auswählen des OIDC Response Types und Modes
- …