Identity and Access Management - dfn.de · Identity and Access Management for Complex Research Data...

Identity and Access Managementfor Complex Research Data Workflows

Richard Zahoransky, Saher Semaan, Klaus [email protected], [email protected], [email protected]

DFN-Forum 2013, Erlangen04.06.2013

Identity & Access Management for Complex Research Data Workflows - Zahoransky, Semaan, Rechert DFN-Forum 2013 2

Was IdM für uns tun kann

● Ein System, welches Benutzerinformationen speichert

● Dadurch beweisbar, dass– Ein Benutzer eine gültige Person ist

– Ein Benutzer einer bestimmten Organisation angehört

– ...


Was moderne IdM Systeme für uns tun können

● IdM-Systeme übernehmen Authentifizierung und liefern Benutzerinformationen an Dienste und Dienstanbieter

● Dadurch erleichtert IdM Workflows, die mit verteilten Diensten arbeiten

● Jeder einzelne Dienst verlangt nach Authentifizierung● Zum Beispiel liefern universitäre IdM-Systeme den

Angehörigen einfachen Zugang zu– Journalen

– Wissenschaftliche Veröffentlichungen

● Dienste und Dienstanbieter stellen eine Herausforderung für IdM-System dar


Neue Herausforderungen für IdM

● Grob gesagt: Einzelne Dienste entsprechen singulärem Web-Portal

● Neue, große und verteilte Dienste: – Einzelne Dienstanbieter nicht mehr ausreichend

– Komplexere Aufgaben erfordern, dass Dienste miteinander interagieren

● Neue Herausforderungen und Möglichkeiten für moderne IdM-Systeme– 1. Delegation von Benutzerrechten erforderlich

– 2. Neue Authorisierungskonzepte notwendig


Unser praktischer Use Case

● bwFLA Funktionale Langzeitarchivierung● Work in progress● Darstellen von archivierten, komplexen, digitalen

Objekten in einer föderierten Umgebung● Herausforderung:

– 1. Ermöglichen, dass einzelne Dienste im Namen ihres Benutzerkontexts interagieren können

– 2. Implementierung eines föderierten Authentifizierungsschemas

● Ziel: Verbinden der einzelnen Dienste durch bwIdM


Das Projekt bwIDMPartner:

● Die neun Universitäten von Baden-Württemberg

Motivation:● Universitäten bieten verschiedenarti-

ge Dienste an● Hoher Verwaltungsaufwand, um

Dienste einer anderen Universität zu nutzen

● Bedarf an einer Landesweiten IdM-Lösung


Das Projekt bwIDMAnforderung:

● Dezentral: Kein zentrales Nutzermanagement● Redundanzen minimieren: Keine redundan-

ten Informationen speichern● Minimal: IdM-Systeme und Dienste sollten so

wenig wie möglich beeinflusst werden

Ziel:Ein föderiertes IdM für Baden-Württemberg, um Angehörigen den Zugang über Universi-tätsgrenzen hinweg mit ihren lokalen Nut-zeraccount zu ermöglichen


Technologie

● Föderationsfähige Technologie in Universitäten und wissenschaftlichen Einrichtungen: Shibboleth, eine Implementierung von SAML (Security Assertion Markup Language)

– Infrastruktur größtenteils bereits vorhanden (An Universitäten und den meisten Hochschulen)

– Know-how vorhanden

– Unterstützung für Datenschutz

● SAML als Technologie zum Aufbau der Infrastruktur gewählt


Workflow in Shibboleth

● Shibboleth trennt Service Provider und Identity Provider

● Erlaubt eine Föderation zwischen Service Provider and Identity Provider

SP1. User Request

2. Redirect Auth request to IdP

3. User chooses IdP and enters credentials 4. IdP-Answer

sent back

5. deny or grant Access base on IdP-Answer

Memory InstitutionDienstanbieter: Service Provider(SP)

Identitätsmanagement: Identity Provider(IdP)


Shibboleth aus Sicht des Dienstanbieters

● Ein Service Provider (SP) muss seine Benutzer nicht kennen

● Er delegiert Identität- und Nutzer-Management● Der Service vertraut dem Identity Provider (IdP)● Der Service erhält seine Benutzerinformationen

durch den IdP● Anhand dieser Informationen kann der Service

Authorisierungsfragen beantworten


Shibboleth aus Sicht des Benutzers

● Der Benutzer loggt sich an seiner Heimatorganisation ein● Der lokale IdP fragt nach Benutzername und Passwort● Der Benutzer muss sich keine Sorgen machen, dass

sein Passwort gestohlen wird● Besucht der Benutzer weitere Service, stellt der IdP

sicher, dass seine Identität mitreist● Kein weiteres Login notwendig: Single Sign On (SSO)


Shibboleth Login-Prozedur

● Benutzer Login mit Browser● Browser leitet Anfrage an IdP weiter● Benutzer beweist seine Identität (Benutzername und Passwort)● Anwort des IdPs wird an den Service Provider weitergeleitet

Browser IdP SP A

Request for URL

Response (POST)

Loginpage, Login

Authentication Request

Tim

e

Browser redirect

Browser redirect containing security token


