Zugriffsschlüssel sind die Grundlage für einen alternativen Autorierungsmechanismus, der mittels einer annehmbaren Strategie das Schreiben oder Lesen von Objekten oder Derivaten ermöglicht.
Mit einer zugehörigen Strategie können Zugriffsschlüssel die Grundlage für einen unabhängigen oder nebenläufigen Autorierungsansatz schaffen.
Eine wesentliche Motivation ist die Autorisierung unabhängig vom Nutzersystem (Nutzer) für Dritte (Gäste), exemplarisch beleuchtet etwa für Peer-Reviews.
Dabei zielt der Ansatz auf das Lesen, aber auch Schreiben von Objekten oder Derivaten.
Denn fundamental wird zwischen Lese- und Schreibzugriffsschlüssel unterschieden, die persistent oder temporär aktiviert werden kann, siehe Gebrauch.
Ein Nutzer kann für ein Objekt oder Derivat genau einen Zugriffsschlüssel persistent aktivieren.
Zusätzlich können Gäste oder Nutzer gegebenenfalls Zugriffsschlüssel temporär für ein Objekt oder Derivat aktivieren.
Hierbei unterliegt der Zugriffsschlüssel der Browser-Session.
Zugriffsschlüssel können grundsätzlich deaktiviert werden.
Die Gültigkeit kann optional zeitlich über ein Ablaufdatum beschränkt werden.
Die REST-API V2 bietet eine Möglichkeit für die Verwaltung von Zugriffsschlüsseln.
Dafür die Verwaltung muss ein Nutzer oder Gast mindestens über Schreibrechte verfügen.
Gegebenenfalls muss die REST-API zusätzlich aktiviert werden, wenn beispielsweise die Verwaltung von Zugriffsschlüsseln für Gäste zugelassen werden soll.
Darüber hinaus steht ein Ansatz für eine Webapplikation zur Verwaltung von Zugriffsschlüsseln bereit.
Zusammenfassung aller Properties mit default Werten und Beispielen, die Zugriffsschlüssel betreffen:
|
|
Strukturell betrachtet setzt sich ein Zugriffsschlüssel substanziell aus einem Secret und Type zusammen. Secret definiert das Geheimnis, das ein Nutzer kennen muss, um den Zugriffsschlüssel zu aktivieren. Der Wert kann frei gewählt werden, jedoch kann der Wert nach dem Hinzufügen des Zugriffsschlüssels nicht mehr eingesehen oder geändert werden. Das Secret wird default gehasht im Backend abgelegt. Hashing kann aber mit:
MCR.ACL.AccessKey.Secret.Hashing=false
read
beschrieben, ein Schreibzugriffsschlüssel mit dem Wert writedb
.
Optional kann der Status eines Zugriffsschlüssels mit IsActive beschrieben werden.
Hiermit kann der Zugriffsschlüssel de- und aktiviert werden
IsActive wird mit true
(aktiviert) oder false
(deaktiviert) beschrieben.
Mit Expiration kann ein Ablaufdatum für den Zugriffsschlüssel gesetzt werden.
Damit lässt sich die Gültigkeit zeitlich einschränken.
Als Wert wird prinzipiell ein Unix Timestamp erwartet.
Comment dient für zusätzliche Informationen, die eventuell wichtig für die Verwaltung sind.
Die folgende Ansicht zeigt einen Zugriffsschlüssel im JSON-Format mit allen manipulierbaren Eigenschaften:
|
|
Zugriffsschlüssel können persistent oder temporär aktiviert werden. Persistent bedeutet, dass der Zugriffsschlüssel als Attribut im Nutzerdatensatz in der Datenbank abgelegt wird. Diese Funktionalität kann derzeit noch nicht über das Front-End genutzt werden. Temporär bedeutet, dass der Zugriffsschlüssel in der HTTP-Session abgelegt wird und nach Ablauf der Session erneut übermittelt werden muss.
Für die temporäre Aktivierung steht der AccessKeyFilter bereit, der default für das Object-Servlet aktiviert werden kann.
In Kombination mit der bereitgestellten Strategie kann der Filter abgeleitet aus MCR.AccessKey.Strategy.AllowedSessionPermissionTypes
eingeschaltet werden.
Sofern der Filter eingeschaltet ist, wird der Query-String auf das Secret über den Parameter accesskey
geprüft - beispielhaft: receive/<object>?accesskey=<secret>
.
Nur nur wenn der Zugriffsschlüssel zum angefragten Objekt passt, wird dieser temporär für die HTTP-Session aktiviert - ansonsten ignoriert.
Sonderzeichen (Secret) sollten im Pfad codiert werden, siehe URL-Encoding.
Über die MyCoRe Kommandozeile können auch administrative Operationen für Zugriffsschlüssel ausgeführt werden.
Für den Export von Objekten/Derivaten liegt jeweils ein Style-Sheet save-accesskey
bereit, das alle Zugriffsschlüssel in einem JSON-Array in einem ServFlag accesskeys
abelegt.
Allgemein werden Zugriffsschlüssel bei einem Update eines Objekts/Derivates nicht berücksichtigt.
Beim Löschen eines Objekts/Derivats werden alle zugehörigen Zugriffsschlüssel gelöscht.
Beim Import eines Objekts/Derivats werden die ServFlags mit dem Typ accesskeys
erwartet im JSON-Array-Format.
clear all access keys
clear all access keys for {0}
create access key for {0} from file {1}
update access key for {0} with secret {1} from file {2}
delete access key for {0} with secret {1}
import access keys for {0} from file {1}
export access keys for {0} to file {1}
clean up access key user attributes
hash access key secret {0} for {1}