Das Projekt AAR ReDI als Pilotanwendung für die Shibboleth-Authentifizierung vascoda AG Betrieb und Weiterentwicklung Köln, 24. August 2005 Bernd Oberknapp,

Das Projekt AAR ReDI als Pilotanwendung für die

Shibboleth-Authentifizierung

vascoda AG Betrieb und WeiterentwicklungKöln, 24. August 2005

Bernd Oberknapp, UB Freiburg

Authentifizierung, Autorisierung und Rechteverwaltung

Bernd Oberknapp, UB Freiburg 2

• Das Projekt AAR

• Warum AAR?

• Wie funktioniert AAR?

• Vorteile von AAR

• ReDI als Pilotanwendung

• Attribute

• Föderationen

Übersicht


• Partner: UB Freiburg und UB Regensburg• finanziert durch das BMBF• eingebettet in vascoda• Laufzeit 3 Jahre bis Ende 2007:

– 2 Jahre Entwicklungs- und Testphase mitReDI und vascoda als Pilotanwendungen

– 1 Jahr Unterstützung von Einrichtungen und Anbietern bei der Einführung des Systems

Das Projekt AAR


Authentifizierung, Autorisierung undRechteverwaltung sind notwendig um

• den Zugriff auf Ressourcen auf bestimmte Benutzergruppen oder Benutzer einschränken und

• den Benutzern Dienste personalisiert anbieten zu können.

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

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

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

Warum 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 authentifiziertihre Mitglieder und der Anbieter kontrolliertden Zugang zu seinen Ressourcen

• AAR baut auf Shibboleth (Internet2-Projekt) auf

Was ist AAR?


Wie funktioniert AAR?

Heimateinrichtung

Benutzerin

Anbieter

Benutzerin bekannt?(1)

(4)(5) Benutzerin berechtigt?

(6)

(7)

(8)

gestattet

verweigertZugriff

(9)ja

nein

ja

neinLokalisierungsdienst(2)(3)



Apachemod_jk

Tomcat

SSO (HS)

AALDAP

ARP

Horizon

SQL

Authentifizierung über Tomcat oder Apache schützt

SSO (HS)Autorisierung

Einrichtung (Identity Provider)

BenutzerdatenRichtlinien für die Freigabe

von Attributen...

Shibboleth-Komponenten



Apache

mod_shib(shire)

AAP

Anbieter (Service Provider)

shibd (shar)

Ressourcen

Benutzer authentifiziert?

fragt Attribute bei der AA ab

definiert, welche Attribute für den Zugriff

auf die Ressourcen erforderlich sind

Ressource-Manager (RM)

kontrolliert den Zugriff auf die Ressourcen


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

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

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ängigvon Standort und Zugriffsweg möglich

• Datenschutz wird respektiert

Vorteile von AAR


• 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

AAR „ToDo-Liste“


Umstellung von ReDI auf Shibboleth oder:

Wie migriert man einem Dienst mit Authentifizierung und Autorisierungüber lokale Benutzerdatenbanken für38 Einrichtungen mit lokal installierten Komponenten im laufenden Betrieb auf ein neues Authentifizierungssystem?

ReDI als Pilotanwendung



Aktuelle ReDI-Authentifizierung

...ReDI-Server Einrichtunge

n

IBplusAuthServer

Benutzerdaten

Uni Stuttgart

• Benutzerkennung• Passwort• Einrichtungsauswahl

ReDI-Login

ReDI-Server

IBplusServer Benutzerdaten

FH Heilbronn

IBplusAuthServer



1. Schritt: Zentrale Implementierung allerShibboleth-Komponenten in ReDI

ReDI-Server Einrichtungen

Benutzerdaten

Uni Stuttgart

Einrichtungsauswahl

ReDI-Login

ReDI-Server

Benutzerdaten

FH Heilbronn

FH Heilbronn

HS AA

Uni Stuttgart

HS AA

IBplusAuthServer

IBplusAuthServer

. . ....


• 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!




2. Schritt (optional): Übernahme derIdentity Provider durch die Einrichtungen

.

.

.

ReDI-Server Einrichtungen

Benutzerdaten

Uni Stuttgart

Einrichtungsauswahl

ReDI-Login

ReDI-Server

Benutzerdaten

FH Heilbronn

HS AA

HS AA



• 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


• 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

Offene Fragen


• eduPersonScopedAffiliationBeispiel: [email protected]

• eduPersonEntitlementBeispiele: urn:mace:incommon:entitlement:common:1 urn:mace:aar:entitlement:redi:unifr:jura urn:mace:aar:entitlement:ezb:unirb:admin

• eduPersonPrincipalNameBeispiel: [email protected]

• eduPersonTargetedID

Shibboleth-Standardattribute

Bernd Oberknapp, UB Freiburg 24Föderation

Was ist eine Föderation?

Einrichtung Anbieteren


• 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.

Was ist eine Föderation?


Aufgaben einer Föderation sind:

• Vorgabe von Richtlinien (Policies)

• Verwaltung der Metadaten der Mitglieder

• Betrieb des Lokalisierungsdienstes

• Betrieb einer Zertifizierungsstelle

• Technischer Support

Aufgaben 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!

Aufbau einer Föderation


Weitere Informationen

• AAR-Workshop für potentielle Identity Provider am 12. Oktober 2005 in Freiburg

• AAR-Webseitehttp://aar.ub.uni-freiburg.de/

• Freiburger AAR-Team:[email protected]

Fragen?

http://aar.ub.uni-freiburg.de/

mailto:[email protected]

Documents

Das Projekt AAR ReDI als Pilotanwendung für die Shibboleth-Authentifizierung vascoda AG Betrieb und Weiterentwicklung Köln, 24. August 2005 Bernd Oberknapp,