MPG-AAI

From MPDLMediaWiki
Revision as of 07:33, 20 August 2013 by Grossmann (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

MPG-AAI (MPG-wide Authentication and Authorization Infrastructure)[edit]

Offizielle Seite: https://aai.mpg.de/

Ziel[edit]

In der MPG wird ein System eingeführt, das die MPG-Weite Authentifizierung einführt. Damit wird gewährleistet, daß alle MPG-Mitarbeiter mit einer Identität (einem Username und einem Password) auf alle Ressourcen in der MPG zugreifen können, zu denen ihnen Zugriffsrechte gegeben werden.

Basis[edit]

Ein erfolgversprechender Ansatz muß davon ausgehen, dass die Authentifizierung in den Instituten unterschiedlich gehandhabt wird und nicht ohne erhebliche Probleme unifiziert werden kann. Die MPG wird ein Teil von größeren "Identity and Resource Federations" werden. Daraus folgt eine auf gegenwärtigen Trends aufbauende Infrastruktur zu realisieren. Da ein zentrales User Management nicht möglich ist, muss die Benutzerverwaltung weiterhin verteilt erfogen, denn nur die MPIe und die GV kennen "ihre" Benutzer im einzelnen.

Immer mehr nationale und internationale "Identity and Resource Federations" setzen die Shibboleth Middleware ein als sicheres und akzeptiertes Zwischenglied. Wo es möglich ist, setzt Shibboleth auf allgemein anerkannte Standards wie zB. SAML auf. Die MPG sollte sich an die Trends anschließen und keinen eigenen Weg einschlagen.

Prinzip[edit]

Das folgende Bild gibt das Pinzip der Interaktion wieder, wenn man Shibboleth einsetzt. Ein User X ist an einem MPI als Benutzer registriert und will auf Ressourcen zugreifen, die zB. vom MPI Nijmegen und der MPDL zur Verfügung gestellt werden. Die Zugriffe können einzeln, sequentiell (typische Browser-Arbeitsweise) oder auch gemeinsam, parallel (typische Web-Applikations-Arbeitsweise) erfolgen. User X versucht über einen Browser oder eine Applikation auf eine oder mehrere Ressourcen zuzugreifen, die zugriffsgeschützt sind. Er wird daraufhin zurückgewiesen zur Authentifizierungs-Instanz, zB. das MPI Leipzig. Das ist und bleibt das Institut, bei dem User X einen Vertrag und damit auch einen Account hat. Er wird sich dort authentifizieren. Shibboleth wird nun dafür sorgen, dass bestimmte Informationen über diesen User X an die Ressourcen-Anbieter übermittelt werden. Diese externen Services können jetzt die Authorisierung überprüfen und auch vornehmen. Damit bekommt der User oder die Benutzer-Klasse Zugriffsrechte auf diesen speziellen Service.

Shib.gif

Shibboleth ist derart aufgesetzt, dass es Benutzer-Klassen unterstützt wie zB. "alle Direktoren" oder "alle Verwaltungs-Mitarbeiter". Das setzt entsprechende Einträge bei den Benutzer-Attributen und auch in den Authorisierungs-Records voraus. Oftmals werden in der Wissenschaft allerdings Rechte nur an bestimmte Individuen geknüpft, daher muß jeder Benutzer einen eindeutigen Benutzer-Namen haben. Dieser Name muß so gewählt werden, daß er auch über die MPG-Grenzen hinaus verwendbar ist. Alles basiert auf entsprechenden Nutzer-Klassifikationen und Abkommen, die eine Domäne des Vertrauens schaffen - daher der Begriff der "Federations".


Die teilnehmenden Institute müssen die Shibboleth Identity Provider Komponente installieren und ihr lokales Authentifizierungs-System entsprechend anpassen, wenn ihre Benutzer in der Föderation akzeptiert werden sollen. Die Shibboleth Service Provider, also diejenigen die einen Dienst anbieten, müssen ihrerseits die Shibboleth Service-Provider-Komponente installieren und ihr lokales Resource Management System entsprechend anpassen.

Die Interaktion darf nur zwischen zertifizierten Servern und Services vorgenommen werden, wobei hier die EUGridPMA und TERENA spezifizierten Zertifikate zur Anwendung kommen, die jeweils PKI System-basiert zu signieren sind.

Meetings[edit]

eScience Seminar May 2007[edit]

The eScience Seminar was dedicated to "Secure server and service systems" and specially focused on Flexible Roaming and Shibboleth Infrastructures;
a working group was established to apply for a pilot project at the BAR.

Stuttgart 26. July 2007[edit]

Do. 26. July 2007 in MPI Solid State Science, Stuttgart, 10:00 - 17.00.

Topics were federation policies and attribute sets. We had a close look on policy from DFN AAI, please have a look at the presentations below:

Munich 11. Dec 2007[edit]

Fr. 11. December, MPDL, Munich, 10:00 - 15:00

After approval of the BAR application a constituitive meeting for the pilote phase took place

Munich 11. Feb 2008[edit]

the next meeting is scheduled for elaboration on attribute schemes (eduPerson) for the various use cases identified for the pilot phase and further refinement of the project planning

Federations[edit]


Attribute Sets[edit]


Meetings[edit]

April 2008

Unicode[edit]

Unicode


Further Informations[edit]