Datenpfade & -embargos

X509 Zertifikate stellen im Moment (Nov. 21) gängigste Methode dar eine Authentifizierung gegenüber Rucio durchzuführen. Zertifikate dienen jedoch lediglich der Authentifizierung nicht aber der Autorisierung. Sie lassen sich auch nicht zu Gruppen zusammenfassen, wie sie zur Autorisierung des Dateizugriffs (und damit der Einhaltung eines Datenembargoes) benötigt werden. Darüber hinaus muss sicher gestellt werden, dass die Zugriffsberechtigungen auf eine Datei unabhängig von der Zugriffsmethode (via Rucio, native Methgoden, NFS, etc.) berücksichtigt werden. 

Auf unterster Ebene greift Rucio auf eine Datei über dCache zu. Um die Protokollunabhängigkeit zu gewährleisten, ist es daher am einfachsten Zugriffsbeschränkungen auf dieser Ebene zu integrieren, da alle höheren Protokolle (einschließlich Rucio) diesen dann ebenfalls unterliegen. 

Jeder dCache Knoten mappt hierzu jedes Zertifikate zu genau einer Posix UID. Letztere lassen sich wiederum zu Gruppen zusammengefassen. Zugriffsrechte auf eine Datei können somit letztenendes auf gewöhnliche Posix Dateizugriffsrechte zurückgeführt werden. Offene, frei zugängliche Dateien besitzen ein Leserecht für Jedermann, während z.B. Dateien, die noch einem Embargo unterliegen, nur für eine bestimmte Gruppe lesbar sind. 

Das Bild oben zeigt den gesammten Prozess schematisch. Nutzer regestrieren sich über eine Webseite nach Vorlage ihres Zertifikates. Die UID, und das Zertifikat werden daraufhin in einem LDAP-Verzeichnis abgelegt. Nutzer des KIS und reguläre Benutzer am OT erhalten standardmäßig einen Account im SDC, dennoch müssen auch diese ein Zertifikat erwerben (LINK) und über die Webseite ihrem Account zuordnen. 

Auf einer weiteren Webseite ordnet man diese Accounts Beobachtungskampagnen zu. Jede Kampagne entspricht einer dedizierten Posixgruppe, der sämtliche Kampagnenmitglieder angehören. Dateien unter Embargo gehören dem PI der Kampagne und Mitglieder der zugehörigen Posix-Gruppe haben Leserechte. 

Jeder dCache Knoten hat eine lokale Datei, die eine Zuordnung zwischen der UID eines Nutzers und dessen Zertifikat enhält (multimap). Ein Cronjob updated diese Datei regelmäßig auf jedem Knoten. Das ist keine wirklich elegante, aber einfache und robuste Methode das Mapping über alle Knoten zu gewährleisten. Dennoch, sollte auch in Zukunft keine zentrale Autorisierung über Rucio möglich sein, so wird man langfristig entweder ein bestehendes dCache-Pluging abändern, oder ein eigenes Plugin schreiben wollen.

Das Einstellen der Daten durch ein Instrument ist ein zweistufiger Prozess (siehe blaue Pfeile in der Grafik oben). Das Instrument stellt die Daten per NFS an der von Rucio erwarteten Stelle ein, setzt den POI als Eigentümer und die Gruppe gemäß der Kampagne, in der die Daten gewonnen wurden, und entfern globale Leserechte ausserhalb dieser Gruppe. Erst danach wird das File in Rucio registriert. Damit werden die Metadaten zugänglich und die Datei wird suchbar. 

Die Dateien enthalten im Metadaten-Header die Kampagnenzugehörigkeit. Bei der Replikation jedweder Daten auf andere Knoten, setzt ein spezieller Prozess die Leserechte gemäß dem skizzierten Schema. Dies gilt nicht nur für Rohdaten, sondern auch für von diesen abgeleitete Datenprodukte. 

Hiervon ausgenommen sind Quicklooks und andere, nicht wissenschaftlich verwertbare, Produkte, sowie Metadaten. Letztere ermöglichen, dass Dateien (auch während des Embargoes) suchbar und Quicklooks einsehbar sind.

Zum Herunterladen nicht-freier Daten (rote und lila Pfade im Bild oben) benötigt man ein Zertifikat. Dieses wird von den unterschiedlichen Klienten an dCache durchgereicht und dort auf eine User-ID gemappt. Diese muss berechtigt sein, um die Datei herunterladen zu können. Ist dies nicht der Fall, bekommt der Benutzer eine Fehlermeldung. 

Der Download über die Webseite erfolgt mit einem Standardzertifikat, das auf einen generischen Nutzer gemappt ist, und zum Herunterladen Leserechte für Jedermann erfordert.