\subsection{openClinica}

\emph{openClinica} ist ein Tool, welches dazu dient, klinische Tests zu verwalten und durchzuführen. Hierbei ermöglicht das Tool, eine Studie zu definieren und im Anschluss die Messdaten der Studienteilnehmer einzutragen. Es eignet sich dabei auch für größere Studien, die über mehrere Standorte verteilt sind, was sich auch im Berechtigungsmodell widerspiegelt.

Es ist modular aufgebaut und in einen \emph{core} sowie dem \emph{web application} und \emph{web service} Modul unterteilt. Die Installation der Webapplikation ist mit dem Deployment via Tomcat und einer Anpassung der Konfiguration recht schnell erledigt.

\subsubsection{Technologien}

Um Benutzer zu authentifizieren wird das Springframework verwendet. Im Hintergrund werden die Daten entweder in einer Postgres- oder eine Oracle-Datenbank gespeichert. Die Webapplikation läuft auf der Tomcat-Plattform.

\subsubsection{Authentifizierung}

Momentan kann sich ein Benutzer nur über ein normales Passwort authentifizieren, jedoch würde Spring auch andere Methoden zulassen, was in openClinica jedoch noch nicht implementiert ist. In der Konfiguration existiert schon ein Attribut \emph{auth}, allerdings mit dem Kommentar, dass momentan außer \texttt{password} nichts unterstützt wird -- LDAP-Support ist geplant
\footnote{\url{https://wiki.openclinica.com/doku.php?id=developerwiki:security-authentication}}.

Ablauf der Authentifizierung:
\begin{enumerate}
	\item Browser greift auf beliebige Seite zu
	\item Springframework definiert in \lstinline~/classes/org/akaza/openclinica/applicationContext-security.xml~ \emph{security interceptors} für alle Seiten außer Bilder, Anmeldeseiten, Kontaktseiten etc. Zugriff auf jegliche Seiten außerhalb der definierten Ausnahmen sind nur mit der Spring-Rolle \lstinline~ROLE_USER~ möglich. Diese Rolle erhält man mit der Accounterstellung und wird in der Tabelle \texttt{authorities} gespeichert.
\begin{itemize}
\item Anmeldung erfolgt mit Benutzername und Passwort. Die Authentifizierung erfolgt u. A. in \texttt{OpenClinicaUsernamePasswordAuthenticationFilter}.
\item Ein Anmeldevorgang, egal ob positiv oder negativ, wird in \lstinline~audit_user_login~ mit Datum und Uhrzeit vermerkt.
\end{itemize}
\item Im Anschluss wird die Kontrolle an das jeweilige Servlet (definiert in \lstinline~WEB-INF/web.xml~) übergeben
\begin{itemize}
\item diese sind von \texttt{SecureController} abgeleitet welcher ein \lstinline~mayProceed()~ und ein \lstinline~processRequest()~ fordert
\item \lstinline~SecureController.processRequest()~ initialisiert die benötigten Datenstrukturen wie Benutzerdaten, aktive Studie und Rolle und ruft am Ende \lstinline~mayProceed()~ auf
\item \lstinline~mayProceed()~ muss mit einer Methode überschrieben werden, die den jeweiligen User auf entsprechende interne OpenClinica-Rollen überprüft
\item die \lstinline~processRequest()~-Methode des Servlets wird nur aufgerufen, wenn der Benutzer eine gültige Rolle besitzt, ansonsten wird eine Fehlerseite zurückgegeben
\item in den JSP-Seiten ist konditionaler Code enthalten der je nach aktiver Rolle nur die passenden Menüpunkte anzeigt
\end{itemize}
\end{enumerate}

Bei einem erneuten Aufruf einer Seite (zum Beispiel durch einen Klick auf einen Link oder ein Formular) wird die Session erneut überprüft bevor der Aufruf wieder an das zuständige Servlet durchgeleitet wird. Wie beim ersten Aufruf, wird auch bei allen folgenden Aufrufen in \lstinline~mayproceed()~ geprüft, ob die Berechtigungen für eine Aktion vorhanden sind.

\begin{figure}[t]
	\centering

\begin{tikzpicture}
  \node [box](browser) {Browser};
  \node [box,below=of browser] (interceptor) {Interceptor};
  \node [box,below right=of interceptor] (login) {Login};
  \node [box,below=of interceptor] (securecontroller) {SecureController};
  \node [box,below=of securecontroller] (mayproceed) {mayProceed()};
  \node [box,right=of mayproceed] (fail) {Fehlerseite};
  \node [box,below=of mayproceed] (processrequest) {processRequest()};
  \node [box,right=of processrequest] (forwardpage) {forwardPage()};
  \node [box,right=of forwardpage] (render) {Seite rendern};

  \draw[link] (browser) -- node[right] {Seitenanfrage} (interceptor);
  \draw[link] (interceptor) -- node[left] {ungeschützt} (securecontroller);
  \draw[link] (interceptor) -- node[right] {geschützt durch Spring} (login);
  \draw[link] (login) -- node[right] {} (securecontroller);
  \draw[link] (securecontroller) -- node[right] {} (mayproceed);
  \draw[link] (mayproceed) -- node[above=0.4cm] {ungenügende Berechtigung} (fail);
  \draw[link] (mayproceed) -- node[right] {} (processrequest);
  \draw[link] (processrequest) -- node[right] {} (forwardpage);
  \draw[link] (forwardpage) -- node[right] {} (render);
\end{tikzpicture}
	\caption{Login-Vorgang von openClinica}
\end{figure}

\subsubsection{Rechteverwaltung}

openClinica unterstützt rollenbasierte Rechte auf Basis vordefinierter und unveränderlichen Rollen welche im Quellcode verankert sind. Das System bietet die Rollen \emph{Admin, Coordinator, Studydirector, Investigator, Researchassistent, Monitor} an.

Um auf eine Studie auf verschiedene Arten zuzugreifen (submit data, extract data, manage study, monitor) werden die Rollen verwendet. Die Funktionen, welche die Berechtigungen festlegen sind hierbei fest im Quellcode verankert und nicht veränderbar.
%\footnote{org.akaza.openclinica.bean.core.Role}
%\footnote{org.akaza.openclinica.bean.login.StudyUserRoleBean}.

Die Rollen können für jeden Benutzer studienabhängig vergeben werden, allerdings kann ein Benutzer nur eine Rolle pro Studie einnehmen. Weiterhin gibt es das Konzept der Trennung von \emph{study}- und \emph{site}-Rollen. Eine site-Rolle dabei im Gegensatz zur study-Rolle nur die Rechte auf Daten für eine site wohingegen eine study-Rolle die jeweiligen Rechte auf Daten von allen zugeordneten sites ausüben kann.

Es existieren zusätzlich zu den \emph{user roles} auch \emph{user types}. Diese Benutzertypen sind orthogonal zu den Rollen und können auch unabhängig von den jeweiligen Rollen vergeben werden. Es gibt als Typen normale \emph{user, business administrator} und \emph{technical administrator}\footnote{\url{https://docs.openclinica.com/3.1/openclinica-user-guide/overview-user-types-and-roles}}.

\paragraph{Granularität}

Die Rechteverwaltung ist nicht darauf ausgelegt, die Berechtigungen auf Objektebene zu verwalten. Geprüft wird nur in der Funktion \lstinline~mayproceed()~, welche anhand der aktiven Rolle (studienbezogen) den Zugriff auf ein Servlet verwehrt oder gewährt. Wenn der Benutzer Zugriff bekommt, kann er dieses Servlet auch vollständig nutzen. Eine Einschränkung der Rechte auf individuelle Objekte im System ist dabei nicht vorgesehen. So wird beispielsweise in \lstinline~UpdateStudySubjectServlet~ nicht geprüft, ob der individuelle Benutzer trotz seiner Rolle in der Studie überhaupt die Berechtigung hat, dieses \lstinline~StudySubject~ überhaupt zu verändern.


\paragraph{Flexibilität}

Da Berechtigungen fest in \lstinline~mayproceed()~ verankert sind hat dies zur Folge, dass bei einer Änderung einer Rolle alle betroffenen Java-Klassen überprüft werden müssen und gegenenenfalls manuell korrigiert werden. Ein zentraler Ansatz, der festlegt, welche Rollen auf diverse Tätigkeiten zugreifen dürfen ist nicht vorhanden. Da die Kontrolle aller Klassen nur manuell machbar ist, existiert hier eine potentielle Fehlermöglichkeit, falls eine Klasse übersehen wird oder sich Tippfehler einschleichen.

Ein zentraler, eventuell hierarchischer Berechtigungsansatz könnte hier Fehlerpotential einsparen und gleichzeitig ein feingranulareres Berechtigungsmodell ermöglichen.

\subsubsection{weitere Eigenschaften}

Die endgültigen Seiten die an den Benutzer ausgeliefert werden sind in JSP geschrieben. Die darin angezeigten Daten stammen aus den jeweiligen Servlets die diese an die Render-Engine übergibt. In den JSP-Dateien befindet sich Code, welcher an manchen Stellen auf die hartkodierten Rechte von openClinica verweist und diese nutzt um zu entscheiden, welche Daten angezeigt werden. Dadurch ist die Darstellung relativ stark an die Logik gebunden. Bei einer Veränderung der Rechte müssen nicht nur in den jeweiligen Java-Servlets die Rollen geändert werden sondern auch in allen betroffenen JSPs. Beispielsweise befindet sich in \lstinline~menu.jsp~ folgende Abfrage:

\begin{lstlisting}
<c:if test="${userRole.investigator || userRole.researchAssistant}">
...
</c:if>
\end{lstlisting}

Durch die hartkodierten Rollen kann das Berechtigungsmodell nur sehr aufwändig verändert werden wenn man verhindern will, dass Probleme oder ungewünschte Ergebnisse auftreten.
