Rieger-Integration bestehender IP-basierter Autorisierung · Failover für Netzwerk-Interfaces wäre möglich, aber Konfig. des Squid schwierig! HTTPS Zugriff auf Verlage / Dienste

Integration bestehender IPIntegration bestehender IP--basierter Autorisierung und basierter Autorisierung und Abrechnung in ShibbolethAbrechnung in Shibboleth--basierte Föderationen basierte Föderationen

Sebastian Riegersebastian rieger@gwdg de

Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen, Germany

[email protected]

3. DFN-Forum Kommunikationstechnologien, 26.5.-27.5.2010, Konstanz

OutlineOutline

Problemstellung

A t i i d Ab h b i Z iff f V lAutorisierung und Abrechnung beim Zugriff auf Verlagsressourcen

• IP-basierte Zugriffskontrolle

• Individuelle Benutzerverwaltung auf der Seite der Verlage

• Föderative Authentifizierung und Autorisierung

Bestehende Lösungsansätze für einen Mandanten

Verwendung von Web-Proxies in Föderationen für IP-basierte Zugriffskontrolle

Lösung für die Abrechnung unterschiedlicher föderierter MandantenKombinierte Forward und Reverse Proxies für IP-basierte Abrechnung

• Failover- und Load-Balancing-Lösung

Fazit und Ausblick

3. DFN-Forum IP-basierte Autorisierung und Abrechnung in Shibboleth-basierten Föderationen 2

ProblemstellungProblemstellung

Web-Zugriff auf Verlagsressourcen (z.B. Online Journals, Paper, ...) muss häufig abgerechnet werden, Nutzungsstatistik für unterschiedliche Kunden

Verlage müssen Zugriffskontrolle implementieren!

Benutzer (z.B. in wissenschaftlichen IT-Strukturen) benötigen Zugriff auf unterschiedliche Verlage

Ei h itli h A th tifi i d A t i i ü h t fü N tEinheitliche Authentifizierung und Autorisierung wünschenswert für Nutzer

Typische Lösung: Single Sign-On für Web-Anwendungen: föderatives (Shibboleth bzw SAML) oder benutzerzentriertes (OpenID OAuth) Identity(Shibboleth bzw. SAML) oder benutzerzentriertes (OpenID, OAuth) Identity Management

Zahl der Verlage die SAML-basierte Zugriffskontrolle unterstützen nimmt zuZahl der Verlage, die SAML-basierte Zugriffskontrolle unterstützen nimmt zu (vgl. DFN-AAI)

Mehrheit der Verlage im Umfeld der MPG setzt jedoch noch auf proprietäre


Mehrheit der Verlage im Umfeld der MPG setzt jedoch noch auf proprietäre Verfahren, bzw. insb. Für Abrechnung auf (Quell-)IP-Adresse

IPIP--basierte Zugriffskontrollebasierte Zugriffskontrolle

Nach wie vor vorrangige Zugriffskontrolle für Universitäten, wiss. Einrichtungen

Beispiel: 80 Institute der Max-Planck-Gesellschaft

Verträge mit Verlagen werden zentral durch Max-Planck Digital Library geschlossen, IP-Bereiche für Institute werden bei Verlagen registriert

Zuordnung der Institute für Autorisierung und Abrechnung wird bei Verlagen üb Q ll IP Ad (B i h ) li i tüber Quell-IP-Adresse (Bereiche) realisiert


Individuelle Benutzerverwaltung durch die VerlageIndividuelle Benutzerverwaltung durch die Verlage

Einige Verlage verwenden (zusätzlich) eigene Benutzerverwaltung

Verlage müssen Benutzerkonten für unterschiedliche Kunden verwalten

Benutzerkonten müssen zeitnah bereitgestellt, gesperrt usw. werden

“zentralisiertes Identity Management” ist schwer zu implementieren in verteilten wissenschaftlichen IT-Strukturen (hohe Fluktuation, Verteilung)

Folge: Benutzer benötigen verschiedene Benutzerkonten für Zugriff auf Verlage

U bilit P bl V d hi d B t dUsability Probleme: Verwendung verschiedener Benutzernamen und Passwörter, Änderung von Passwörtern über mehrere Verlage, Änderung von Kontaktdaten …

Lösung: Dezentrales Identity Management (Föderationen, z.B. DFN-AAI)


Föderative Authentifizierung und AutorisierungFöderative Authentifizierung und Autorisierung

Dezentralisiertes Identity Management: föderativ (SAML-basiert z.B. Shibboleth, simpleSAMLphp) oder benutzerzentriert (z.B. OpenID, OAuth)

Authentifizierung und Autorisierung verteilt über föderierte Service Provider (SP) und Identity Provider (IdP)

