SAML/OIDC Claims debuggen mit Cat

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.

Inhalt

  1. SAML Workflow mit ADFS
  2. OIDC Workflow mit ADFS
  3. SAML Workflow mit Keycloak
  4. OIDC Workflow mit Keycloak
  5. SAML Workflow mit AzureAD
  6. OIDC Workflow mit AzureAD
  7. Wie weiter

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.

Token Claims

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

Keycloak Endpoint URLs

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.

Keycloak SAML Client

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.

Keycloak SAML Setup

Unter dem Reiter Mappers erstelle ich ein Claim Mapping für das Attribut Email

Claim Mapping

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

Keycloak OIDC Setup

Den Access Type ändere ich auf confidential und als Valid Redirect URIs füge ich /oidc/callback hinzu.

OIDC Konfiguration

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.

OIDC Client Secret

Mit der URL (welche in den Realm Settings -> Endpoints ersichtlich ist), der ClientID und dem Secret kann der Flow gestartet werden.

OIDC Flow Start
ID, Access und Userinfo Token

SAML Workflow mit AzureAD

Für eine SAML Anbindung muss in Azure Active Directory eine Enterprise Application erstellt werden.

Neue Enterprise Application

In der Gallery wird Create your own application ausgewählt und als Typ (Rechts) wird Non-gallery ausgewählt.

Non Gallery Applikation erstellen

Nachdem die Applikation erstellt wurde muss sie einem Benutzer (oder Gruppe) zugewiesen werden, für den/die das Login erlaubt werden soll.

Benutzer der Enterprise Applikation zuweisen

Anschliessend geht es an die SAML Konfiguration. Dazu muss unter dem Reiter Single sign-on als Methode SAML ausgewählt werden.

SSO mit SAML

In der Basic SAML Configuration auf das Bleistift Symbol klicken und die Werte gemäss Screenshot eintragen.

SAML Konfigurations Parameter

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.

SAML Token von AzureAD

OIDC Workflow mit AzureAD

Eine OIDC Anbindung an AzureAD wird über App registrations gemacht.

Neue App registration erstellen

Als Redirect URI wird diejenige welche in Cat im OIDC Workflow ersichtlich ist eingetragen.

App registration Details

Anschliessend wird unter Certificates & secrets ein Client Secret mit einer frei wählbaren Beschreibung und Ablauf Datum erstellt.

Client Secret erstellen

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.

OIDC Parameter kopieren

Der OIDC Workflow mit AzureAD kann gestartet werden

OIDC Tokens von AzureAD

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.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.