Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:eduroam:admins [2018/04/19 16:09] – [Anbindung des eduroam IdP/SP via RADSEC] Ralf Paffrath
+++ de:eduroam:admins [2018/04/20 12:01] (aktuell) – gelöscht Ralf Paffrath
@@ Zeile 1: / Zeile 1: @@
-====== eduroam aus Sicht des Instituts-Admins ======
-Eine in eduroam teilnehmende Einrichtung kann in der Regel 2 Rollen einnehmen:
-  * Die des eduroam Identity-Provider (IdP), der seine Nutzer für eduroam registriert, verwaltet und die Authentifizierung durchführt,
-  * Die des eduroam Service-Provider (SP), der registrierten eduroam Nutzern den Netzzugang über ein WLAN (SSID:edurom) oder LAN emöglicht
-===== eduroam Identity-Provider (IdP) =====
-(folgt in Kürze)
-===== eduroam Service-Provider (SP) =====
-Service-Provider im eduroam-Sinne, sind die Einrichtungen, die das WLAN / die SSID 'eduroam' ausstrahlen und somit den reisenden Forscherinen und Forschern Internetzugriff ermöglichen. **Jedes Mitglied** im eduroam **muss immer auch ein Service-Provider sein**((d.h. wenn Ihre User eduroam nutzen dürfen sollen, müssen Sie selbst vor Ort auch eduroam anbieten. Teilen sich mehre Einrichtungen ein Gebäude, kann es vorkommen, dass rein technisch gesehen eine Einrichtung doch 'nur' IdP ist, weil eine andere die SP-Aufgabe für beide übernimmt.)). Es kann Einrichtungen geben, die nur eduroam ausstrahlen, deren User jedoch nicht selbst das eduroam nutzen können. Ein Beispiel hier sind einige Innenstädte, Bahnhöfe, Flughäfen und Bibliotheken, die als eduroam SP, nicht jedoch als IdP, auftreten.
-In der [[https://www.eduroam.org/wp-content/uploads/2016/05/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf|eduroam Service Definition (Abs. 6.3.3)]] sowie knapper formuliert dem [[https://www.eduroam.org/wp-content/uploads/2016/05/eduroam_Compliance_Statement_v1_0.pdf|eduroam Compliance Statement (Anhang B)]] werden die Anforderungen und Pflichten eines SP aufgeführt.
-Ganz knapp umrissen, muss ein SP folgende Elemente vorhalten:
-  * **WPA2-Enterprise WLAN**
-      * RADSEC-Verbindung zum DFN (s.u.)
-      * Einfügen des 'Calling-Station-Id' RADIUS-Attributs in den Request zum DFN
-      * Synchrone System-Uhrzeit (zB via ntp)
-  * (DHCP-)**Autokonfiguration für die Clients** im WLAN
-  * **offener Internetzugriff für die Clients**
-      * mit Firewall-Regeln für die WLAN-Clients, die bevorzugt einen komplett uneingeschränkten Netzzugang ermöglichen, ggf. nur einige Dienste (zB tcp/25) verbieten.
-      * Es müssen nach außen mindestens(!) folgende Dienste frei sein:
-        * ipsec
-        * GRE
-        * UDP-Ports: 500,1194,4500
-        * TCP-Ports: 21,22,80,110,143,443,465,587,993,995,3128,8080,1723,10000
-Jede gängige WLAN-Installation, egal ob selbst-gebaut auf günstiger Hardware und OpenSource-Basis, medium-bepreiste Firmenlösungen oder Enterprise-Campus-WLAN-Controller, erfüllt diese Anforderungen. In vielen Fällen muss derzeit (Stand Anfang 2018) für die Verbindung zum DFN jedoch zusätzlich ein Proxy für die **Umsetzung von UDP-RADIUS Paketen auf eine verschlüsselte TLS/TCP-RADSEC-Verbindung** installiert werden. Immer mehr Anbieter integrieren aber das RADSEC-Protokoll bereits direkt in die WLAN-Infrastruktur, wodurch dieser Umsetzter in Zukunft entfallen kann.
-**Der Netzzugang für den eduroam Nutzer wird vollständig durch den SP gestellt.** Mit Ende der Authentifizierung durch das Accept-Paket erfolgt keine Kommunikation mit dem IdP mehr. eduroam enthält keinerlei VPN-artigen Funktionalitäten. Verteilt/föderiert ist nur der Prozess der Authentifizierung. Auch gibt es im eduroam keine weiteren Autorisierungsmechanismen / User-Gruppen. Ein User darf das eduroam nutzen; oder nicht.
-==== Anbindung des eduroam IdP/SP via RadSec Protokoll ====
-Die Übertragung der RADIUS-Pakete in der DFN eduroam Föderation vom SP zum DFN erfolgt seit Dezember 2017 nur noch verschlüsselt via [[https://tools.ietf.org/html/rfc6614|RADSEC-Protokoll]]. RADSEC basiert auf dem bekannten TLS-Verfahren, bedarf also X.509-Zertifikaten, genau wie bspw. Web-Browser für HTTPS.
-Es werden nur [[https://www.pki.dfn.de/ueberblick-dfn-pki/|Zertifikate der DFN PKI]] Generation 1 oder 2 akzeptiert. Einrichtungen, die nicht Teilnehmer der DFN PKI sind, können [[https://www.dfn.de/kontakt/|auf Anfrage]] für diesen Zweck ein einzelnes Zertifikat ausgestellt bekommen.
-**Für den Betrieb benötigt der DFN folgende Informationen von zukünftigen SP:**
-  * IPv4-Adresse(n) der RADSEC Clients
-  * CN der Zertifikate der RADSEC Clients
-  * **Der Domain-Name wird nicht verwendet!** Weder für die Herstellung der Verbindung, noch den Zertifikats-Check.
-  * IPv6 wird momentan noch nicht unterstützt
-Die Parameter (IPs, DNS, Zertifikate) der DFN-RADSEC-Server finden Sie [[de:eduroam:admins:basics|hier]].
-Wir empfehlen eine Überprüfung anhand der IP, des CN des Zertifikats sowie natürlich einer korrekten Signatur des selben durch die DFN CA bzw. ein Telekom Root-Zertifikat. Config-Beispiele für gängige Produkte finden sich bei den [[de:eduroam:Anleitungen|Anleitungen]].
-**Für den Support der Endanwender ist immer der Heimat-IdP zuständig**. Stellt sich im Laufe der Fehlersucher heraus, dass eine Unterstützung durch den besuchten SP notwendig ist, muss der Kontakt durch die Admins des IdPs, nicht den Endanwender, aufgenommen werden. Im Zweifel vermittelt der DFN die zugehörigen Kontaktadressen.
-Die Authentifizierungs-Infrastruktur der eduroam .de-Föderation darf **nur für die Anmeldung an Computer-Netzwerken via 802.1x** verwendet werden. Die Terminierung der EAP-Verbindung erfolgt ausschließlich im Endgerät sowie dem Heimat-IdP. Eine Terminierung der EAP-Verbindung im SP oder einem anderen Zwischen-Hop ist untersagt.
-Noch unterstützen nicht alle WLAN-Geräte dieses Protokoll, weshalb in den meisten Fällen ein Umsetzer / Proxy erforderlich ist. Hierfür eignen sich praktisch alle RADIUS-Server-Programme, die auch RADSEC unterstützen. Darunter sind u.a. [[de:eduroam:anleitungen:freeradius|Freeradius]], [[https://www.open.com.au/radiator/|Radiator]] und der [[de:eduroam:anleitungen:radsecproxy|radsecproxy]]. Für SP empfehlen wir den radsecproxy, da es das einfachste Programm mit den geringsten Anforderungen und zudem Open Source mit einer breit installierten Basis ist.