\subsection{Shiro}

Shiro ist ein Apache-Projekt und ein Framework, welches Methoden zu
Authentifizierung, Authorisierung, Kryptographie und Session Management
anbietet. Es arbeitet unabhängig von der Art der Anwendung, erlaubt also sowohl
Desktop- als auch Webanwendungen. Für letzteres gibt es weitergehende
Unterstützung, z. B. durch automatisches Setzen von Cookies.

\subsubsection{Authentifizierung}

Mittelpunkt der Sicherheitsarchitektur ist ein \emph{security manager}, der zu
Beginn ein \emph{token}, welches die Anmeldedaten des Nutzer enthält,
entgegennimmt. Dieses wird dann an einen \emph{authenticator} weitergeleitet, in
der Regel der \lstinline~ModularRealmAuthenticator~. Dieser wiederum ist in der
Lage, eine Authentifizierung gegen einen oder mehrere \emph{realms}
durchzuführen, derer da wären:

\begin{itemize}
	\item JDBC (Benutzername und Passwort sind in der Datenbank abgelegt)
	\item LDAP
	\item ActiveDirectory
	\item Textdatei
	\item applikationsspezifisch (selbst implementiert)
\end{itemize}

Falls mehrere Realms spezifiziert sind, kann über eine eigene
\lstinline~AuthenticationStrategy~ festgelegt werden, ob z. B. eine einzelne
positive Antwort ausreichend ist, oder ob sämtliche Realms die Anmeldedaten
akzeptieren müssen.

Am Ende der Authentifizierung steht ein Objekt der Klasse
\lstinline~AuthenticationInfo~, welches Zugriff auf sämtliche \emph{principals}
(ein Objekt, welches einen Benutzer repräsentiert) bietet, die von den Realms
ermittelt worden sind.

\subsubsection{Authorisierung}

Shiro ordnet jedem Benutzer eine Menge an \emph{Permissions} zu. Diese können
beliebig definiert werden; eine Möglichkeit dafür sind
\emph{WildcardPermissions}. Diese bieten eine hierarchische Form von
Berechtigungen an, z. B. \lstinline~participant:edit,view:*~ (repräsentiert die
Berechtigung, sämtliche Teilnehmer betrachten und bearbeiten zu können).
Berechtigungen können in einer Konfigurationsdatei vordefiniert , aber auch zur
Laufzeit vergeben werden; außerdem sind beliebig viele Ebenen in der Hierarchie
möglich. Die Berechtigungen werden den Nutzern über Rollen zugeordnet.

Überprüft werden können diese Berechtigungen einfach via einer der überladenen
Varianten von \lstinline~isPermitted~. Alternativ ist noch eine automatische
Überprüfung via Annotationen möglich, was aber die Einbindung eines
AOP-Frameworks nötig macht.

Intern wird die Prüfung wieder über die Realms realisiert, wobei der
standardmäßig verwendete \lstinline~ModularRealmAuthorizer~ die Berechtigung
bejaht, wenn mindestens ein Realm dies tut.

\subsubsection{Web-Unterstützung}

Per Filter lässt sich Shiro in die \texttt{web.xml} einbinden. In der
Konfiguration können dann URL-Muster und zugehörige Zugriffsrechte angegeben
werden, So kann z. B. folgendes festgelegt werden:

\begin{lstlisting}
/participant/*/view = authc, ssl, roles[dataEntry]
\end{lstlisting}

Dies legt fest, dass, um den angegebenen Pfad aufrufen zu können, der Benutzer
authorisiert (eingeloggt) sein muss, die Seite per SSL aufruft und die Rolle
"`dataEntry"' innehat. Es ist ferner möglich, eine URL zu konfigurieren, unter
der ein Login möglich ist, so dass nicht eingeloggte Benutzer weitergeleitet
werden können. Ebenso wird ein Redirect auf SSL automatisch erledigt.

\subsubsection{Einschätzung}

Shiro eignet sich aus folgenden Gründen für den Einsatz in einem
Clinica-Trial-System:

\begin{itemize}
	\item Es erlaubt sehr feingranulare Zugriffsberechtigungen, so dass es
	problemlos möglich ist, Sites und Nutzer voneinander zu unterscheiden. So
	könnte mit Berechtigungen wie
	\lstinline~clinic-a:study-a:participant:view:*~ festgelegt werden, dass ein
	Nutzer in der Studie A in der Klinik A alle Teilnehmerdaten betrachten darf.

	\item Shiro bietet viele Mechanismen standardmäßig und ohne
	Konfigurationsaufwand an, z. B. Sessionmanagement. Dadurch verringert sich
	der Implementierungsaufwand deutlich.

	\item Der Einsatz für Webanwendungen ist vorgesehen, was sich u. a. durch
	die direkte Integrierbarkeit in die \texttt{web.xm} äußert. Grobe
	Zugriffsbeschränkungen können dadurch mit wenig Aufwand direkt realisiert
	werden, was das Risiko von unberechtigten Zugriffen minimiert.

	\item Es wird eine große Zahl an \emph{authenticators} mitgeliefert. Sollten
	diese nicht ausreichend sein, ist es einfach, einen selbst zu
	implementieren.
\end{itemize}

Ebenso wie bei JAAS führt Shiro keine weitergehenden Schutzmaßnahmen gegen
übliche Sicherheitslücken durch. 

