Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Letzte ÜberarbeitungBeide Seiten der Revision
de:shibidp3x509 [2018/06/21 15:44] – [Hinweis zur Urheberschaft und weiterführende Informationen] Wolfgang Pempede:shibidp3x509 [2021/05/03 14:53] Silke Meyer
Zeile 1: Zeile 1:
 ====== X509-Authentifizierung in Shibboleth ====== ====== X509-Authentifizierung in Shibboleth ======
 +<callout color="#ff9900" title="Archiv">
 +Dieser Artikel ist ein Beitrag für Shibboleth IdP 3.x. Es ist unklar, ob er für Shibboleth IdP 4.x so noch gilt.
 +</callout>
 +Ein Login-Vorgang am Shibboleth-IdP besteht im Allgemeinen aus verschiedenen //Flows//. Nachdem eine Anfrage von einem Service Provider (SP) empfangen wurde, geht der IdP in einen der verfügbaren Flows zur Authentifizierung über. Dabei handelt es sich beispielsweise um den Password-Flow authn/Password, wobei sich der Nutzer durch die Eingabe von Nutzername und Passwort authentifizieren kann. Diese Daten werden dann gegen eine angeschlossene Datenquelle (häufig LDAP-Server) geprüft. Am Ende dieses Flows steht die //Subject-Canonicalization//, die das Erzeugen eines Benutzernamens (auch //Principal// genannt) für den Nutzer, der sich gerade erfolgreich authentifiziert hat, beschreibt. Unter diesem Benutzernamen ist der Nutzer im weiteren Verlauf im IdP bekannt. Normalerweise entspricht dieser Name schlichtweg dem Nutzernamen.
  
-Ein Login-Vorgang am Shibboleth-IdP besteht im Allgemeinen aus verschiedenen //Flows//. Nachdem eine Anfrage von einem Service Provider (SP) empfangen wurde, geht der IdP in einen der verfügbaren Flows zur Authentifizierung über. Dabei handelt es sich beispielsweise um den Password-Flow authn/Passwordwobei sich der Nutzer durch die Eingabe von Nutzername und Passwort authentifizieren kannDiese Daten werden dann gegen eine angeschlossene Datenquelle (häufig LDAP-Server) geprüftAm Ende dieses Flows steht die //Subject-Canonicalization//, die das Erzeugen eines Benutzernamens (auch //Principal// genannt) für den Nutzer, der sich gerade erfolgreich authentifiziert hat, beschreibt. Unter diesem Benutzernamen ist der Nutzer im weiteren Verlauf schließlich im IdP bekannt. Normalweise (und vor allem bei Verwendung des Password-Flowsentspricht dieser Name schlichtweg dem Nutzernamen.+Neben dem authn/Password-Flow stellt der Shibboleth-IdP auch den sogenannten authn/X509-Flow zur Verfügung, der die Verwendung von X509-Client-Zertifikaten als Authentifizierungsmethode erlaubtDie Logik auf Seiten des IdP ist dabei vergleichsweise simpel: Im Servlet-Container wird die Umgebungsvariable „javax.servlet.request.X509Certificate“ verwendet, um zu prüfen, ob die Authentifizierung erfolgreich ist. Wie diese Variable befüllt wird, spielt für den IdP dabei keine Rolle (siehe [[https://wiki.shibboleth.net/confluence/display/IDP30/X509AuthnConfiguration|Dokumentation im Shibboleth Wiki]]).
  