Benutzer wählt “Heimat”-IdP an Discovery Service (DS), IdP sendet nach Login digital signierte Assertion an SP, Session am IdP Single Sign-On

IdP überträgt Attribute des Benutzers an SP für Autorisierung (z.B. Instituts-ID)

Einige Verlage betreiben bereits SPs z BEinige Verlage betreiben bereits SPs z.B.integriert in DFN-AAI

Zugriff kann unabhängigZugriff kann unabhängigvon Quell-IP-Adresse desClients erfolgen


Nachteile IPNachteile IP--basierter und föderativer Verfahrenbasierter und föderativer Verfahren

IP-basierte Zugriffskontrolle

Mobilität: Verlagsressourcen nur aus Institutsnetz zugreifbar

Sicherheit: Fälschung von IP-Adressen (Spoofing, Routing Attacken) „keine Authentifizierung“, Subnetze u.U. von unterschiedlichen Institutionen gemeinsam genutzt

Mi b h VPN d P Z iff t il i b t d h V lMissbrauch: VPN- und Proxy-Zugriff teilweise verboten durch Verlage

Föderative Zugriffskontrolle

Aufwand: Komplexe Implementierung für Verlage und Institute

Fehlende Standardisierung: keine Standard Attribute (eduPerson) undFehlende Standardisierung: keine Standard-Attribute (eduPerson) und Werte für Accounting in Föderationen

Komplexität: separate Attribute und Werte für differenzierte Abrechnung


Komplexität: separate Attribute und Werte für differenzierte Abrechnung verschiedener Nutzer (z.B. an Bibliotheken angebundene Einrichtungen)

ProxyProxy--basierter Zugriff auf Verlage in Föderationenbasierter Zugriff auf Verlage in Föderationen

Nachteile föderativer Zugriffskontrolle führen dazu, dass Verlage zumindest für Ab h IP b i t V f h f th ltAbrechnung an IP-basierten Verfahren festhalten