Untersuchung des Use-Cases

● Aufgabe: Benutzer benötigt Zugang zu einem komplexen, digitalem Objekt

● Einbindung von drei unabhängigen Einheiten / Diensten:1.Lokaler Bibliotheksservice

● Liefert digitales Objekt und zugehörige Metadaten

2.Föderiertes Software-Archiv ● Bietet standartisierte Software Komponenten

3.Emulationsservice (Emulation-as-a-Service)● Ermöglicht Ausführung der Software und des Objekts


1. Lokale Bibliothek (Bibliothek-Service)

• Management von lokalen, digitalen Objekten

• Interne Zugangsbeschränkung für jedes einzelne Objekt

• Direkter Zugang für den Benutzer


2. Föderiertes Software Archiv

● Verteiltes Software Archiv– Verteiltes Syndikat von

spezialisierten Software Archiven– Gemeinsame Zugangs-API– Zugangberechtigung

• Abonement

• pay-per-use• flat-rate• Zugang pro Benutzer / pro Institution


3. Emulation-as-a-Service

● Syndikat von Emulationsknoten– verteilte / speziell verbundene Dienste– Zugangsberechtigung

• Abonement• Rechenzeit• Zugang pro Benutzer / pro Institution


Überblick

Bibliothek-Service


Shibboleth Login-Prozedur

● Benutzer greift nur über ein Portal zu (lokale Bibliothek)

→ Kein direkter Zugang zum SW-Archiv oder Emulation-Service durch Browser

● Frage: Wie weiß der Backend-Service, dass der Benutzer gültig ist – SSO funktioniert hier nicht

● Antwort: SAML biete ein Profil genannt Enhanced Client or Proxy (ECP)

● ECP bietet eine Funktion genannt „Delegation“– Diese Funktion erlaubt es einem SP sich im Namen seines

Benutzers zu authentifizieren

– Der lokale Bibliotheks-Service kann sich gegenüber dem SW-Archive und dem Emulationsservice authentifizieren


ECP delegation

SAML: Single Sign On (SSO)

ECP delegation

SAML: Security Assertion Markup Language / ECP: Enhanced Client or Proxy (a subset of SAML )

SP A(Bibliothek-Service)

SP B(SW-Archiv)


ECP delegation


ECP delegation



SP B(SW-Archiv)


Was wird von Backend Services benötigt?

● Problem gelöst: Delegation von Benutzer-Identitäten● Jedoch: Welche Informationen wird von den Backend-Services

für Autorisierung benötigt?● Erinnerung: Individuelle, verteilte, lose gekoppelte, föderierte

Dienste● Autorisierung anhand individueller Übereinkünfte (1:1) skaliert

nicht● Wir benötigen globale Abmachungen zwischen Dienst- und

Identitätsanbieter!– Wie soll ein Benutzerkontext repräsentiert werden?

– Wie soll dieser Kontext zwischen den Diensten übermittelt werden?

– Wie soll die Autorisierung anhand des Benutzerkontexts stattfinden?


Übertragung von Benutzerattributen durch Shibboleth

● Unsere Abmachung besteht aus einer Reihe Attributen● Diese Attribute lassen sich durch Shibboleth übertragen● Anhand dieser Attribute kann jeder Dienstanbieter seine

Autorisierung durchführen● Was ist jedoch, falls

– Die Attribute nicht ausreichen, um eine Autorisierung durchzuführen?

– Die Attribute nicht richtig verstanden werden?

– Ein Dienstanbieter zusätzlich eine lokale Datenbank mit Zugangsberechtigungen halten möchte?

→ Hybrides Autorisierungsmodell


Warum hybrides Autorisationsmodell

● Unterschiedliche Organisationen haben unterschiedliche Konzepte von Attributen:– Was sagt das Attribut “affiliation” (Mitgliedschaft)? aus

– Wie lautet die Definition, welche Werte darf es annehmen?

● Student, employee, member, staff … ?

● Trade-off zwischen Autorisierung basierend auf Attributen und Verhandlungsaufwand, um Attribute eindeutig festzulegen


Attribut Schemata

● LDAP-Schema– Weit verbreitet

● eduPerson-Schema– Weit verbreitete

Spezialisierung in wissenschaftlichen Einrichtungen

● eduGain-Schema– EU Schema

● dfnEduPerson-Schema– Deutsche Spezialisierung

● Eigenes Schema?


Zusammenfassung● Umsetzung mehrschichtiger Dienste mit Shibboleth möglich● Aushandeln eines allgemein anerkanntem Set an Attributen

ist schwer● Nur eine Untermenge aller Möglichkeiten abdeckbar● Anhand dieser Untermenge an Attributen lässt sich eine

grobe Autorisierung durch die Diensten durchführen● Der Rest muss an den Diensten lokal implementiert werden,

falls nötig● Zu tun: Ein machbarer Trade-Off zwischen föderierter und

lokaler Autorisierung finden● bwIdM: Entwickeln eines solchen Sets an Attributen

Identity and Access Management - dfn.de · Identity and Access Management for Complex Research Data...

Documents

Transcript of Identity and Access Management - dfn.de · Identity and Access Management for Complex Research Data...