-\section{Weitergehende Benutzerauthorisierung}
+\section{Weitergehende Benutzerautorisierung: eduGAIN}
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=0.6\textwidth]{edugain-arch.png}
+ \caption{eduGAIN-Architektur~\cite{Lopez2008418}}
+ \label{fig:edugain}
+\end{figure}
-Um erweiterte Benutzerauthorisierung zu implementieren, führen López et al. \cite{Lopez2008418}\cite{Lopez2007900} ein weiteres Modell namens \emph{\acr{NAS-SAML}} ein, das zur Verwaltung und Abfrage von Authorisierungsattributen genutzt werden kann. Es kennt folgende Entitäten:
+Um erweiterte Benutzerautorisierung zu implementieren, wurde das \emph{eduGAIN}-Projekt gestartet. Es hat zum Ziel, existierende Institutionen durch eine Authentifizierungs- und Autorisierungs-Infrastuktur zu verbinden. Die Infrastruktur (siehe Abb. \ref{fig:edugain}) besteht aus \emph{Bridged Elements} (BE), die von den Institutionen gestellt werden und die Kommunikation zwischen Institutionen regeln sowie Authentifizierungs- und Autorisierungsinformationen bereitstellen; und zum anderen einem \emph{MetaData Service} (MDS), der Metadaten über existierende Bridged Elements sammelt und zwischen ihnen vermittelt. Er dient als zentraler Lokationsservice, den ein Bridged Element benutzt, um zum Austausch von Autorisierungsinformationen mit Bridged Elements anderer Institutionen Kontakt aufzunehmen.
+
+Im Kontext von eduGAIN führen López et al. \cite{Lopez2008418}\cite{Lopez2007900} ein weiteres Modell namens \emph{\acr{NAS-SAML}} ein, das zur Verwaltung und Abfrage von Autorisierungsattributen genutzt werden kann und auf den XML-basierten Sprachen SAML (\emph{Security Assertion Markup Language}) und XACML (\emph{eXtensible Access Control Markup Language}) basiert. Mittels SAML werden Authentifizierungs- und Autorisierungsinformationen ausgetauscht, während XACML dazu genutzt wird, Richtlinien für die Autorisierung zu definieren.
+
+Auch in diesem Modell hat jeder Benutzer eine Heiminstitution, die eine Menge von Attributen zu ihm speichert, beispielsweise seine Gruppenzugehörigkeit. Die Institution, bei der der Benutzer zu Gast ist, wird \emph{Remote Instutition} genannt. Das Modell kennt zudem folgende Entitäten:
\begin{itemize}
+ \item die RADIUS-Server in der Home und Remote Institution, die für die Authentifizierung in eduroam genutzt werden
+ \item den \emph{Identity Provider}, eine Entität der Home Institution, die die Authentifizierungs- und Autorisierungsinformationen über deren Benutzer speichert
\item einen \emph{Policy Decision Point} in der besuchten Institution, der den Zugriff auf bestimmte Netzwerkressourcen regelt
- \item ein \emph{edu\acr{GAIN} Bridged Element}, das die Kommunikation zwischen Institutionen regelt sowie Authentifizierungs- und Authorisierungsinformationen bereitstellt
\end{itemize}
-Die Authentifizierungsphase über \acr{RADIUS} wird dahingehend erweitert, dass das Bridged Element der Heiminstitution des Benutzers als Interface zwischen dem \acr{RADIUS}-Server der Heiminstitution und dem Identity Provider arbeitet, und zusätzlich dem \acr{RADIUS}-Server der besuchten Institution eine Zugriffsnummer mitgibt, mit der weitere Benutzerattribute abgerufen werden können. Das Bridged Element der besuchten Organisation ist dafür zuständig, Authorisierungsanfragen des \acr{RADIUS}-Server seiner Institution zu beantworten, indem er die Anfrage an die Heiminstitution des Benutzers weiterleitet, wobei die vorher erhaltene Zugriffsnummer als Schlüssel dient, um dem Bridged Element der Heiminstitution die Berechtigung nachzuweisen. Aufgrund dieser abgefragten Attribute ist der Policy Decision point in der besuchten Institution imstande, Authorisierungsentscheidungen zu treffen und den Zugriff auf Netzwerkressourcen zuzulassen oder zu verweigern.
+Die Kommunikation zwischen \acr{RADIUS}-Server und Bridged Element findet bevorzugt über \acr{LDAP} (Lightweight Directory Access Protocol) statt; einem weit verbreiteten Protokoll zur Abfrage von Daten aus einem Verzeichnis. Bridged Elements verständigen sich untereinader über \acr{SAML}, das im XML-basierten \acr{SOAP} über HTTP oder ähnliche Protokolle auf Anwendungsschicht gekapselt wird, um Prozeduren auf entfernten Systemen aufzurufen (sog. \emph{Remote Procedure Call}).
+
+Die Authentifizierungsphase über \acr{RADIUS} wird dahingehend erweitert, dass der Server der Home Institution dem anfragenden Server der Remote Institution in der RADIUS-\emph{Access-Accept}-Nachricht ein \emph{Handle} mitgibt, mit dem dieser über das Bridged Element seiner Institution weitere Attribute des Benutzers abfragen kann. Das Bridged Element der Remote Institution leitet die Autorisierungsanfragen über SAML an das Bridged Element der Heiminstitution weiter, wobei das vorher erhaltene Handle als Schlüssel dient, um dem Bridged Element der Heiminstitution die Berechtigung nachzuweisen.
+
+Die empfangenen Attribute wiederum verwendet das Bridged Element der Remote Institution, um den Policy Decision Point nach einer endgültigen Autorisierungsentscheidung zu fragen, und schließlich dem RADIUS-Server der Remote Institution mitzuteilen, ob der Zugriff auf die vom Benutzer angeforderten Netzwerkressourcen zuzulassen oder zu verweigern ist.
-Die Kommunikation zwischen \acr{RADIUS}-Server und Bridged Element findet bevorzugt über \acr{LDAP} statt; die Bridged Elements verständigen sich über das in der edu\acr{GAIN}-Architektur spezifizierte, XML-basierte Protokoll \acr{SAML}, das in \acr{SOAP} gekapselt wird.
+%\subsection{Status und Alternativen}
+eduGAIN befindet sich zur Zeit in einer Testphase, an der die Länder Deutschland, Kroatien, Finnland, die Tschechische Republik, Polen und die Schweiz teilnehmen. \cite{edugain.org}
projects / seminar-bachelor.git / blobdiff