1 / 22

Shibboleth und der föderative Ansatz

Shibboleth und der föderative Ansatz Authentifizierung, Autorisierung und Rechteverwaltung in einem föderativen Umfeld Ato Ruppert UB Freiburg. Übersicht. Authentifizierung, Autorisierung, Rechteverwaltung Motivation Was ist AAR ? Föderationen und Rechtliches. Was wollen wir erreichen?.

zan
Download Presentation

Shibboleth und der föderative Ansatz

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Shibboleth und der föderative Ansatz Authentifizierung, Autorisierung und Rechteverwaltung in einem föderativen Umfeld Ato Ruppert UB Freiburg

  2. Übersicht Authentifizierung, Autorisierung, Rechteverwaltung • Motivation • Was ist AAR? • Föderationen und Rechtliches 2

  3. Was wollen wir erreichen? Leitsätze zur Nutzung verteilter Informationen im Internet aus Sicht der Nutzer, Einrichtungen und Anbieter • 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 Authentifizierung und Autorisierung (Single Sign-On) zur Verfügung stehen. • Einrichtungen (etwa Hochschulen): Die Einrichtung soll ein beliebiges Authentifizierungssystem wählen dürfen. Der Aufwand der Rechteverwaltung soll möglichst gering sein. • Anbieter:Die lizenzpflichtigen Inhalte der Anbieter sollen vor unberechtigten Zugriff geschützt werden. 3 Demo: ReDI

  4. 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 („Reference Linking“) • 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 • AAR ergänzt Shibboleth um einen Rechteserver 4

  5. Wie funktioniert AAR? (1) Benutzerin bekannt? (2) (3) nein Lokalisierungsdienst WAYF Benutzerin ja (5) (6) Benutzerin berechtigt? (4) (9) Zugriff (7) gestattet ja nein verweigert (8) Heimateinrichtung Anbieter 5

  6. AAR verwendet ShibbolethV 1.3 (später 2.0) Shibboleth baut auf folgende Standards auf: HTTP XML XML Schema (XSD) XML Signatur (XMLDisg) SOAP SAML 1.1 (später 2.0) Wie funktioniert AAR? HTTP/HTTPS SOAP Nachricht SOAP Header SOAP Body SAML Anfrage/Antwort 6

  7. Wie funktioniert AAR?(auf der Einrichtungsseite) Apache mod_jk Einrichtung (Identity Provider) Tomcat Authentifizierung über Tomcat oder Apache schützt SSO (HS) Autorisierung SSO (HS) Attribute Authority Richtlinien für die Freigabe von Attributen ARP ... LDAP Benutzerdaten SQL 7

  8. Wie funktioniert AAR?(auf der Anbieterseite) Anbieter (Service Provider) Ressourcen Apache Assertion Consumer Service Access Control R fragt Attribute bei der AA ab Attribute Requester definiert, welche Attribute für den Zugriff auf die Ressourcen erforderlich sind AAP kontrolliert den Zugriff auf die Ressourcen 8

  9. Was ist eine Föderation? • Eine Föderation ist ein Zusammenschluss von Einrichtungen und (auch kommerziellen) 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. • DFN und AAR bauen gemeinsam eine deutschlandweite Föderation auf. 9

  10. Aufbau einer Föderation Für den AufbaueinerFöderation muss (mindestens) festgelegt werden: • Organisationsstruktur • Voraussetzungen für die Mitgliedschaft • Rechte und Pflichten der Föderation und Mitglieder • Richtlinien • Aufnahmeverfahren für neue Mitglieder • Aktualisierung der Metadaten • akzeptierte (CA-)Zertifikate • Standardattribute, Datenschutz • Vorgehensweise bei Missbrauch 10

  11. Föderation als Konsortium mit externer Verwaltung Die organisatorischen Aufgaben zu AAR werden extern vergeben. Alle Entscheidungen verbleiben in der Föderation. Verträge: Multilateral mit allen Beteiligten Grenze: Größe der Föderation Föderation En E1 Externer Verwalter (DFN) E… Externer Verwalter E2 E4 E3 11

  12. Föderation als Dienstangebot des DFN Die organisatorischen Aufgaben werden als Dienst des DFN den Einrichtungen der Föderation angebotenen und von der Föderation kontrolliert. Verträge: Bilateral zwischen Teilnehmer und zentraler Einrichtung Beispiele: Switch, Haka, InCommon Föderation En E1 E… DFN E2 E5 E4 E3 12

  13. Teilnehmer der Föderation und ihre Rollen • Mitglieder (Unis, FHs, etc): • Einrichtung = Identity Provider • Anbieter (etwa eLearning-Angebote) • Partner • Anbieter (auch kommerzielle!) • Steuerungsgremien • Überwachung und Entscheidung • Operator • Koordinationsdienst für die Föderationsverwaltung 13

  14. Beispiel: Haka/Finnland(Quelle: Mikael Linden, CSC) Die Organisationsstruktur von Haka entspricht der von SWITCHaai Operator CSC – scientific computing ltd Central AAI services Federation members Federation partners Advisory comm. Operations comm. IdP Palvelu IdP Palvelu Palvelu IdP Palvelu Palvelu SP SP Palvelu SP SP SP SP 14

  15. Vorgabe von Richtlinien (Policies) Verwaltung Metadaten der Mitglieder Betrieb eines Lokalisierungsdienstes Betrieb einer Zertifizierungsstelle Betrieb einer Testumgebung Technischer Support Status inArbeit: DFN, AAR inArbeit: DFN, AAR verfügbar: AAR verfügbar: DFN verfügbar: AAR verfügbar: AAR Dienste des Föderationsoperators 15

  16. Datenschutz 1 (Datenhaltung) Europäisches Recht (Art. 6): PersonenbezogeneDaten dürfen nur für spezielle Aufgaben verarbeitet werden! • Die Einrichtungen (= Identitiy Provider) müssen den Zweck der Datenhaltung festlegen und beschreiben. In Universitäten z.B. (verkürzt): Unterstützung von Forschung und Lehre. Daraus folgt: • Die Ziele aller Mitglieder einer Föderation müssen diesem Zweck entsprechen! (Bei Unis u.a. ist das per se so) Auf Seiten der (auch kommerziellen) Dienstanbieter (SP): • Z.B. Buchhandel, ZS-Verlage, wiss. Infodienste: Ja • Z.B. EBAY, Kaufhäuser: Nein • Behörden: ? 16

  17. Datenschutz 2 (Weitergabe von Attributen) Europäisches Recht (Art. 7), §§18-20 LDSG-BW: Weitergabe personenbezogener Daten nur wenn notwendig • Zur Vertragserfüllung (mit den Anbietern) • Gesetzliche Grundlagen vorliegen • Zum Schutz vitaler Interessen (der Anbieter) • Zur Erfüllung der Leistung eines Auftrages (des Anbieters) • und 5. Nach ausdrücklicher Zustimmung der betroffenen Person Fazit: Bei der Gründung der Föderation muss der Zweck festgelegt werden! 17

  18. Attribut-Schemata • Mehrere Grundlagen liegen vor: • eduPerson Specification (internet2) • funetEduPerson (Haka) • SCHAC-IAD Version 1.0.0 (Terena) • SwissEduPerson (Switch) Beachte: Weltweite, kommerzielle Partner halten sich bisher i.a. an eduPerson! (wg. InCommon) 18

  19. Shibboleth-Standardattribute • Shibboleth/InCommon-Standardattribute basieren auf dem eduPerson-Schema:http://www.incommonfederation.org/docs/policies/federatedattributes.html • Internationale Anbieter halten sich üblicherweise an diesen Standard (insb. eduPersonEntitlement) • Anbieter kommen meistens mit einigen wenigen Attributen aus, die in der Shibboleth-Software bereits vorkonfiguriert sind • Beispiele: • eduPersonScopedAffiliation (member@..., staff@...) • eduPersonTargetedID (r12345z@...) • eduPersonPrincipalName (ruppert@uni-freiburg.de) 19

  20. Zum Abschluss:Stand und Ausblick zum Projekt • Alle Komponenten von Shibboleth sind in einer Testumgebung verfügbar • Gespräche mit Dienstanbietern entwickeln sich sehr positiv (im Rahmen von Kaufverhandlungen, etwa 100 kommerzielle Service Provider) • ReDI wurde im Januar auf Shibboleth umgestellt (mit einer „internen“ Föderation, etwa 60 Identity Provider) • Die Betriebssoftware IPS von vascoda wird bis Mitte 2006 auf Shibboleth umgestellt • Der Rechteserver wird bis Mitte 2006 als Prototyp zur Verfügung stehen. • Am 23. März 2006 wird ein Workshop für Anbieter in Freiburg stattfinden 20

  21. Links • Allgemeines • http://aar.vascoda.de/links.php • http://www.terena.nl/tech/ • http://www.geant2.net/upload/pdf/GN2-05-192v6.pdf • Attribut-Schemata • http://www.csc.fi/suomi/funet/middleware/valinen/funetEduPerson_1_0.pdf • http://www.nmi-edit.org/eduPerson/draft-internet2-mace-dir-eduperson-00.html • http://www.terena.nl/tech/task-forces/tf-emc2/docs/schac/schac-schema-IAD-rc2.pdf • http://www.switch.ch/aai/docs/swissedu.schema • http://www.incommonfederation.org/docs/policies/federatedattributes.html • Datenschutz • http://www.bfdi.bund.de/DE/Home/homepage__node.html • http://www.baden-wuerttemberg.datenschutz.de/recht/ldsg/default.htm • EU-Richtlinie 21

  22. Danke für Ihre Aufmerksamkeit! AAR ist ein Projekt der UB Freiburg und UB Regensburg. Gefördert vom BMBF (PT-NMB+F ) aar.vascoda.de info@aar.vascoda.de ruppert@ub.uni-freiburg.de 22

More Related