\subsection{openCDMS}

\emph{openCDMS} (vormals \emph{PsyGrid}) ist eine Sammlung von Tools, die es
ermöglichen klinische Studien anzulegen, zu bearbeiten und zu analysieren. Es
wird ebenfalls ein Tool mitgeliefert um neue Datensätze anzulegen und zu
bearbeiten.

Im Gegensatz zu den anderen, im folgenden betrachteten Systemen war es leider
nicht möglich, \emph{openCDMS} lokal zu installieren, da die
Installationsroutine offenbar fehlerhaft ist und ein Versuch das System manuell
zu bauen scheiterte an zahlreichen Fehlern beim Kompilationsvorgang. Daher
wurden für diese Evaluation nur der Quelltext, die Dokumentation sowie die
öffentlich verfügbare Demontrations-Applikation hergezogen.

\subsubsection{Technologien}

Die Applikation ist in einer 3-Tier Architektur aufgebaut, die Dokumentation
bezeichnet sie als Client, Logik und Daten. Dabei wird die Datenhaltung über
eine von Hibernate unterstützte Datenbank abgewickelt. Sie beinhaltet unter
anderem die Speicherung der Studien, Anonymisierung, Authorisierung. User
werden hingegen gegen einen LDAP-Server authentifiziert. Der Logik-Tier,
aufbauend auf Tomcat verarbeitet diese Daten und stellt sie dem Client-Tier
bereit. Diese Kommunikation verläuft über eine SSL-geschützte HTTP-Verbindung
mittels SOAP.

Die Clients, von denen je nach Aufgabe verschiedene benutzt werden sind
hingegen als Java-Swing-Applikationen realisiert und können via Java-Web-Start
aus dem Browser heraus gestartet werden. Dies hat zwar zur Folge, dass der
Benutzer Java installiert haben muss, aber hat bedeutende Sicherheitsvorteile
gegenüber Web-Applikationen bringt. So kann man typische Szenarien wie
XSS-Lücken sowie CSRF-Angriffe von vorhinein vermeiden.

\subsubsection{Authentifizierung}

\begin{figure}
  \includegraphics[width=.95\textwidth]{openCDMS}
  \caption{Vereinfachte Darstellung der Authentisierung und Authorisierung, Server ist oben, Client unten}
\end{figure}

Authentifizierung läuft im gesamten System über die \emph{Security Assertion
Markup Language}, einem XML-Dialekt, der auf SOAP aufbaut. Die Prüfung der
Berechtigungen (SAML Assertions) erfolgt in der Policy Authority (PA) im
Zusammenspiel mit der Attribute Authority (AA) im Logik-Tier serverseitig. Wenn
Berechtigungen fehlen wird eine entsprechende SAML-Exception weitergegeben.

Der Login in die Datensammlungs-Applikation läuft ab, indem in
\texttt{org.""psygrid.""collection.""entry.""Launcher.""launchLoginDialog} für
den Login ein \texttt{EntryLoginService} erstellt wird, der in
\texttt{authenticate()} schließlich auf den Applikations-übergreifenden
\texttt{org.""psygrid.""securitymanager.""security.""SecurityManager} zugreift
-- dieser ist die zentrale Stelle in openCDMS, in der Authentifikation
gehandhabt wird.  Im Zuge von \texttt{SecurityManager.""login()} wird das
Passwort in \texttt{refreshKey()} verwendet um dort via
\texttt{doRemoteLogin()} die entsprechenden X.509-Zertifikatsdaten
vorzubereiten und die weitere Authentifizierung an den \texttt{LoginClient}
weiterzuleiten. Dieser ruft dann auf einer SOAP-Gegenstelle namens
\texttt{LoginServicePortType} die Methode \texttt{login()} mit dem Usernamen
und Passwort auf, die den User authentifizieren soll. Bei Fehlern werden
Exceptions geworfen, so dass der Client-Part feststellen kann dass die
Authentifizierung nicht geklappt hat.

Dabei kann die Authentifizierung nicht nur an einer falschen
Benutzername/Passwort-Kombination scheitern, das System sieht ebenfalls vor,
dass Accounts gesperrt sein können. Zugriffe mit unbekanntem Usernamen werden
ebenfalls Server-seitig geloggt wie auch falsche Passwörter, dem Client wird
diese Information natürlich aus Sicherheitsgründen nicht übermittelt. Positiv
ist auch, dass im Client versucht wird, das Passwort die meiste Zeit
verschlüsselt im Speicher anzulegen, so dass man nicht das Klartext-Passwort im
Speicher stehen hat, allerdings ist die Verschlüsselung symmetrisch und kann
wieder entschlüsselt werden.

