\subsection{OBiBa}

Das \emph{OBiBa}-Projekt, welche für den Einsatz in Biobänken\footnote{Datenbank
von biologischem Material, z. B. DNA-oder Blutproben} gedacht ist, besteht aus
mehreren, voneinander größtenteils unabhänigen Softwarepaketen. Relevant für
diese Evaluation sind dabei \emph{Onyx} und \emph{Opal}.

\subsubsection{Onyx}

Onyx ist der Datenerfassungsteil von OBiBa. Der Hauptbestandteil ist dabei eine
Webanwendung, über welche vordefinierte \emph{Questionnaires} ausgefüllt werden
können. Diese Fragebögen müssen von der einsetzenden Institution programmiert werden

Eine vorkonfigurierte Version von Onyx existiert nicht, da, nach Angaben auf
der Webseite, man mit den Entwicklern Kontakt aufnehmen soll, um eine angepasste
Version zu erhalten. Eine selbstkompilierte Variante war jedoch nicht lauffähig,
da einige Klassen zum Ausführen fehlen, daher basiert diese Betrachtung nur auf
Dokumentation und Quelltext. (Das Beispielprojekt war ebenfalls nicht
lauffähig.)

Onyx verwendet ein Rechtesystem bestehend aus genau vier Rollen, \emph{system
administrator}, \emph{questionnaire editor}, \emph{participant manager} und
\emph{data collection operator}. Diese Rollen sind in \texttt{opal-core}
hartkodiert. Die einzelnen Rechte für diese Rollen können im
User Guide\footnote{\url{http://wiki.obiba.org/download/attachments/11599994/OnyxUserGuide_1-8.pdf?version=1&modificationDate=1293187542000}}
nachgelesen werden. Die Authentifizierung läuft manuell über die
Datenbankverbindung; hierfür wird -- im Gegensatz zu Opal -- nicht Shiro
verwendet (siehe unten). Auch sind die Rollen nicht veränderbar.

Der Login-Vorgang läuft wie folgt ab:

\begin{itemize}
	\item über das \texttt{LoginPanel} werden Benutzername und Passwort
	abgefragt und an die \texttt{authenticate}-Methode in
	\texttt{OnyxAuthenticatedSession} weitergereicht
	\item ein eigener \texttt{EntityQueryService} fragt in der Datenbank nach
	dem Benutzernamen und prüft das Passwort
	\item die zugeordneten Rollen werden automatisch von der
	Java-Persistence-API in ein Objekt abgelegt, welches in der Wicket-Session 
	gespeichert wird
\end{itemize}

Zugriffe auf die Administrationsoberfläche werden anschließend von Wicket über
Annotationen überprüft, z. B.

\begin{verbatim}
@AuthorizeAction(action = "RENDER", roles = { "SYSTEM_ADMINISTRATOR" })
\end{verbatim}

\begin{figure}[t]
	\centering

	\begin{tikzpicture}
		\node [box](browser) {Browser};
		\node [box,below=of browser] (wicket) {Wicket};
		\node [box,below left=of wicket] (signin) {LoginPanel.signIn};
		\node [box,below right=of wicket] (new-session) {OnyxApplication.newSession};
		\node [box,below=3 cm of wicket] (session) {OnyxAuthenticatedSession.authenticate};
		\node [box,below=of session] (service) {EntityQueryService.match(User)};

		\draw[link] (browser) -- node[right] {Seitenanfrage} (interceptor);
		\draw[link] (wicket) -- node[right] {} (signin);
		\draw[link] (wicket) -- node[right] {Session in Wicket ablegen} (new-session);
		\draw[link] (signin) -- node[right] {} (session);
		\draw[link] (new-session) -- node[right] {Session abrufen} (session);
		\draw[link] (session) -- node[right] {Daten prüfen} (service);
	\end{tikzpicture}
	\caption{Login-Vorgang von Onyx}
\end{figure}

Darüber hinausgehender Zugriffsschutz, z. B. auf Ebene einzelner Fragebögen, ist
nicht ersichtlich.

\subsubsection{Opal}

Opal ist der Datenbankbestandteil von OBiBa. Das Datenmodell von sieht eine
Aufteilung in mehrere Einheiten vor, wobei in Opal mehrere Datenquellen zusammen
laufen.

Opal ist eine Anwendung mit zwei Backends: Weboberfläche per Google Web Toolkit
und Jetty und Shell-Zugriff per Apache SSH-Server. Zur Authentifikation wird
Apache Shiro verwendet. Installation und Konfiguration sind recht einfach
durchzuführen; es existiert auch ein Paket für Debian-Systeme.

Wie bereits genannt, besteht das Gesamtsystem aus sogenannten \emph{Units},
wobei Opal selbst eine Unit darstellt. Innerhalb der Opal-Unit werden Personen
(\emph{participants}) durch einen \emph{private identifier} identifiziert,
welcher nicht öffentlich ist, d. h. nicht vom System aus nach außen gelangt. Um
einen Datenaustausch zu gewährleisten, wird ein \emph{shared key} sowie eine
Abbildung auf die entsprechenden privaten Schlüssel benötigt. Diese Abbildung
wird in einer separaten Datenbank (\emph{identifiers database}) abgelegt, welche
sich auch auf einem getrennten Server befinden kann (intern wird dies durch zwei
verschiedene JDBC-Datenquellen realisiert). In dieser gesonderten Datenbank
liegen außerdem persönliche Informationen des jeweiligen Teilnehmers, während in
der \emph{data database} anonyme Daten abgelegt werden. Durch diese Maßnahme
soll sichergestellt werden, dass nur tatsächlich benötigte Daten ausgetauscht
werden können, wodurch ein Angreifer Zugriff auf beide Datenbanken benötigt.

Der Datenaustausch mit einer spezifischen Unit findet in zwei Stufen statt:
Zunächst wird aus dem \emph{keystore} das Schlüsselpaar für diese Unit geladen
und die zu importierende Datei im Speicher entschlüsselt. Jeder Datensatz ist
nun mit dem gemeinsamen Schlüssel zwischen Opal und der anderen Unit
identifiziert. In der identifiers database wird dieser nun nachgeschlagen und,
falls existent, auf den private identifier abgebildet. Falls ein noch nicht
bekannter gemeinsamer Schlüssel auftritt, wird eine neuer privater Schlüssel
zufällig erzeugt. Im zu importierenden Datensatz vorliegende private Daten
werden ebenfalls in der identifiers database abgelegt, der Rest wird in der data
database gespeichert\footnote{\url{http://wiki.obiba.org/display/OPALDOC/General+Concepts\#GeneralConcepts-ParticipantIdentifierSeparation}}.

Die Daten werden innerhalb von \emph{Tabellen}, die zu \emph{Datenquellen}
zusammengefasst sind, verwaltet. Jede Tabelle definiert eine Reihe an
\emph{Variablen}, die neben einem Typ auch weitere Attribute enthalten kann (so
z. B. die entsprechende Fragestellung und Antwortmöglichkeiten in einem
Fragebogen). Jeder Datensatz in einer solchen Tabelle gehört zu einer
\emph{Entität}; üblicherweise eine Person bzw. ein Teilnehmer, der durch den
privaten Schlüssel identifiziert wird.

Opal verwendet ein rollenbasiertes Rechtesystem. Sowohl einzelnen Nutzern als
auch Gruppen können Leserechte auf gesamte Tabellen einer Datenquelle vergeben
werden, aber auch feingranular auf einzelne Variablen. Darüber hinaus werden
\emph{views} unterstützt, die ähnlich wie SQL-Views arbeiten und eine bestimmte
Sicht auf die Daten erlauben.

Umgesetzt wird die Authorisierung von Shiro, welches auch die Sessionverwaltung
umfasst. Der hierfür relevante Code befindet sich in den Teilprojekten
\texttt{opal-core} und \texttt{opal-core-ws}. Opal definiert mehrere
\emph{Realms} für die Authentifizierung per HTTP-Header oder per Cookie. Die
Benutzeraccounts selbst können per Shiro-Konfiguration einerseits statisch
definiert werden, andererseits aber auch an z. B. LDAP angebunden werden,
wodurch auch dieser Teil auf einem getrennten Server liegen kann.
