alternative logins für eduroam - rollout als föderierter ......konzeption v2.0 sw-entwicklung...
TRANSCRIPT
Alternative Logins für Eduroam -Rollout als föderierter Dienst
Axel Taraschewski
IT Center der RWTH Aachen
68. DFN-Betriebstagung
Berlin-Zehlendorf
Gerätemanager
2
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!
Hintergründe: Warum ? Gerätemanager
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
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
5
GerätemanagerBeispiel: RWTH Aachen University
14
Zeitachse & Milestones
Projektübergabe
Konzeption V2.0
SW-Entwicklung
Anwendertests & Umsetzung Feedback
Freigabe DSB
Supportkonzept für externe Institutionen
Produktabstimmung mit FZJ
Einarbeitung des Feedback FZJ
Pilotbetrieb
10.2016 01.2017 02.201712.2017 02.2017 02.2017 03.2017 03.2017 08.2017
IT-SD Tool
15
Architektur des Gerätemanager
FZJ
16
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“
eduroam Gerätemanager Von Version 1.0 zu Version 2.0
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.)
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.
19
eduroam Gerätemanager 2.0Nutzung seit dem 1.10.17 (WiSe 17/18)
• 34.025 Accounts angelegt
• 12.348 Accounts gelöscht
• 9.622 Passworte neu erzeugt
• 790 „Nicknames“ für das Devices geändert
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
21
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
Gerätemanager
22
Die Support Pyramide
Fachabteilung
(IT Center)
IT-ServiceDesk(IT Center RWTH)
Externer 1st-Level Support(Forschungszentrum Jülich)
Externer Anwender (Forschungszentrum Jülich)
Am Beispiel eines gemeinsam konzipierten und entwickelten Dienstes zwischen
zwei unabhängigen Forschungseinrichtungen
Gerätemanagerwww.rwth-aachen.de/eduroamSarah Grzemski
Bernd Decker
Axel Taraschewski
Zusatzinformationen
25
Projektstruktur
EGM
PIT
Projektleitung
Konzept
Frontend
Schnittstellen
User Experience
VVZ
IT-SD
Dokumentation
Support
Anwendertests
Konzept
User Experience
Netzte
Radius
Backend
KonzeptKommunikation
DFN
A&O
Marketing
SuB
Monitoring
Datenbanken
IdMHosting
Leitung
Owner
Kooperation
Ressourcen
SecurityKonzept
Sicherheitskonzept
FZJ
26
Gerätemanagement für weitere Einrichtungen
OAuth2 als föderierter Dienst
27
Beispiel: RWTHApp
Autentifizierung
(Shibboleth)
Prozess starten
(RWTHApp)
App Autorisieren
(OAuth)
Personalisierte
Informationen Anzeigen
(RWTHApp)
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 ~20.000 Nutzern
Verfahren skaliert auf unterschiedliche
Anwendungen