Serverseitig wird der Login dann weiter zum \texttt{AuthenticationManager}
geleitet, dieser prüft in \texttt{checkUID()} ob der User im angeschlossenen
LDAP existiert und kann in \texttt{login()} den User einloggen -- im
Erfolgsfall werden Credentials zurückgegeben, die an den Client geschickt
werden. Der Client speichert die Credentials in seinem \texttt{KeyStore}.

\subsubsection{Authorisierung}

Bei dem Anlegen neuer Datensätze wird im Collection-Tool nach der Einwilligung
des Probanden gefragt. Dabei wird die Datenbank vom Client modifiziert, daher
ist es interessant zu sehen wie ein Änderungsvorgang abläuft, um zu sehen ob
und wie der Vorgang authorisiert wird. Die Einwilligung wird in
\texttt{org.""psygrid.""collection.""entry.""ui.""EditConsentDialog.""doConsentChange()}
editiert, sowohl der lokal im Client vorgehaltene Datensatz, als auch der
Remote-Datensatz, der für die Betrachtung der Authorisierung relevant ist.
Dabei wird der eigentliche Editionsvorgang an den sogenannten
\texttt{RemoteManager} delegiert, der generell für alle Remote-Datenänderungen,
nicht nur Einwilligungen, zuständig ist. Er ist das Equivalent vom
\texttt{SecurityManager} bei der Authentitizierung.

So wird zunächst der editierte Datensatz genommen und via
\texttt{getSAMLAssertion()} eine SAML-Assertion für das spezielle Projekt
angefordert. Diese Anforderung wird an den SecurityManager weitergeleitet, der
solche Anfragen über den AttributeAuthorityQueryClient (\texttt{AAQueryClient})
beantwortet. Im \texttt{AAQueryClient} werden die Attribute des Users von der
Attribute Authority via SOAP abgefragt
(\texttt{AttributeAuthorityQueryPortType.""getAttributesForUserInProject})
welche die Anfrage mit einer passenden SAML-Assertion beantwortet.

Nachdem der Client nun seine passende SAML-Assertion bekommen hat, wird die
Daten-Änderungs-Operation zusammen mit der SAML-Assertion an den
\texttt{RepositoryClient}
(\texttt{org.""psygrid.""data.""repository.""client.""RepositoryClient})
weitergegen, der nun die Operation sowie die SAML-Assertion via SOAP an den
\texttt{RepositoryService} schickt. Serverseitig wird daraufhin in
\texttt{check""Permissions""By""Group}/\texttt{check""Permissions""By""Project}
(\texttt{org.""psygrid.""data.""utils.""service.""AbstractService}) geprüft, ob
die SAML-Assertion gültig ist und die entsprechende Aktion authorisiert, im
Beispiel \texttt{ACTION\_DR\_ADD\_CONSENT}. Dazu wird
\texttt{org.""psygrid.""security.""accesscontrol.""AccessEnforcementFunction.""authorizeUser()}
aufgerufen, welches schließlich über das SOAP-Interface
\texttt{org.""psygrid.""security.""policyauthority.""PolicyAuthorityQueryPortType.""makePolicyDecision()}
anfragt ob der User einer Rolle zugehört bei der diese Action erlaubt wird. Die
exakte Zuordnung von Rollen zu Actions geschieht in der Policy. Nachdem nun
bekannt ist, dass dem User erlaubt ist, die Änderung durchzuführen leitet der
\texttt{RepositoryService} die Operation an die Persistenzschicht weiter, die
sie in die Datenbank übernimmt.

\subsubsection{Rechteverwaltung}

Bei dem Anlegen eines Users erhält man die Möglichkeit die Rollen des neuen
Users festzulegen. Die Auswahl enthält die Rollen ChiefInvestigator,
ProjectAdministrator, ProjectManager, PrincipalInvestigator,
ClinicalResearchManager, ClinicalResearchOfficer, ScientificResearchOfficer,
TreatmentAdministrator, RecruitmentManager, DataAnalyst, NamedInvestigator.
Diese Rollen sind fest im System verankert und können nicht verändert werden.
Zusätzlich existieren die Rollen DELViewer, DELAuthor, DELCurator (zum Zugriff
auf die \emph{Data Element Library}), StudyPatcher, DataImporter, QueryData,
ViewIdentity (zum Ansehen der Identitäten der Probanden) sowie Pharmacist.
Jeder dieser Rollen (\texttt{RBACAction}) wird eine Menge von Aktionen
(\texttt{RBACAction}) zugeordnet, deren Existenz beim Ausführen von Aktionen
geprüft wird.

\subsubsection{Pseudonymisierung/Anonymisierung}

Probanden bekommen vom System eine Identifikationsnummer wie etwa
\emph{OLK/001001-217}, wobei der letzte Teil innerhalb einer Studie einfach
inkrementiert wird.
