Alternative Logins für Eduroam - Rollout als föderierter Dienst. Gerätemanager. Axel Taraschewski IT Center der RWTH Aachen

Transkript

1 Alternative Logins für Eduroam - Rollout als föderierter Dienst Gerätemanager Axel Taraschewski IT Center der RWTH Aachen 68. DFN-Betriebstagung Berlin-Zehlendorf

2 Hintergründe: Warum? Gerätemanager eduroam-zugangsdaten können relativ einfach mittels man in the middle Angriff abgefangen werden Besonders gefährdet sind mobile Devices, die ständig versuchen bekannte Netzwerke zu finden und sich zu verbinden Die Anzahl der Geräte, die eduroam nutzen steigt Die Passwörter werden sowohl im privaten wie auch im Hochschulkontext genutzt Die Erfahrung hat gezeigt, daß dieselben Zugangsdaten oft auch für kritische Dienste genutzt werden, wie Campus Management (z.b. An- / Abmeldung zu Prüfungen) Intranet (Mitarbeiter-Login) etc Ernsthaftes Problem - sowohl für den Nutzer als auch für die Hochschule! 2

3 Lösungsansatz Gerätespezifische eduroam-kennungen Verringern die Auswirkungen der Sicherheitslücke lösen das eigentliche Problem aber nicht vollständig! Jeder Nutzer erhält bei Bedarf mehrere eduroam-kennungen Für jedes Gerät kann eine neue Kennung angelegt werden Benutzername und Passwort werden NUR für eduroam verwendet 3

4 AGENDA Hintergründe: Warum? Vorstellung: Der eduroam Gerätemanager 2.0 (DEMO) Zeitachse und Milestones eduroam Gerätemanager Von Version 1.0 zu Version 2.0 Aktuelle Nutzerzahlen Aufbau neuer Supportstrukturen Gerätemanagement für andere Einrichtungen und Institutionen 4

5 Gerätemanager Beispiel: RWTH Aachen University 5

6

7

8

9

10

11

12

13

14 Zeitachse & Milestones IT-SD Tool Einarbeitung des Feedback FZJ Produktabstimmung mit FZJ Supportkonzept für externe Institutionen Pilotbetrieb Freigabe DSB Anwendertests & Umsetzung Feedback SW-Entwicklung Konzeption V2.0 Projektübergabe

15 Architektur des Gerätemanager FZJ 15

16 eduroam Gerätemanager Von Version 1.0 zu Version 2.0 Probleme: Version 1.0 (2016) User Experience Anwendung nicht intuitiv zu verstehen Darstellung auf mobile Endgeräten verbesserungswürdig Nutzung der Anwendung schien aufwendiger als der gewohnte Weg Mehrwerte wurde häufig nicht erkannt / fehlten noch Wenig Akzeptanz der Anwendung Ziele für Version 2.0 Verbesserte Akzeptanz der Anwendung Steigerung der User Experience Neue Mehrwerte Marketing / Support z.b. im Rahmen von TreMoGe 16

17 eduroam Gerätemanager Von Version 1.0 zu Version 2.0 Ziele für Version 2.0 Dienst als Angebot für andere forschungsnahe Institutionen und Hochschulen Erste Partnerschaft mit FZJ-Jülich Föderiertes Gerätemanagement Neue zielgruppenspezifische Supportstrukturen Maßnahmen Intuitives Web-Interface Anlegen und Löschen von Zugangsdaten mit nur drei Klicks! Neues Design Corporate Design der RWTH Aachen Responsive Layout / Angepasste Darstellung auf allen mobilen Endgeräten Möglichkeit ein neues Passwort zu generieren Intergierte Informationen Warum gerätebasierte Zugangsdaten How to use / Anleitungsvideos Marketing (Ankündigung, Blog-Beiträge, TreMoGe etc.) 17

18 Gerätebasierte Zugangsdaten: Version 2.0 eduroam Gerätemanager Maßnahmen: Neue Mehrwerte Nutzer können prüfen wann ihr Gerät verwendet wurde Monitoring aktueller und zurückliegender Verbindungsversuche (Radius Logging) Zu welcher Zeit und von welcher IP ist ein Gerät zuletzt mit eduroam verbunden gewesen Nutzer können bei Verdacht selber feststellen, ob ihre Zugangsdaten geklaut wurden und das Passwort über den Gerätemenanger neu generieren. 18

19 eduroam Gerätemanager 2.0 Nutzung seit dem (WiSe 17/18) Accounts angelegt Accounts gelöscht Passworte neu erzeugt 790 Nicknames für das Devices geändert 19

20 Gerätemanagement als Dienst für weitere Institutionen Föderiertes Gerätemanagement Etablierte Strukturen nutzen Authentifizierung mittels Shibboleth Bereits Teil des DFN AAI Nutzer beteiligter Institutionen können authentifiziert werden Autorisierung mittels OAuth2 Anpassung der lokalen Infrastruktur um diese als Dienst im DFN AAI anzubieten Erweiterungen am Gerätemanager (Backend) Eine Subdomain für jede Institution Mandantenfähigkeit der Webanwendung Lifecycle-Management 20

21 Gerätemanager Support für weitere Einrichtungen Aufbau neuer Supportstrukturen Erweiterung der Monitoring Informationen für den lokalen Support Login Informationen: Zeitpunkt, IP-Adresse (Ort), MAC Adresse, Fehlermeldung Zugriff für Support über Benutzer- und/oder Gerätekennung Teilnehmende Einrichtungen sehen für ihre (Sub-) Domain (nur) die eigenen Informationen Abgestimmte Dokumentation, Hilfe und Tutorials etc. Einbindung der externen Supporteinrichtungen in die Support- und Kommunikationsprozesse der lokalen Einrichtung Service Level Agreements 21

22 Die Support Pyramide Am Beispiel eines gemeinsam konzipierten und entwickelten Dienstes zwischen zwei unabhängigen Forschungseinrichtungen Fachabteilung (IT Center) IT-ServiceDesk (IT Center RWTH) Externer 1st-Level Support (Forschungszentrum Jülich) Externer Anwender (Forschungszentrum Jülich) 22

23 Axel Taraschewski Sarah Grzemski Gerätemanager Bernd Decker

24 Zusatzinformationen

25 Projektstruktur VVZ Projektleitung FZJ Konzept User Experience PIT Dokumentation Sicherheitskonzept Schnittstellen Frontend User Experience IT-SD Support Konzept Security Konzept Anwendertests Owner EGM Radius Leitung Netzte Backend Kooperation Ressourcen Konzept Kommunikation DFN Monitoring A&O SuB Datenbanken Marketing Hosting IdM 25

26 Gerätemanagement für weitere Einrichtungen OAuth2 als föderierter Dienst 26

27 Beispiel: RWTHApp Prozess starten (RWTHApp) Autentifizierung (Shibboleth) App Autorisieren (OAuth) Personalisierte Informationen Anzeigen (RWTHApp) 27

28 Umsetzung OAuth an der RWTH Aachen Sichere, gerätebasierte Autorisierung (De)Autorisierung über Webinterface Keine Weitergabe von Benutzerdaten OAuth2 als Dienst Integriert mit Shibboleth zur Authentifizierung Möglich auch als Föderationsdienst An der RWTH etabliert z.b. die RWTHApp mit ~ Nutzern Verfahren skaliert auf unterschiedliche Anwendungen 28