Sicherheitsstandards und Authentifizierungsmechanismen sind heutzutage unerlässlich für die Gewährleistung der Integrität von Webanwendungen und Geschäftskritischen Plattformen. Im Zentrum moderner Single Sign-On (SSO) Implementierungen steht häufig das Security Assertion Markup Language (SAML) Protokoll, das sowohl von Dienstanbietern als auch Identitätsanbietern genutzt wird, um Benutzerauthentifizierung zu realisieren. Eine wiederkehrende Frage in der Entwicklergemeinschaft lautet dabei, ob das Zertifikat des Service Providers (SP) direkt in der Authentifizierungsanfrage (AuthnRequest) enthalten sein sollte oder nicht. Die Antwort hierauf hat nicht nur technische Implikationen, sondern beeinflusst auch die Sicherheit und Effizienz des gesamten Authentifizierungsprozesses. Zunächst ist es wichtig, den Grundaufbau einer SAML AuthnRequest zu verstehen.
Diese Anfrage wird vom Service Provider an den Identity Provider (IdP) gesendet, um eine Authentifizierung des Nutzers zu initiieren. Die AuthnRequest dient als Initialisierungsnachricht, die dann vom IdP geprüft und verarbeitet wird. Eine wichtige Komponente der Sicherheit hierbei ist die digitale Signatur, welche sicherstellt, dass die Anfrage authentisch ist und von dem berechtigten Service Provider stammt. In der Praxis ist es gängige Methode, dass das Zertifikat des Service Providers in dessen Metadaten konfiguriert und hinterlegt wird. Diese Metadaten werden zwischen IdP und SP ausgetauscht, um gegenseitiges Vertrauen herzustellen.
Das Zertifikat in den Metadaten dient zum Verifizieren der Signatur der AuthnRequest, ohne dass es notwendig wäre, das Zertifikat selbst in jeder einzelnen Anfrage mitzusenden. Auf diese Weise bleibt die Anfrage kompakt und es wird eine klare Trennung zwischen Metadatenverwaltung und realem Authentifizierungsprozess erzielt. Das direkte Einbinden des Zertifikats in die AuthnRequest wirft verschiedene Fragen auf. Einerseits könnte man argumentieren, dies würde die Überprüfung der Signatur erleichtern, da der IdP nicht auf externe Metadaten angewiesen wäre. Andererseits widerspricht dies dem Grundprinzip der Signaturprüfung, denn die Signatur soll mittels eines vorab vertrauten Zertifikats überprüft werden, das nicht Teil der Nachricht selbst ist, um Manipulationen zu vermeiden.
Wird das Zertifikat in der Anfrage eingebettet, könnte ein Angreifer theoretisch eine eigene AuthnRequest mit manipuliertem Zertifikat senden, was das Sicherheitsmodell untergraben würde. Offizielle SAML-Spezifikationen und Best Practices raten davon ab, das Zertifikat in der AuthnRequest zu inkludieren. Stattdessen wird empfohlen, die Vertrauensbeziehung über einen vorherigen Austausch der Metadaten herzustellen. Dort ist das öffentliche Schlüsselzertifikat eingebunden und ermöglicht dem IdP eine valide Prüfung der eingehenden Signaturen. Dadurch wird ein sicherer Rahmen geschaffen, der die Authentifizierungsanfragen überprüfbar macht, ohne dass es notwendig ist, das Zertifikat dauerhaft in den Nachrichten mitzuführen.
Die Implementierung dieser Prinzipien hat auch praktische Vorteile. Das Verwenden von Metadaten als einzigen Ort für Zertifikatsinformationen erleichtert die Wartung und Verwaltung. Ändert sich beispielsweise das Zertifikat des Service Providers, kann der neue Schlüssel einfach in den Metadaten ausgetauscht werden, während alle AuthnRequests weiterhin standardisiert und unverändert bleiben. Dies ermöglicht eine klar strukturierte Konfiguration und reduziert Fehlerquellen im Authentifizierungsablauf. Zudem existieren technische Limitationen bei der Einbettung großer Datenmengen in SAML-Nachrichten, die oft über HTTP Redirect oder POST Bindings übertragen werden.
Das Hinzufügen eines Zertifikats führt zu einer deutlichen Vergrößerung der AuthnRequest und könnte dadurch Performanceprobleme verursachen oder Probleme bei der Übertragung hervorrufen. Aus der Sicherheitsperspektive wird empfohlen, dass der Service Provider seine Anfragen signiert, damit der Identity Provider die Absenderauthentizität prüfen kann. Die Signatur wird mit dem privaten Schlüssel des Service Providers erzeugt, während der Identity Provider anhand des zuvor gültig hinterlegten öffentlichen Schlüssels im Zertifikat im Metadaten-Repository die Signatur validiert. Dies ist ein bewährter und sicherer Prozess, der sicherstellt, dass die Authentifizierungsanfrage nicht abgefangen oder manipuliert wurde. In manchen Fällen kann die Diskussion aufkommen, dass das Einfügen des Zertifikats in der AuthnRequest den Prozess vereinfacht, weil man sich weniger Sorgen um prior ausgetauschte Metadaten machen muss.
Diese Ansicht berücksichtigt jedoch nicht die Sicherheitsimplikationen und den Standardkonformitätsaspekt. Ohne die zwingende Validierung eines vorab geteilten Zertifikats könnten Man-in-the-Middle-Angriffe oder Replay-Attacken leichter erfolgreich sein. Zusammenfassend kann man sagen, dass das Einfügen des Service Provider-Zertifikats direkt in der AuthnRequest aus technischer und sicherheitstechnischer Sicht nicht ratsam ist. Stattdessen sollte der Fokus auf einen sorgfältigen und verifizierten Austausch der Metadaten gelegt werden, in denen das Zertifikat eingebunden ist. Die Signatur der AuthnRequest sollte mit dem privaten Schlüssel des SP erfolgen und der IdP die Signatur gegenüber dem bekannten öffentlichen Schlüssel validieren.
