Infrastruktur zur verteilten Authentifizierung und Autorisierung

mit Shibboleth im Rahmen der Deutsche Föderation DFN-AAI

Das Projekt Authentifizierung, Autorisierung und Rechteverwaltung (AAR)

Ato Ruppert, UB Freiburg

Erste Fachtagung für Datenschutzbeauftragte an Hochschulen und anderen wissenschaftlichenEinrichtungen 2007

13./14.9.2007, Berlin

13./14.9.2007 Ato Ruppert 2

Das Projekt AAR

• Partner: UB Freiburg und bis 31.3.2007 UB Regensburg– Seit 10/2006 auch Partner des Deutschen Forschungsnetz, DFN

• finanziert durch das BMBF (PT-NMB+F) und eingebettet in vascoda (http://www.vascoda.de/)

• Laufzeit 01/2005 bis 06/2008:– 2 Jahre Entwicklungs- und Testphase mit der Regionalen Datenbank-

Information Baden-Württemberg (ReDI) und vascoda als Pilotanwendungen

– 1,5 Jahre Aufbau der Deutschen Föderation (mit DFN-Verein)– Laufend: Unterstützung von Einrichtungen und Anbietern bei der

Einführung des Systems, Workshops, Schulungen, Marketing• Der DFN-Verein übernimmt das nachhaltige Dienstangebot

im Jahr 2008 vollständig unter dem Namen DFN-AAI.

13./14.9.2007 Ato Ruppert 3

Gliederung

• Das Szenario im Informationsbereich• Aktuelle Technik und Ziele• Allgemeines zu Shibboleth und Single

Sign-On (SSO)• Datensicherheit und Datenschutz• Weitergabe von Attributen• Aufgaben der Föderation• Einsatzmöglichkeiten, Beispiele, Fazit

13./14.9.2007 Ato Ruppert 4

13./14.9.2007 Ato Ruppert 5

13./14.9.2007 Ato Ruppert 6

13./14.9.2007 Ato Ruppert 7

13./14.9.2007 Ato Ruppert 8

13./14.9.2007 Ato Ruppert 9

13./14.9.2007 Ato Ruppert 10

Bisherige Lösung: IP-Kontrolle

• Authentifizierung und Autorisierung nicht getrennt !– Eine Authentifizierung findet im eigentlichen Sinn nicht statt

• Vorteile: – Sehr einfach– Sicher geringste Datenintensität!

• Nachteil: funktioniert zunächst nur ortsgebunden– Lösungsmöglichkeiten des Ortsbindungsproblems:

• VPN, Proxies, Rewriting Proxies (HAN, EZProxy)

• Unsicherheiten:• Fälschbare IP-Adressen, Offene Proxies

13./14.9.2007 Ato Ruppert 11

Bisherige Lösung: Login/Password

• Authentifizierung durch Login/Password.• Autorisierung ist ein getrennter Schritt.• Datenintensität gering, Daten aber vielfach verteilt

und vom Nutzer kaum noch kontrollierbar.• Falls der Anbieter zusätzliche Daten verlangt, wird

die Datenintensität höher und….• Nutzer gibt zwar bewusst seine Daten weiter, hat

aber keine Alternative.

13./14.9.2007 Ato Ruppert 12

Was wollen wir erreichen?

Nutzer• Der Zugriff auf lizenzierte Inhalte soll unabhängig vom

gewählten Arbeitsplatz und dem Zugriffsweg möglich sein. • Alle lizenzierten Inhalte sollten nach nur einmaliger Anmeldung

zur Verfügung stehen (Single Sign-On).• Möglichst keine Weitergabe von personenbezogenen Daten.Einrichtungen (etwa Hochschulen)• Die Einrichtung soll ein beliebiges Authentifizierungssystem

wählen dürfen und betreibt dazu ein Identity Management System (IdM)

Anbieter • Die lizenzpflichtigen Inhalte der Anbieter sollen vor

unberechtigten Zugriff geschützt werden.

13./14.9.2007 Ato Ruppert 13

Was ist Shibboleth?• Shibboleth ist ein Internet2/MACE-Projekt

(MACE = Middleware Architecture Committee for Education)

• Shibboleth entwickelt eine– Architektur (Protokolle und Profile),– Richtlinien-Strukturen und eine– Open Source-Implementierung

für den einrichtungsübergreifenden Zugriffauf geschützte (Web-)Ressourcen

• Shibboleth basiert auf einem föderativen Ansatz:Die Einrichtung verwaltet und authentifiziertihre Mitglieder und der Anbieter kontrolliertden Zugang zu seinen Ressourcen

13./14.9.2007 Ato Ruppert 14

Warum Shibboleth?

• Autorisierung und Zugriffskontrolle über Attributemit der Möglichkeit zur anonymen/pseudonymenNutzung von Angeboten

• basiert auf bewährter Software und Standards(SAML, XML, SOAP, TLS, XMLsig, XMLenc)

• Aufwand für Integration mit vorhandenem IdMund (webbasierten) Anwendungen in vielen Fällen vergleichsweise gering

• Weltweit hohe Akzeptanz, auch bei kommerziellen Anbietern (Elsevier, JSTOR, EBSCO, Ovid, GBI, CSA, ...)

13./14.9.2007 Ato Ruppert 15

Woher kommt „Shibboleth“?

Hintergrund ist eine Stelle aus dem Alten Testament, Buch Richter Kapitel 12 Vers 5ff:

• Und die Gileaditer nahmen ein die Furt des Jordans vor Ephraim. Wenn nun sprachen die Flüchtigen Ephraims: Laß mich hinübergehen, so sprachen die Männer von Gilead zu ihm: Bist du ein Ephraiter? Wenn er dann antwortete: Nein, so hießen sie ihn sprechen: Schiboleth, so sprach er: Siboleth, und konnte es nicht recht reden. So griffen sie ihn und schlugen ihn an der Furt des Jordans, daß zu der Zeit von Ephraim fielen zweiundvierzigtausend.(Zitat http://www.spiritproject.de/orakel/magie/lyrik/bibel/richter.htm)(vergl. auch: http://www.thebricktestament.com/judges/42000_ephraimites_killed/jg12_04.html)

Das Wort „Shibboleth“ ist somit wohl das erste biometrische Autorisierungsverfahren gewesen !

Shibboleth‘s heute: „Awwer hache derfst misch net!“☺

13./14.9.2007 Ato Ruppert 16

Anbieter

Wie funktioniert Shibboleth?

BenutzerinBenutzerin berechtigt?

(7)gestattet

verweigertZugriff

(9)

neinLokalisierungsdienst(WAYF, IdP Discovery)

(2)

Erstkontakt

Benutzerin angemeldet?

(1)

Heimateinrichtung

(4)

ja

nein

(6)(5) Login

(3)

(8)

13./14.9.2007 Ato Ruppert 17

Anbieter

Wie funktioniert Shibboleth?

Benutzerin

gestattet

verweigertZugriff

(9)

Benutzerin bekannt?

(1)

ja

nein

ja(2)

Folgekontakt (gleicher Anbieter)

Benutzerin berechtigt?

(7)

13./14.9.2007 Ato Ruppert 18

Anbieter

Wie funktioniert Shibboleth?

BenutzerinBenutzerin berechtigt?

(7)gestattet

verweigertZugriff

(9)

neinLokalisierungsdienst(WAYF, IdP Discovery)

(2)

Folgekontakt anderer Anbieter

Benutzerin bekannt?

(1)

Heimateinrichtung

(4)

ja

nein

(6)

(3)

(8)

13./14.9.2007 Ato Ruppert 19

Wie funktioniert Shibboleth?Datensicherheit

WAYF

Anbieter

Service-ProviderMetadatenOptional: lokaler WAYF, Rechteserver

Cient-Zertifikat

Heimateinrichtung

Identity-ProviderMetadaten

Optional: ShARPE/Autograph

Server-Zertifikat

SSL SSLServer-

ZertifikatServer-

Zertifikat

Server-Zertifikat

Zugangskontrolle

Web-RessourceIdentity-Management

Authentifizierungsverfahren

Zertifikat

SSL

BrowserdesBenutzer

Metadaten

13./14.9.2007 Ato Ruppert 20

Attribute• Personen erhalten elektronische Identität (IdM)

– Attribute beschreiben die Rolle der Person

• Attribute bilden die Grundlage für die Autorisierung und Zugriffskontrolle in Shibboleth:

– Identity-Provider stellen mit Attributen die notwendigen Informationen über ihre Benutzer zur Verfügung. (IdP).

– Service-Provider werten die Attribute anhand ihrer Regeln aus und gestattenoder verweigern je nach Ergebnis den Zugriff (SP).

• Hierfür sind Absprachen zwischen Identity- und Service-Providern notwendig, die durch Verwendung eines einheitlichen Attributschemas vereinfacht werden!

• Das Attributschema der deutschen Föderation DFN-AAIbasiert auf internationalen Standards.

• Voraussetzung sind verlässliche Benutzerdaten, also ein funktionierendes lokales Identity-Management!

13./14.9.2007 Ato Ruppert 21

Anforderungen an IdM, die sich aus dem föderativen Verfahren ergeben

• Qualitätsanforderungen– Verlässlichkeit: Sicherheitsstufen,

Missbrauchsverhinderung– Aktualität: zeitnahe Änderung– Nachvollziehbarkeit: Dokumentation, Logging– Ausfallsicherheit: Back-up-Systeme

• Einklang mit rechtlichen Vorgaben– Datenschutzgesetz, vor allem: Datensparsamkeit

13./14.9.2007 Ato Ruppert 22

Fragen bei der Nutzung des IdMzur Authentifizierung und Autorisierung

• Zulässigkeit (wozu wurden Daten erhoben?)• „Zweckändernde Verarbeitung“ (§14 BDSG) liegt vor, daher: BDSG §14 Abs. 2 Nr. 2 der Betroffene eingewilligt hatoder: BDSG §14 Abs. 2 Nr. 3: keine Zustimmung nötig,

offensichtlich ist, daß es im Interesse des Betroffenen liegt, und kein Grund zu der Annahme besteht, daß er in Kenntnis des anderen Zwecks seine Einwilligung verweigern würde …

13./14.9.2007 Ato Ruppert 23

Weitergabe: § 16 Abs.1 Nr.2

• Weitergabe von Daten (§15, §16 BDSG)

§ 16 Datenübermittlung an nichtöffentliche Stellen(1) Die Übermittlung personenbezogener Daten an

nichtöffentliche Stellen ist zulässig, wenn …2. der Dritte, an den die Daten übermittelt werden, ein

berechtigtes Interesse an der Kenntnis der zu übermittelnden Daten glaubhaft darlegt und der Betroffene kein schutzwürdiges Interesse an dem Ausschluss der Übermittlung hat.

…

13./14.9.2007 Ato Ruppert 24

eduPersonEntitlement: Beispiele

• urn:mace:dir:entitlement:common-lib-terms Benutzer ist berechtigt, die von der Einrichtung lizenzierten Ressourcen zu nutzen (NUR Standardverträge)

• urn:mace:ebsco.com:entitlement:<EBSCO-Account>Benutzer darf die auf dem <EBSCO-Account> der Einrichtung verfügbaren Ressourcen nutzen

• urn:mace:ub.uni-freiburg.de:entitlement:unist:redi:adminBenutzer der Universität Stuttgart mit Administratorrechten in ReDI

In jeden Fall: Absprachen zwischen IdP und SP notwendig!

13./14.9.2007 Ato Ruppert 25

eduPersonScopedAffiliation

• Ermöglicht die Zuordnung der Benutzer einer Einrichtung zu einigen grundlegenden Rollen

• Zulässige Werte: member, faculty, staff,employee, student, alum und affiliate

• Beispiel: member@uni-freiburg.de• Erste Implementierungen von kommerziellen Anbietern

(EBSCO) basierten auf diesem Attribut.• Probleme:

– Semantik ist auf internationaler Ebene nicht wirklich einheitlich festgelegt (Was genau ist z.B. ein student?)

– Es fehlen wichtige Rollen wie „walk-in patron“, „on campus“.

13./14.9.2007 Ato Ruppert 26

eduPersonTargetedID

• Eindeutiges, persistentes Pseudonym des Benutzers für einen Service-Provider

• Ermöglicht die Wiedererkennung des Benutzers (z.B. bei personalisierten Anwendungen), ohne die Identität des Benutzers zu kennen

• Erschwert das Zusammenführen von Informationen über einen Benutzer seitens der Service-Provider

• Beispiel: „Ruppert,EBSCO“ wird durch MD5 zu: „be83f47a1e56631eceddde08e8a76fa3“

13./14.9.2007 Ato Ruppert 27

eduPersonPrincipalName

• Eindeutiger, persistenter Identifier des Benutzers inklusive Domain ("NetID")

• Beispiel: ruppert@uni-freiburg.de• Sollte aus Datenschutzgründen nur verwendet werden,

wenn die Nutzung des Dienstes nicht anonym oder pseudonym erfolgen kann!

• Anwendungsbeispiel: Schreibender Zugriff auf eine Anwendung (z.B. Wiki, Forum oder Repositorium ), bei der der Autor sich zu erkennen geben muss.

• Weitergabe NUR unter Beachtung des Datenschutzgesetzes!

13./14.9.2007 Ato Ruppert 28

Weitergabe von Attributen: Das Modell ShARPE Autograph (MAMS)

• Die Attribute, die an einen Service-Provider weitergegeben werden, werden den Benutzern in Form von Visitenkarten präsentiert.

• Benutzer können für jeden Service-Provider individuelle Visitenkarten erstellen.

• Die Bedienung ist sehr intuitiv:– Streichen von Attributen schränkt die verfügbaren Dienste

entsprechend ein– Auswahl eines gewünschten Dienstes fügt automatisch die

notwendigen Attribute hinzu

13./14.9.2007 Ato Ruppert 29

Visitenkartenmodell von MAMS

Auswirkung:Ohne Mail-Adresse ist Nutzung des Alert-Dienstes nicht möglich.

X

X

Namen: Ruppert

Mitgliedstyp: Staff

Mail: ato@uni-freiburg.de

X

Sie geben folgende Daten an den Dienstanbieter weiter. Wenn Sie einzelne Datennicht weitergeben wollen, löschen Sie bitte die Markierung:

X

Namen: Ruppert

Mitgliedstyp: Staff

Mail:

X

13./14.9.2007 Ato Ruppert 30

Das Modell von SwitchArpViewer

© SWITCH

http

://w

ww

.switc

h.ch

/aai

/sup

port/

tool

s/ar

pvie

wer

.htm

l

13./14.9.2007 Ato Ruppert 31

Die Föderation DFN-AAI• Wo ist das Problem?

– Anbieter muss dem Anwender vertrauen.– Es geht um Geld.– „Vertrauen“ heißt im Geschäftsleben: „Vertrag“.– Es müssen belastbare vertragliche Regelungen getroffen

werden.– Es müssen Regeln für den technischen Betrieb existieren.

• DFN-AAI ist ein Dienst des DFN-Vereins für Wissen-schaftseinrichtungen und (auch für kommerzielle) Anbieter von (Informations)-Ressourcen.

• DFN-AAI schafft das für notwendige Vertrauensverhältnis und einen organisatorischen, technischen Rahmen für den Austausch von Nutzerinformationen zwischen vielen Anwendern und vielen Anbietern.

13./14.9.2007 Ato Ruppert 32

Aufgaben der DFN-AAI

• Vorgabe von Richtlinien (Policy)• Vertragsgestaltung und -abschluss• Public Relations & internationale Vertretung• zentrale betriebliche Aufgaben

– Metadatenverwaltung der teilnehmenden Einrichtungen– WAYF-Server (Discovery-Service)– Testsystem für neue Teilnehmer und neue Software– Web-Portal mit Informationen– Schulung, Beratung

• übernimmt nicht die Lizenzverträge.

13./14.9.2007 Ato Ruppert 33

Einsatzmöglichkeiten von SSO

• Zugang zu geschützten (auch und gerade kommerziellen) elektronischen Informationsangeboten:– E-Zeitschriften, Datenbanken, E-Bücher, ...– Portale (z.B. vascoda, ReDI)– DFG-Nationallizenzen– Repositories

• e-Learning• e-Science• Verwaltungssysteme• Grid-Computing

13./14.9.2007 Ato Ruppert 34

Beispiel: Nationallizenzen: Die Situation heute – institutionelle Nutzer

Verlag-1

Verlag-m

Verlag-2Einrichtung-1

Einrichtung-2

z.B.ReDI

Zugangsvermittlung mitproprietären Verfahren

IP-Kontrolle

IP-Liste

IP-Liste

IP-Kontrolle

IP-Kontrolle

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Kontrolle

13./14.9.2007 Ato Ruppert 35

Beispiel: Nationallizenzen: Die Situation heute – institutionelle Nutzer

Verlag-1

Verlag-m

Verlag-2Einrichtung-1

Einrichtung-2

z.B.ReDI

Zugangsvermittlung mitproprietären Verfahren

IP-Kontrolle

IP-Liste

IP-Liste

IP-Kontrolle

IP-Kontrolle

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Liste

IP-Kontrolle

Einige Zahlen:Der GBV verwaltet für die Nationallizenzen:

- über 70.000 IP-Adressen von- über 360 Einrichtungen- für mehr als 100 Anbieter- mehr als 60 Mill. Nachweisdaten in unterschiedlichen Sammlungen

13./14.9.2007 Ato Ruppert 36

Nationallizenzen…und das Ziel mit Shibboleth

1x1x

NLVHO

ReWritingProxy

Verlag-1

Verlag-m

Verlag-2

Shib idp Shibsp

Shibsp

Shib idp

Shibsp

IP-Ctrl

Ggf mehrere Instanzen (Einrichtungen)

IPListe

IPListe

Falls Einrichtung über IP authentifiziert

IPIP

13./14.9.2007 Ato Ruppert 37

Bibliotheks-dienste

E-Learning

SeminararbeitPersonalisierte

Dienste

E-Mail

Verwaltungs-systeme

IdM

Das Das ProjektProjekt myLoginmyLogin derder UniUni FreiburgFreiburg

13./14.9.2007 Ato Ruppert 38

Single-SignOn mit Shibboleth,ein Login für alle Dienste

Bibliotheks-dienste

E-Learning

SeminararbeitPersonalisierte

Dienste

E-Mail

Verwaltungs-systeme

Das Das ProjektProjekt myLoginmyLogin derder UniUni FreiburgFreiburg

13./14.9.2007 Ato Ruppert 39

Meine Dienste:

Chance und Vision:Authentifizierung & Personalisierung

Mein OLAF-Konto:

derzeit keine

4,50 Eur

51

derzeit keine

Katalogauswahl: Mein Katalog

Meine BibliothekLogout

Meine Einstellungen

Mein Fachportal

E-Learning

13./14.9.2007 Ato Ruppert 40

Fazit oder „wem nützt was“?• Die Nutzer haben deutlich vereinfachte Verfahren beim

Zugang zu lizenzierten Diensten• Die Daten der Nutzer liegen nur noch an einer Stelle

(bei der „Heimateinrichtung“)• Sichere Übertragungswege mit einem weltweit

einheitlichen Verfahren• Die vertrauenswürdige Infrastruktur der Föderation

unterstützt auch die Bedürfnisse der Anbieter • Einheitliche Authentifizierung und Autorisierung

innerhalb einer Einrichtung• Kein direkter Zugang zum Authentifizierungssystem

für alle Administratoren, daher besserer Schutz.

13./14.9.2007 Ato Ruppert 41

Vielen Dank für Ihre Aufmerksamkeit!

AAR ist ein Projekt der UB Freiburg.

Gefördert vom BMBF (PT-NMB+F )AAR kooperiert mit dem DFN-Verein

aar.vascoda.deinfo@aar.vascoda.de

ruppert@ub.uni-freiburg.de