PowerPoint-Präsentation

Authentifizierung, Autorisierung
und Rechteverwaltung
Das Projekt AAR
ReDI als Pilotanwendung für die
Shibboleth-Authentifizierung
vascoda AG Betrieb und Weiterentwicklung
Köln, 24. August 2005
Bernd Oberknapp, UB Freiburg
Übersicht
•
•
•
•
•
•
•
Das Projekt AAR
Warum AAR?
Wie funktioniert AAR?
Vorteile von AAR
ReDI als Pilotanwendung
Attribute
Föderationen
Bernd Oberknapp, UB Freiburg
2
Das Projekt AAR
•
•
•
•
Partner: UB Freiburg und UB Regensburg
finanziert durch das BMBF
eingebettet in vascoda
Laufzeit 3 Jahre bis Ende 2007:
– 2 Jahre Entwicklungs- und Testphase mit
ReDI und vascoda als Pilotanwendungen
– 1 Jahr Unterstützung von Einrichtungen und
Anbietern bei der Einführung des Systems
Bernd Oberknapp, UB Freiburg
3
Warum AAR?
Authentifizierung, Autorisierung und
Rechteverwaltung sind notwendig um
• den Zugriff auf Ressourcen auf
bestimmte Benutzergruppen oder Benutzer
einschränken und
• den Benutzern Dienste personalisiert
anbieten zu können.
Bernd Oberknapp, UB Freiburg
4
Warum AAR?
Probleme aus Sicht des Anbieters:
• hoher Aufwand für den Schutz von
Ressourcen, insbesondere für einen
differenzierten Schutz
• hoher Aufwand für die Registrierung
und Verwaltung von Benutzern für
personalisierte Angebote
Bernd Oberknapp, UB Freiburg
5
Warum AAR?
Probleme aus Sicht der Einrichtung:
• hoher Aufwand für die Einbindung neuer
Ressourcen in das eigene Angebot
• hoher Aufwand für den Schutz eigener
Ressourcen (z.B. E-Learningmodule)
• Sicherheitsprobleme und technische
Probleme bei heute üblichen Verfahren
Bernd Oberknapp, UB Freiburg
6
Warum AAR?
Probleme aus Sicht des Benutzers:
• mehrfache Authentifizierung für die
Nutzung verschiedener Dienste erforderlich
• verschiedene Benutzerkennungen und
Passworte für verschiedene Dienste
• bei vielen Ressourcen Zugriff nur
innerhalb der eigenen Einrichtung
Bernd Oberknapp, UB Freiburg
7
Was ist AAR?
• AAR ist eine Infrastruktur zur Authentifizierung,
Autorisierung und Rechteverwaltung
• AAR ist ein Single Sign-on System, mit dem
verschiedene Ressourcen mit einem einzigen
Login genutzt werden können
• AAR basiert auf einem föderativen Ansatz:
Die Einrichtung verwaltet und authentifiziert
ihre Mitglieder und der Anbieter kontrolliert
den Zugang zu seinen Ressourcen
• AAR baut auf Shibboleth (Internet2-Projekt) auf
Bernd Oberknapp, UB Freiburg
8
Wie funktioniert AAR?
(1)
Benutzerin bekannt?
(3)
(2)
nein
Lokalisierungsdienst
ja
Benutzerin
(5)
(6)
Benutzerin berechtigt?
(4)
(7)
(9)
ja
gestattet
Zugriff
(8)
Heimateinrichtung
Bernd Oberknapp, UB Freiburg
nein
verweigert
Anbieter
9
Wie funktioniert AAR?
Einrichtung (Identity Provider)
Apache
mod_jk
Tomcat
Authentifizierung
über Tomcat oder
Apache schützt
SSO (HS)
ShibbolethKomponenten
SSO (HS)
Autorisierung
Horizon
Benutzerdaten
Bernd Oberknapp, UB Freiburg
SQL
LDAP
...
AA
ARP
Richtlinien für
die Freigabe
von Attributen
10
Wie funktioniert AAR?
Anbieter (Service Provider)
fragt Attribute
bei der AA ab
definiert, welche Attribute
für den Zugriff auf die
Ressourcen erforderlich
sind
Bernd Oberknapp, UB Freiburg
mod_shib
(shire)
shibd (shar)
RessourceManager (RM)
Ressourcen
Benutzer
authentifiziert?
Apache
AAP
kontrolliert den Zugriff
auf die Ressourcen
11
Vorteile von AAR
Vorteile aus Sicht des Anbieters:
• Ressourcen können differenziert geschützt werden
• keine Benutzerverwaltung auf Seiten des
Anbieters erforderlich
• Integration in vorhandene Systeme ist häufig mit
geringem Aufwand möglich
• Komponenten sind Open Source (Apache-Lizenz,
Version 2.0) und stehen kostenfrei zur Verfügung
Bernd Oberknapp, UB Freiburg
12
Vorteile von AAR
Vorteile aus Sicht der Einrichtung:
• Einbindung neuer Ressourcen in das eigene
Angebot ist sehr einfach
• berechtigten Nutzern anderer Einrichtungen kann
leicht Zugriff auf eigene geschützte Ressourcen
(z.B. E-Learningmodule) gewährt werden
• hohe Sicherheit durch zentrale Authentifizierung
• Komponenten sind Open Source und kostenfrei
Bernd Oberknapp, UB Freiburg
13
Vorteile von AAR
Vorteile aus Sicht des Benutzers:
• Single Sign-on – alle Ressourcen können
mit einem einzigen Account und nach nur
einmaliger Authentifizierung genutzt werden
• Nutzung der Ressourcen ist unabhängig
von Standort und Zugriffsweg möglich
• Datenschutz wird respektiert
Bernd Oberknapp, UB Freiburg
14
AAR „ToDo-Liste“
•
•
•
•
•
ReDI auf Shibboleth umstellen
IPS-Software Shibboleth-fähig machen
weitere Dienste auf Shibboleth umstellen
AAR-Rechteserver aufbauen (Regensburg)
Einrichtungen und Anbieter bei der
Einführung von Shibboleth unterstützen
• deutschlandweite Föderation aufbauen
Bernd Oberknapp, UB Freiburg
15
ReDI als Pilotanwendung
Umstellung von ReDI auf Shibboleth oder:
Wie migriert man einem Dienst mit
Authentifizierung und Autorisierung
über lokale Benutzerdatenbanken für
38 Einrichtungen mit lokal installierten
Komponenten im laufenden Betrieb auf
ein neues Authentifizierungssystem?
Bernd Oberknapp, UB Freiburg
16
ReDI als Pilotanwendung
Aktuelle ReDI-Authentifizierung
Uni Stuttgart
ReDI-Server
ReDI-Login
• Benutzerkennung
• Passwort
• Einrichtungsauswahl
IBplusServer
Bernd Oberknapp, UB Freiburg
ReDI-Server
IBplusAuthServer
Benutzerdaten
FH Heilbronn
IBplusAuthServer
Benutzerdaten
..
.
17
Einrichtungen
ReDI als Pilotanwendung
1. Schritt: Zentrale Implementierung aller
Shibboleth-Komponenten in ReDI
IBplusAuthServer
ReDI-Server
Benutzerdaten
ReDI-Login
Einrichtungsauswahl
FH Heilbronn
HS
AA
Uni Stuttgart
HS
...
Bernd Oberknapp, UB Freiburg
ReDI-Server
Uni Stuttgart
FH Heilbronn
IBplusAuthServer
AA
Benutzerdaten
..
.
18
Einrichtungen
ReDI als Pilotanwendung
• Im ersten Schritt zentrale Implementierung aller
Shibboleth-Komponenten in ReDI:
– ReDI als Service Provider (zusätzlich zu den
anderen ReDI-Authentifizierungsverfahren)
– Identity Provider für alle Einrichtungen
• Zugriff auf Benutzerdatenbanken erfolgt zunächst
auch für Shibboleth über das IBplus-Protokoll, in
den Einrichtungen sind daher keine Änderungen
erforderlich!
Bernd Oberknapp, UB Freiburg
19
ReDI als Pilotanwendung
2. Schritt (optional): Übernahme der
Identity Provider durch die Einrichtungen
ReDI-Server
ReDI-Login
Einrichtungsauswahl
Uni Stuttgart
HS
AA
Benutzerdaten
FH Heilbronn
HS
AA
Benutzerdaten
.
.
.
Bernd Oberknapp, UB Freiburg
ReDI-Server
20
Einrichtungen
ReDI als Pilotanwendung
• Im zweiten Schritt können Einrichtungen
(bei Horizon-Bibliotheken auch das BSZ) den
Betrieb des Identity Providers übernehmen.
• Zugriff auf die Benutzerdatenbanken kann
dann direkt erfolgen, der IBplusAuthServer
wird dann nicht mehr benötigt
• ReDI als Datenbanksystem ist damit aus
Shibboleth-Sicht nur noch Anbieter
Bernd Oberknapp, UB Freiburg
21
Offene Fragen
• Was ist mit Einrichtungen, die über keine
geeignete Benutzerdatenbank verfügen?
• IP-Kontrolle ersetzen durch automatisch
generierte anonyme Accounts?
• Welche Attribute werden für welche
Dienste benötigt?
• Wo werden die Attribute gespeichert?
Alternativen: Benutzerdatenbank, lokale
Rechtedatenbank, AAR-Rechteserver
Bernd Oberknapp, UB Freiburg
22
Shibboleth-Standardattribute
• eduPersonScopedAffiliation
Beispiel: [email protected]
• eduPersonEntitlement
Beispiele: urn:mace:incommon:entitlement:common:1
urn:mace:aar:entitlement:redi:unifr:jura
urn:mace:aar:entitlement:ezb:unirb:admin
• eduPersonPrincipalName
Beispiel: [email protected]
• eduPersonTargetedID
Bernd Oberknapp, UB Freiburg
23
Was ist eine Föderation?
Einrichtungen
Bernd Oberknapp, UB Freiburg
Anbieter
Föderation
24
Was ist eine Föderation?
• Eine Föderation ist ein Zusammenschluss
von Einrichtungen und Anbietern auf Basis
gemeinsamer Richtlinien.
• Eine Föderation schafft das für Shibboleth
notwendige Vertrauensverhältnis
zwischen Einrichtungen und Anbietern und
einen organisatorischen Rahmen für den
Austausch von Benutzerinformationen.
Bernd Oberknapp, UB Freiburg
25
Aufgaben einer Föderation
Aufgaben einer Föderation sind:
• Vorgabe von Richtlinien (Policies)
• Verwaltung der Metadaten der Mitglieder
• Betrieb des Lokalisierungsdienstes
• Betrieb einer Zertifizierungsstelle
• Technischer Support
Bernd Oberknapp, UB Freiburg
26
Aufbau einer Föderation
• Einrichtungen aus dem Hochschulbereich
schließen sich üblicherweise landesweit zu
Föderationen zusammen, zum Beispiel:
USA (InCommon), Großbritannien (SDSS),
Schweiz (SWITCH), Finnland (HAKA)
• Aufbau einer deutschlandweiten Föderation
im Rahmen des DFN wird angestrebt
• Einrichtungen und Anbieter können jeweils zu
mehreren Föderationen gehören!
Bernd Oberknapp, UB Freiburg
27
Weitere Informationen
• AAR-Workshop für potentielle Identity
Provider am 12. Oktober 2005 in Freiburg
• AAR-Webseite
http://aar.ub.uni-freiburg.de/
• Freiburger AAR-Team:
[email protected]
Fragen?
Bernd Oberknapp, UB Freiburg
28