Weitere Anforderungen SAML 2.0

Die Integration einer SAML 2.0 fähigen Applikation in den eIAM Service setzt fundierte Kenntnisse des SAML 2.0 Protokolls sowie der zu integrierenden Applikation voraus. Die Applikation ist dem Service eIAM anzupassen. eIAM wird entsprechend dem Dossier konfiguriert. Kundenspezifische Anpassungen von eIAM für die einmalige Nutzung einer Anwendung sind nicht möglich.

Unterstützte SAML Profile, Bindings, Subject Confirmation Type

Alles was im Folgenden nicht explizit als unterstützt definiert ist, wird vom eIAM Service NICHT unterstützt.

Von eIAM-Web PEP unterstützte SAML 2.0 Profile
Die nachfolgende Tabelle zeigt die von den Akteuren im eIAM Service zu verwendenden SAML 2.0 Profile.


Akteur Webbrowser SSO Profile Single Logout Profile
Anwendung unter Verwendung von RP-PEP MUSS MUSS
Anwendung mit Standard Integration (STS-PEP) MUSS KANN

Von eIAM PEP unterstützte SAML 2.0 Bindings
eIAM unterstützt aus Sicht der Applikation die folgenden SAML 2.0 Bindings:

  • HTTP POST Binding für SAML AuthnRequests und SAML Responses
    • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

Von eIAM PEP unterstützte "Subject Confirmation Type"
eIAM unterstützt aus Sicht der Applikation die folgenden Subject Confirmation Types:
  • Bearer
    • urn:oasis:names:tc:SAML:2.0:cm:bearer

Signaturen und Verschlüsselungen

Die folgende Tabelle gibt eine Übersicht über die Anforderungen an die digitalen Signaturen und Verschlüsselungen auf Meldungs-Ebene. Davon unabhängig dürfen die Meldungen generell nur mit Verschlüsselung auf dem Transport-Layer (HTTPS) übertragen werden.

Kommunikation SAML Profil Digitale Signatur                                      Verschlüsselung auf Meldungsebene
Applikation → eIAM SAML Endpunkt Web-SSO Profile (Login)AuthnRequest: MUSS NICHT (1) AuthnRequest: DARF NICHT
eIAM SAML Endpunkt → Applikation Web-SSO Profile (Login)Response: MUSS
Assertion: MUSS NICHT (2) 		Response: DARF NICHT
Assertion: DARF NICHT
Single Logout ProfileLogoutRequest: MUSS
LogoutResponse: MUSS NICHT 		LogoutRequest: DARF NICHT
LogoutResponse: DARF NICHT
Single Logout ProfileLogoutRequest: MUSS
LogoutResponse: MUSS NICHT (3) 		LogoutRequest: DARF NICHT
LogoutResponse: DARF NICHT
(1) Die Signierung des AuthnRequests ist freiwillig, jedoch empfohlen. Damit wird CSRF (Cross Site Request Forgery) verhindert. Dies, weil die Signatur dafür sorgt, dass eIAM nur AuthnRequests akzeptiert, welche wirklich von der Applikation ausgestellt wurden.
(2) Dies ist nicht zwingend nötig. eIAM signiert jedoch Assertions auch.
(3) eIAM signiert LogoutResponses in jedem Fall.

x509 Keymaterial für die Signatur von SAML Nachrichten

Um die SAML-Meldungen zu signieren, muss das Projekt ein Zertifikat bereitstellen.
Es gelten die folgenden Anforderungen:
  • Jede Umgebung (REF, ABN, PROD) MUSS ein eigenes Zertifikat haben
  • Schlüssellänge: MUSS mindestens 2048 Bit betragen
  • Gültigkeitsdauer des Zertifikats MUSS zwischen 1 und 3 Jahren liegen
  • Zertifikate MÜSSEN eine "Key Usage" für Signierung haben
  • Für Anwendungen innerhalb der Bundesverwaltung MÜSSEN Zertifikate von der Swiss Government PKI (SG-PKI) ausgestellt werden und vom Typ "Class-C" oder "Class-E" sein
  • Für alle anderen Anwendungen SOLLTEN Zertifikate der SG-PKI verwendet werden, aber auch andere sind zulässig
Es wird empfohlen, diese in einer frühen Phase des Projekts zu bestellen.

Benötigtes Schlüsselmaterial und dessen Verwendung
Benötigtes Schlüsselmaterial und dessen Verwendung

Anforderungen an die KeyInfo

Zur Identifizierung des für die Prüfung der Signatur der SAML Strukturen zu verwendenden Public Key gibt es gemäss der SAML 2.0 Spezifikation verschiedene Möglichkeiten.

eIAM verwendet das Element KeyInfo, welches in jeder signierten SAML Meldung vorhanden sein MUSS. KeyInfo MUSS das X.509 Zertifikat des Schlüsselpaars enthalten, mit welchem die SAML-Meldung signiert wurde.


Notwendige Informationen für die SAML 2.0 Konfiguration . . .

Austausch des x509 Key Materials

Der Austausch der öffentlichen Schlüssel (Zertifikate) findet zum ersten Mal während der Integration der Anwendung statt. Normalerweise stellen Anwendung und eIAM ihre Metadaten-Datei dem Gegensystem zur Verfügung. Für Details siehe

Notwendige Informationen für die SAML 2.0 Konfiguration . . .
.
Gegenseitiger Austausch der Signer Zertifikate für die Signaturprüfung
Gegenseitiger Austausch der Signer Zertifikate für die Signaturprüfung


  • eIAM stellt der Applikation den öffentlichen Schlüssel (Zertifikat) des eIAM-Web PEP Signer in seiner Rolle als Identity Provider zur Verfügung, damit diese die Signatur der von ihm ausgestellten SAML-Meldungen prüfen kann.
  • Die Applikation stellt dem eIAM-Web PEP den öffentlichen Schlüssel (Zertifikat) des Applikations Signer in ihrer Rolle als Service Provider zur Verfügung, damit dieser die Signatur der von ihr ausgestellten SAML-Meldungen prüfen kann.

Erneuerung von Key Material

Das Keymaterial SOLL sowohl von der Applikation als auch vom PEP entsprechend der Gültigkeitsdauer der Zertifikate erneuert werden. eIAM ist so ausgelegt, dass ein Parallelbetrieb mit mehreren Public Keys (dem alten und dem neuen) für die Prüfung der Signatur der Applikation arbeiten kann. Ebenso MUSS die Applikation technisch in der Lage sein, mehrere Zertifikate zur Prüfung der Signaturen von eIAM zu halten. Dies erlaubt eine Erneuerung von Zertifikaten zur Signaturprüfung ohne einen Ausfall der Applikationen und ohne dass die Zertifikate und privaten Schlüssel der Gegenstellen zum exakt gleichen Zeitpunkt erneuert werden müssen.

Der Betreiber der Applikation und der Betreiber von eIAM MÜSSEN sich frühzeitig gegenseitig über die Erneuerung des Schlüsselmaterials informieren. Die betrieblichen Prozesse über die Information der Gegenstelle und den Austausch der Schlüssel MÜSSEN vor der Produktivsetzung der Applikation durch das Projekt (Kunden) geregelt sein.