Zentrale vs. dezentrale Rollenverwaltung und extreme Role Engineering als alternatives Verfahren zur Rechteverwaltung Treffen des Arbeitskreis Verzeichnisdienste des ZKI Dr.-Ing. Thomas Hildmann IT Dienstleistungszentrum der TU Berlin
Vorstellung von Person und Einrichtung
Motivation Das Fachgebiet
Motivation Rollen
Die richtige Rollenzahl
Geschäftsrollen Anwendungsrollen TUBIS Anwendung Statistiken 3-teiliges Modell Erfahrungen Was ist das Problem? Einsatzgebiet RBAC TUB-spezifisch Motivation Einleitung Normalisierung Rollenähnlichkeit Vorteile Autorisierung extreme Role Engineering Prototyp Demo Nachteile zentral Vorteile dezentral Nachteile Einsatzgebiet Vorgehensmodell Zahlen und Fakten schmutzige Details Usecases Komplexität
on Einleit Autorisierung al dezentral
Einsatzgebiet Was ist das Problem? Motivation
Nor Geschäftsrollen Anwendungsrollen TUBIS Anwendung Statistiken 3-teiliges Erfahrungen Modell RBAC TUB-spezifisch Einleitung
No Geschäftsrollen Anwendungsrollen TUBIS Anwendung Statistiken 3-teiliges Erfahrungen Modell C TUB-spezifisch
Einl Autorisierung dezentral
Vorteile zentral Nachteile Vorteile
Eins l dezentral Vorteile Nachteile
Rollenähnlichkeit ng extreme Role Engineering Prototyp Demo le Einsatzgebiet Vorgehensmodell Zahlen und Fakten schmutzige Details Komplexität Usecases
ng extreme Role Engineering Einsatzgebiet Vorgehensmodell schm De
Normalisierung g Rollenähnlichkeit extreme Role Engineering Prototyp Demo
extreme Role Engineering Prototyp Demo iet orgehensmodell schmutzige Details Zahlen und Fakten Komplexität Usecases
Geschäftsrollen Anwendungsrollen TUBIS Anwendung Statistiken 3-teiliges Modell Erfahrungen Was ist das Problem? Einsatzgebiet RBAC TUB-spezifisch Motivation Einleitung Normalisierung Rollenähnlichkeit Vorteile Autorisierung extreme Role Engineering Prototyp Demo Nachteile zentral Vorteile dezentral Nachteile Einsatzgebiet Vorgehensmodell Zahlen und Fakten schmutzige Details Usecases Komplexität
Klassisches RBAC Benutzer ID Name Rolle berechtigt zu Recht
Verteilte Administration Strukturtyp Benutzer ID Name Struktureinheit Name 1 1 Recht berechtigt zu Rolle
Kapselung der Anwendungsschicht Strukturtyp wird bereitgestellt wird bereitgestellt Benutzer ID Name Struktureinheit Name 1 1 verwaltet Zugriff auf Anwendungsrolle Name berechtigt zu Recht Geschäftsrolle 1 Anwendung
Eingangsbeispiel im Rollenmodell Strukturtyp wird bereitgestellt wird bereitgestellt Tabelle Studierende: lesen/schreiben Tabelle Räume: lesen/schreiben (eigene) Tabelle Noten: lesen/schreiben Benutzer ID Name Struktureinheit Name 1 1 verwaltet Zugriff auf Anwendungsrolle Name berechtigt zu Recht Geschäftsrolle 1 Anwendung
3-teiliges Modell mit Views Identität Organisation Anwendung Strukturtyp wird bereitgestellt wird bereitgestellt Benutzer ID Name Struktureinheit Name 1 1 verwaltet Zugriff auf Anwendungsrolle Name berechtigt zu Recht Geschäftsrolle 1 Anwendung
Erfahrungen im Bereich rollenbasiertes IdM an der TUB 2001 Campuskarte 2007 Webportal mit rollen-basierter Autorisierung AA-Gateway: Apache, Jetty/Servlet, PHP IdM/RBAC: J2EE Eigenentwicklung ~ 50.000 Entitäten im IdM-System ~ 30 Anwendungen im Portal ~ 500 Einheiten (Fakultät, Institut, Referat...) ~ 3000 Rollen / durchschnittl. ~ 6 pro Einheit
Nutzungshäufigkeit von Diensten im persönlichen Portal für 2009 25% 2% 2% 3% 4% 5% 5% 7% 16% 10% 13% Studierendendaten Super X Typo3 Editorbereich Konto und Rollen Softwareportal Personaldaten Rollenverwaltung Mailingliste beantragen LinF Rollenverwalter und IT-Betreuerliste PW-Änderung Noteneingabe Modulverwaltung (POS) Gastaccounts Hardwareportal (Sofort-PC) Antrag Typo3-Auftritt IP-Adressenverwaltung Externe Antrag Web-Auftritt (konventionell) Hardwareportal Antrag Hosting Antrag Housing
Rollenverwaltung
Rollenverwaltung
Zentrale Lösung Was verstehe ich darunter? [Szenario-Modell unvollständig] 1 2 3 4 Identifiziere und modelliere (neues) Benutzungsszenario Leite Zugriffsrechte vom Szenario ab Identifiziere Nebenbedingungen Verfeinere das Szenario- Modell [Änderungsfall] 7 6 5 Definiere RBAC Model Leite vorläufige Rollenhierarchie ab Definiere Aufgaben und Arbeitsprofile [Szenario-Modell vollständig] Benutzer Rollen Rechte
Vorteile einer zentralen Lösung Klassischer RBAC-Ansatz: Verteilung der Verantwortung Es existieren Role-Engineering Methoden für eine zentrale Lösung, die zu strukturierten Modellen führen Know-How über Autorisierungsmodell gebündelt Überblick über das gesamte System IT-Dienstleister = Rollendienstleister (Service) Klassischer Weg: Anforderung, Analyse, Implementierung Rollenadministratoren können beraten und prüfen flache Lernkurve als Einstieg für Nicht-Experten Constraints können organisatorisch umgesetzt werden Vertretungsregelungen bei Admins durch Dienstleister
Dezentrale Lösung Was verstehe ich darunter? Benutzer Rollen Rechte
Erfahrungen im Bereich rollenbasiertes IdM an der TUB Kein Bittstellergefühl Reduzierung der Bearbeitungszeit Backuprollen in übergeordneten Einheiten Rollenvertretungen von jedem verwaltbar Flexible selbst gestaltete Struktur Transparenz Verteilung der Verantwortlichkeiten Entlastung der Administratoren Fehlinterpretation durch dritte entfällt Fehler sind lokal beschränkt Sehr guter Überblick über die verwaltete Einheit
Nachteile einer dezentralen Lösung und Maßnahmen Nachteil für lokalen Admin Fehlender Überblick über Rollenmodell Fehlendes Wissen um neue Anwendungen Folgenabschätzung und Konsequenzen Abwesenheit des lokalen Rollenadministrators Fehlendes Anwendungswissen Hohe Komplexität des Modells Maßnahmen Mehrteiliges Modell Anwendungs-, dezentrale/zentrale Rollenadmins Informationspolitik Support Schulungen, Informationen Support Selbst definierte Vertretungen Backuprollen, zentrale Rollenadmins Informationen Anwendungsrollen vordefiniert / Templates Schulung und Support Werkzeuge: GUIs, extreme Role Engineering
extreme Role Engineering Rollendruide :Testmodell :Snapshot [Story nicht umsetzbar] [Fehler im Testfall] Story erstellen Testfälle definieren Verfeinerung Sandboxdefinition Release [Fehler im Wirkbetrieb] Rollback :Story :Testmatrix Templates suchen
Ähnlichkeit von Rollen P 1 P 2 P 3 P 4 C 1 C 2 C 3 read 1 1 1 0 1 1 1 write 1 0 1 0 0 1 0 edit 1 0 0 0 0 1 0 delete 1 0 0 1 0 0 1 d(x, y) = def n x i y i i=1 x/y P 1 P 2 P 3 P 4 C 1 3 0 1 2 C 2 1 2 1 4 C 3 2 1 2 1
Normalisierung des Abstands dn(x, y) = n i=1 x 1 y i n 0.0... 0.5... 1.0 gleich unterschiedlich
Komplexität begrüßung() {O(1)} modellladen() {O(p)} storydefinieren() {O(1)} testmatrixerstellen() {O kandidatenerstellen +O vereinigegleichekandidaten = O(2no 2 )} verfeinerung() {O verfeinerung = O(opn)} sandboxtest() {O(1)} modellspeichern() {O(p)} O xreprozess = O(max(O(no 2 ),O(opn))) O(opn) fürp o
Erfolgreiche Tests xre: Prototyp, Tests mit Echtdaten, eine Testperson, Vergleich mit Handarbeit xre ermöglicht intelligentes Hinzufügen von Rollen für kleine Organisationseinheiten
Geschäftsrollen Anwendungsrollen TUBIS Anwendung Statistiken 3-teiliges Modell Erfahrungen Was ist das Problem? Einsatzgebiet RBAC TUB-spezifisch Motivation Einleitung Normalisierung Rollenähnlichkeit Vorteile Autorisierung extreme Role Engineering Prototyp Demo Nachteile zentral Vorteile dezentral Nachteile Einsatzgebiet Vorgehensmodell Zahlen und Fakten schmutzige Details Usecases Komplexität
Zusammenfassung Erfahrungen an der TU Berlin zeigen Eignung des dezentralen Identitätsmanagements. Anfänglich hoher Schulungsaufwand und Kritik. Inzwischen hohes Maß an Transparenz, Flexibilität und Selbstbestimmung. Fehler und Lücken sind auf Werkzeuge zurückzuführen. Daher Verbesserung und Erweiterung von Methoden und Werkzeugen. Nächster entscheidender Schritt: extreme Role Engineering
Quellen und Kontaktdaten thomas.hildmann@tu-berlin.de http://www.user.tu-berlin.de/hildcatf/