Integration IP-basierter Zugriffskontrolle in Föderationen durch bestehende (Reverse )Proxy Lösungen (http://v1 ezproxy aai mpg de) z B OCLC EZproxy(Reverse-)Proxy-Lösungen (http://v1.ezproxy.aai.mpg.de) z.B. OCLC EZproxy

Authentifizierung und Autorisierung über Shibboleth, Proxy leitet Anfragen an Verlage weiter Verlage ermitteln Kunden durch Quell-IP-Adresse des ProxysVerlage weiter, Verlage ermitteln Kunden durch Quell-IP-Adresse des Proxys


VorVor-- und Nachteile von und Nachteile von ProxiesProxies in Föderationenin Föderationen

Proxies in Föderationen steigern Usability im Vergleich zu IP-basierten Verfahren...

Proxy erlaubt Benutzern Zugriff auf Verlage unabhängig vom Aufenthaltsort

Authentifizierung und Autorisierung wird durch AAI Richtlinien (z.B. zeitnahe Sperrung von Accounts) gewährleistet

Single Sign-On über unterschiedliche im Proxy konfigurierte Verlage

Dank Reverse-Proxy Lösung keine zusätzliche Konfiguration für Clients sowie Verlage erforderlich, Verlage müssen nicht auf Shibboleth (SAML) umstellen

...aber...

Eine einzige Quell IP Adresse für alle ausgehenden Anfragen zu allen VerlagenEine einzige Quell-IP-Adresse für alle ausgehenden Anfragen zu allen Verlagen

Nicht akzeptabel für verteilte IT-Infrastrukturen mit mehreren Mandanten


Abrechnung (Accounting) nur direkt im Proxy implementierbar (Logging)

“Föderativer IP“Föderativer IP--Proxy” für die MPGProxy” für die MPG

Abrechnung unterschiedlicher Kunden in Föderation mit bestehenden Reverse Proxy Lösungen nicht möglich, keine Standards für Accounting in SAML etc.

Großteil der Verlage setzt noch auf IP-basierte Zugriffskontrolle Migrationsszenario erforderlich

„Föderativer IP-Proxy“ kombiniert Reverse und Forward Proxy

V l di SAML i ht t tüt kö i Föd ti fVerlage, die SAML nicht unterstützen, können in Föderation aufgenommen werden Migrationspfad! mobiler Zugriff, Anforderungen der Verlage durch Föderationsrichtlinien umgesetzt, Abrechnung über Quell-IP-Adresse


ImplementierungImplementierung

Reverse Proxy (EZproxy) nutzt Forward Proxy (Squid), Squid hat mehrere virtuelle Netzwerk-Interfaces, ein Interface (und IP) pro Institut

Benutzer greift z.B. auf http://v1.ezproxy.aai.mpg.de zu, Shibboleth Login am EZproxy

IdP übermittelt „ou” Attribut mit eindeutiger ID des Instituts (Domain Name) z.B. institut1.mpg.de

Attribut wird u.a. für group-based Autorisierung am EZproxy verwendet

EZproxy fügt ou” Attribut als X User Header in ausgehenden Request anEZproxy fügt „ou Attribut als X-User Header in ausgehenden Request an nachfolgenden Proxy (Squid) an

Squid verwendet X-User“ Wert zur Auswahl des passenden Ausgangs-Squid verwendet „X-User Wert zur Auswahl des passenden Ausgangs-Interfaces (für das Institut des Benutzers) und sendet Request an Verlag

Quell-IP-Adressen werden wie zuvor von Verlagen auf Institute abgebildet


Quell IP Adressen werden wie zuvor von Verlagen auf Institute abgebildet

DemoDemo 1Portal: http://ezproxy.aai.mpg.de

Shibboleth Login, Test-Zugangfür MPI f. SonnensystemforschungLindau

Zugriff aufl kt i h direkter Zugriff: http://rzblx1 unielektronische

Zeitschriften-bibliothek derUni-Bibliothek

direkter Zugriff: http://rzblx1.uni-regensburg.de.ezproxy.aai.mpg.de/ezeit

Uni BibliothekRegensburg

2

3


Hochverfügbarkeit für den “Föderativen IP Proxy”Hochverfügbarkeit für den “Föderativen IP Proxy”

Proxy wird von 80 Max-Planck-Instituten verwendet, aktuell Zugriff auf ~60 Verlage, zusätzlich Zugriff auf interne Dienste (E-Procurement, Web-Shops etc.)

Hochverfügbarkeit erforderlich: Wissenschaftler hängen von zentralem Proxy ab

Max-Planck-Gesellschaft betreibt zwei Rechen-/Kompetenzzentren: GWDG in Göttingen und Rechenzentrum Garching (RZG)

B id Sit b t ib i I t d Föd ti IP P “ t hi dli hBeide Sites betreiben eine Instanz des „Föderativen IP Proxy“, unterschiedliche IP-Subnetze

Load Balancer (nginx) als zusätzlicher Reverse Proxy vor beiden SitesLoad Balancer (nginx) als zusätzlicher Reverse Proxy vor beiden Sites, ermöglicht Failover für ezproxy.aai.mpg.de

Zentrale IdP Lösungen (IdP Proxy) zusätzlich redundant ausgelegt (Terracotta)Zentrale IdP Lösungen (IdP Proxy) zusätzlich redundant ausgelegt (Terracotta)


IntraIntra--Site Load BalancingSite Load Balancing

Session-aware Web Switching (Load Balancing) erfordert Synchronisation der Session-Informationen, sonst erneutes Login nach Umleitung an zweiten Proxy

Failover Lösung innerhalb einer Site wünschenswert (z.B. Updates, Service ...)

Jede Quell-IP-Adresse kann nur einmal pro Subnetz vergeben werden, schnelles Failovererforderlich (SquidKonfiguration) daherKonfiguration), daherseparate IP-Bereichefür beide Instanzenan einem Standort


Fazit und AusblickFazit und Ausblick

Migrationspfad für Verlage, die noch auf IP-basierte Zugriffskontrolle setzen

Mobiler Zugriff auf Ressourcen ermöglicht, Proxy durch HA kein “bottleneck”

Nachteil: “Verschwendung” von IP-Adressen (4 pro Institut, max 320 Adressen), Failover für Netzwerk-Interfaces wäre möglich, aber Konfig. des Squid schwierig!

HTTPS Zugriff auf Verlage / Dienste problematisch, SSL Verbindung terminiert P CONNECT M th d l bt k i W it b d X U H d !am Proxy, CONNECT Methode erlaubt keine Weitergabe des X-User Headers!

Eingebettete URLs werden durch EZproxy nicht immer umgeschrieben z.B. RSS funktioniert aber z B für URLs in JavaScriptRSS, funktioniert aber z.B. für URLs in JavaScript...

Proxy-Begrenzung bei manchen Web-Seiten (cpan.org max 4, hier 3 Proxies...)

Lösung: „nativer“ SAML Support durch Verlage - DFN-AAI, Accounting Erweiterung für Shibboleth gemeinsam mit FhG, auch für Grid / Cloud relevant


Vielen Dank für Ihre Aufmerksamkeit! Gibt es Fragen?

Documents

Rieger-Integration bestehender IP-basierter Autorisierung · Failover für Netzwerk-Interfaces wäre möglich, aber Konfig. des Squid schwierig! HTTPS Zugriff auf Verlage / Dienste