-Neben dem authn/Password-Flow stellt der Shibboleth-IdP auch den sogenannten authn/X509-Flow zur Verfügungwelcher die Verwendung von X509-Client-Zertifikaten als Authentifizierungsmethode erlaubtDie Logik auf Seiten des IdP ist dabei vergleichsweise simpel, da schlichtweg die Umgebungsvariable „javax.servlet.request.X509Certificate“ im Servlet-Container verwendet wird, um zu prüfen, ob die Authentifizierung erfolgreich ist oder nicht. Wie diese Variable befüllt wirdspielt für den IdP dabei keine Rolle [Shib-X509AuthnConfiguration].+Jeder Login-Flow wird über einen dedizierten Endpunkt am IdP zur Verfügung gestellt. Bei authn/X509 handelt es sich dabei um den Pfad /Authn/X509. Ein naheliegender Weg besteht nun darin, diesen Endpunkt über den Apache-Webserver zu schützen. Sobald der IdP dann in seinem Ablauf in den authn/X509-Flow springt (wodurch der User auf den geschützten Pfad auf dem Webserver weitergeleitet wird)greift die Zugriffskontrolle von Apache. Da in diesem Fall als Authentifizierungsmethode X509-Zertifikate eingesetzt werden sollen, kann hierfür das [[https://httpd.apache.org/docs/2.4/mod/mod_ssl.html|Apache-Modul „mod_ssl“ entsprechend konfiguriert]] und das Client-Zertifikat validiert werdenIst diese Validierung erfolgreich, kann der Nutzer den Endpunkt des IdP aufrufen. Dort ist „javax.servlet.request.X509Certificate“ nun korrekt befüllt und stellt Informationen über das verwendete Zertifikat bereit. Wenn die Zugriffskontrolle von Apache den Nutzer nicht durchlässt (also die Validierung des Zertifikats nicht erfolgreich war)kommt der Nutzer gar nicht erst zum X509-Endpunkt.
  
-Jeder Login-Flow wird über einen dedizierten Endpunkt am IdP zur Verfügung gestellt. Bei authn/X509 handelt es sich dabei um den Pfad /Authn/X509. Ein naheliegender Weg besteht nun darin, diesen Endpunkt über den Apache-Webserver zu schützen. Sobald der IdP dann in seinem Ablauf in den authn/X509-Flow springt (wodurch der User auf den geschützten Pfad auf dem Webserver weitergeleitet wird), greift die Zugriffskontrolle von Apache. Da in diesem Fall als Authentifizierungsmethode X509-Zertifikate eingesetzt werden sollen, kann hierfür das Apache-Modul „mod_ssl“ entsprechend konfiguriert [Apache-mod-ssl] und das Client-Zertifikat validiert werden. Ist diese Validierung erfolgreich, kann der Nutzer den Endpunkt des IdP aufrufen. Dort ist „javax.servlet.request.X509Certificate“ nun korrekt befüllt und stellt Informationen über das verwendete Zertifikat bereit. Wenn die Zugriffskontrolle von Apache den Nutzer nicht durchlässt (also die Validierung des Zertifikats nicht erfolgreich war), kommt der Nutzer gar nicht erst zum X509-Endpunkt. +Im Gegensatz zum authn/Password-Flow, wo die //Subject-Canonicalization// im Allgemeinen sehr simpel ist, muss beim authn/X509-Flow unter Umständen mehr konfiguriert werden. Normalerweise lässt sich der zu verwendende Name aber aus dem //Subject-DN// des Client-Zertifikats extrahieren.
- +
-Im Gegensatz zum authn/Password-Flow, wo die //Subject-Canonicalization// im Allgemeinen sehr simpel ist, muss beim authn/X509-Flow unter Umständen mehr konfiguriert werden. Normalerweise lässt sich der zu verwendende Name aber aus dem //Subject-DN//des Client-Zertifikats extrahieren.+
  
 ===== Anleitung für Apache, Tomcat und Shibboleth ===== ===== Anleitung für Apache, Tomcat und Shibboleth =====
Zeile 14: Zeile 16:
  
 In diesem Beispiel werden zwei Client-Zertifikate verwendet: In diesem Beispiel werden zwei Client-Zertifikate verwendet:
 +    - emailAddress=mustermann@dfn-cert.de, CN=Erika Mustermann, OU=Test, O=Organisation 1, C=DE
 +    - emailAddress=mustermann@dfn-cert.de, CN=Erika Mustermann, OU=Test, O=Organisation 2, C=DE
  
-Zertifikat 1: emailAddress=mustermann@dfn-cert.de, CN=Erika Mustermann, OU=Test, O=Organisation 1, C=DE +Die Zertifikate sind durch folgende Zertifikat-Hierarchie ausgestellt: 
- +  C=DE,O=Test,CN=Test Eins CA 
-Zertifikat 2: emailAddress=mustermann@dfn-cert.de, CN=Erika Mustermann, OU=Test, O=Organisation 2, C=DE +  C=DE,O=Test,CN=Test Intermediate 
- +  C=DE,O=Test,CN=Test Root (Root CA
-Die Zertifikate sind nun durch folgende Zertifikat-Hierarchie ausgestellt: +
- +
-C=DE,O=Test,CN=Test Eins CA +
- +
-C=DE,O=Test,CN=Test Intermediate +
- +
-C=DE,O=Test,CN=Test Root +
- +
-Bei „CN=Test Root“ handelt es sich in diesem Beispiel um die Root CA+
- +
-Die beiden Zertifikate unterscheiden sich also nur durch die Zugehörigkeit zu Organisation 1 bzw. Organisation 2.+
  
-Beide Zertifikate wurden als Client-Zertifikate in den Browser importiert.+Die beiden Zertifikate unterscheiden sich also nur durch die Zugehörigkeit zu Organisation 1 bzw. Organisation 2. Beide Zertifikate wurden als Client-Zertifikate in den Browser importiert.
  
 ===== Konfiguration der Authentifizierung in Shibboleth ===== ===== Konfiguration der Authentifizierung in Shibboleth =====
Zeile 39: Zeile 32:
 Weiterhin werden laut [[https://wiki.shibboleth.net/confluence/display/IDP30/X509AuthnConfiguration|Shibboleth Wiki]] noch drei optionale Konfigurationsmöglichkeiten des Flows in ''{idp.home}/conf/authn/x509-authn-config.xml'' angeboten. In der Praxis dürfte in den meisten Fällen jedoch nur einer davon relevant sein: Weiterhin werden laut [[https://wiki.shibboleth.net/confluence/display/IDP30/X509AuthnConfiguration|Shibboleth Wiki]] noch drei optionale Konfigurationsmöglichkeiten des Flows in ''{idp.home}/conf/authn/x509-authn-config.xml'' angeboten. In der Praxis dürfte in den meisten Fällen jedoch nur einer davon relevant sein:
  
-''shibboleth.authn.X509.externalAuthnPath'' erlaubt das Festlegen des Pfads, auf den weitergeleitet werden soll, sobald der Login-Flow aufgerufen wird. Standardmäßig wird der Nutzer dabei auf eine vorgeschaltete Seite weitergeleitet (siehe Abbildung ) und muss explizit bestätigen, dass er nun einen Login per X509-Zertifikat wünscht (was dann zur Weiterleitung auf den Endpunkt /Authn/X509 führt). Wenn dieses Verhalten nicht gewünscht ist, kann dieser Parameter direkt auf den Endpunkt gesetzt werden.+''shibboleth.authn.X509.externalAuthnPath'' erlaubt das Festlegen des Pfads, auf den weitergeleitet werden soll, sobald der Login-Flow aufgerufen wird. Standardmäßig werden die Nutzer*innen dabei auf eine vorgeschaltete Seite weitergeleitet (siehe Abbildung). Dort müssen sie explizit bestätigen, dass sie einen Login per X509-Zertifikat wünschen. Dann werden sie auf den Endpunkt /Authn/X509 weitergeleitet. Wenn dieses Verhalten nicht gewünscht ist, kann dieser Parameter direkt auf den Endpunkt gesetzt werden.
  
-{{:de:screenshot_x509-login.png| \\ +{{:de:screenshot_x509-login.png|Standardmäßig konfigurierte Hinweis-Seite vor der Weiterleitung auf den geschützten Endpunkt}}
-Abbildung 1: Standardmäßig konfigurierte Hinweis-Seite vor der Weiterleitung auf den geschützten Endpunkt}} +
- +
-**Abbildung 1:** Standardmäßig konfigurierte Hinweis-Seite vor der Weiterleitung auf den geschützten Endpunkt+
  
 ===== Validierung der Zertifikate in Apache ===== ===== Validierung der Zertifikate in Apache =====
Zeile 58: Zeile 48:
 </code> </code>
  
-Zu beachten istdass dies nicht innerhalb einer Location-Angabe in Apache erfolgen darf, da insbesondere Apache in der Version 2.4 und mit aktueller OpenSSL-Version damit nicht zurechtkommt. Stattdessen muss diese Angabe direkt im Virtual-Host gesetzt werden.+Die Direktive muss direkt im VirtualHost stehen, nicht innerhalb einer Location-Angabe.
  
 ==== Schutz des X509-Endpunkts des IdP ==== ==== Schutz des X509-Endpunkts des IdP ====
Zeile 68: Zeile 58:
  SSLVerifyClient require  SSLVerifyClient require
  SSLVerifyDepth 3  SSLVerifyDepth 3
- SSLOptions +StdEnvVars +ExportCertData+ SSLOptions  StdEnvVars  ExportCertData
  Require expr (%{SSL_CLIENT_S_DN_O} == 'Organisation 1')  Require expr (%{SSL_CLIENT_S_DN_O} == 'Organisation 1')
 </Location> </Location>
Zeile 82: Zeile 72:
  
 ''Require'' erlaubt die Konfiguration von Bedingungen, die erfüllt sein müssen, damit der Zugriff gestattet wird und ermöglicht damit die Einschränkung der Authentifizierung auf bestimmte Nutzergruppen. Im folgenden wird diese Direktive genauer betrachtet. ''Require expr'' ersetzt im Allgemeinen die veraltete ''SSLRequire''-Direktive. ''Require'' erlaubt die Konfiguration von Bedingungen, die erfüllt sein müssen, damit der Zugriff gestattet wird und ermöglicht damit die Einschränkung der Authentifizierung auf bestimmte Nutzergruppen. Im folgenden wird diese Direktive genauer betrachtet. ''Require expr'' ersetzt im Allgemeinen die veraltete ''SSLRequire''-Direktive.
- 
 ==== Konfigurationsmöglichkeiten Require ==== ==== Konfigurationsmöglichkeiten Require ====
  
Zeile 98: Zeile 87:
  
 Hier wird mit ''%{SSL_CLIENT_I_DN_CN}'' der CN des Issuer des Client-Zertifikats überprüft. Da beide Zertifikate von „Test Eins CA“ ausgestellt wurden, werden beide Zertifikate nicht akzeptiert. Hier wird mit ''%{SSL_CLIENT_I_DN_CN}'' der CN des Issuer des Client-Zertifikats überprüft. Da beide Zertifikate von „Test Eins CA“ ausgestellt wurden, werden beide Zertifikate nicht akzeptiert.
- 
 ===== Weiterverarbeitung des Ergebnisses in Shibboleth ===== ===== Weiterverarbeitung des Ergebnisses in Shibboleth =====
  
Zeile 144: Zeile 132:
 Hier wird der wie oben beschrieben erzeugte Principal als Eingangswert für das Attribut ''uid'' verwendet. Hier wird der wie oben beschrieben erzeugte Principal als Eingangswert für das Attribut ''uid'' verwendet.
  
-===== Hinweis zur Urheberschaft und weiterführende Informationen ===== +{{tag>fixme}}
-Diese Anleitung stammt aus einer Dokumentation, die die DAASI International GmbH im Auftrag des DFN-CERT erstellt hat. Das vollständige Dokument, das auch alternative Systemumgebungen behandelt, kann {{de:anleitung-x509-authn-shibidp-v1.0.pdf|hier heruntergeladen werden}}+
  • Zuletzt geändert: vor 3 Jahren