Auth & Aut
Authentifizierung: Feststellung der Identität eines Benutzers.
Autorisierung: Feststellung ob ein Benutzer eine bestimmte Aktion durchführen darf.
Authentifizierung
Methoden
Ein Benutzer der auf eine beliebige Ressource der GBD WebSuite zuzugreifen versucht ist zunächst einmal anonym. Um sich gegenüber der Applikation zu Identifizieren unterstützt die GBD WebSuite zwei Verfahren über die der Benutzer eine nur Ihm bekannte Information mitschicken kann, durch die die GBD WebSuite ihm eine hinterlegte Identität und die damit verbundenen Berechtigungen zuweisen kann.
basic
Bei der Basic Authentifizierung wird bei jeder Anfrage Benutzername und Passwort mitgeschickt. Möchten Sie mit QGIS auf von der GBD WebSuite bereitgestellte, zugriffsgeschützte OWS Dienste zugreifen benötigen Sie diese Authentifizierungsmethode:
/data/config.cx
{
auth.methods+ {
type basic
secure false
}
}
Provider
Nachdem die GBD WebSuite die Zugangsdaten durch eine der oben beschriebenen [Methoden](TODO LINK) erhalten hat, muss sie überprüfen ob diese Zugangsdaten richtig sind, herausfinden zu welchem Benutzer diese gehören und Informationen zu diesem Benutzer herausfinden, wie z.B. der Anzeigename oder die dem Benutzer zugewiesenen Rollen.
Diese Informationen kann die GBD WebSuite von einem Authentifizierungsprovider beziehen. Es werden folgende Provider unterstützt:
file
Mit diesem Authentifizierungsprovider ist es möglich eine Liste von Benutzern in einer JSON Datei zu hinterlegen.
Ergänzen Sie die Konfiguration für den Authentifizierungsprovider wie folgt:
/data/config.cx
{
actions+ { type auth }
auth.methods+ {
type web
secure false
}
auth.providers+ {
type file
path "/data/users.json"
}
}
Und hinterlegen Sie eine Liste mit Benutzerkonten in der angegebenen Datei:
/data/users.json
[
{
"login": "user_login",
"password": "sha512_encoded_password",
"name": "display name for the user",
"roles": [ "role1", "role2", ...]
},
{
...
}
]
Um das Passwort nicht im Klartext in der Konfiguration zu hinterlegen wird ein
Hashwert
verwendet. Sie können den in der Datei zu hinterlegenden Hashwert mittels eines
Kommandozeilenbefehls von der WebSuite erhalten: [gws auth password
](TODO LINK KOMMANDOZEILENREFERENZ)
ldap
Der ldap-Provider kann Benutzer gegen ein ActiveDirectory oder einen OpenLDAP-Server authentifizieren. Sie sollten mindestens eine URL des Servers und ein Regelwerk konfigurieren, um LDAP-Filter auf GBD WebSuite Rollennamen abzubilden.
Hier ist eine Beispielkonfiguration unter Verwendung des von forumsys.com bereitgestellten LDAP-Testservers:
{
type ldap
url "ldap://ldap.forumsys.com:389/dc=example,dc=com?uid"
bindDN "cn=read-only-admin,dc=example,dc=com"
bindPassword "password"
users [
// LDAP-Benutzer "euler" hat Rollen "moderator" und "expert":
{
matches "(&(cn=euler))"
roles ["moderator" "expert"]
}
// alle Mitglieder der LDAP-Gruppe "mathematicians" haben die Rolle "member":
{
memberOf "mathematicians"
roles ["member"]
}
]
}
postgres
TODO
Autorisierung
Nach der Authentifizierung wird überprüft ob der Benutzer autorisiert ist auf die gewünschte Art mit der gewünschten Ressource zu interagieren.
Rollen
Im Rahmen der Authentifizierung hat der Benutzer eine Liste von Rollen zugewiesen bekommen. Es gibt ein paar vom System vorgegebene Rollen die ein Benutzer automatisch abhängig von seinem Authentifizierungsstatus erhält, und zusätzlich die Rollen die laut Authentifizierungsprovider dem Benutzer zugewiesen werden.
GWS Rollen sind Strings (Textfolgen) die mit einem lateinischen Buchstaben
beginnen, und nur Buchstaben, Ziffern und Unterstriche enthalten dürfen.
Ebenfalls dürfen Sie die Rollen guest
, user
und all
nicht selbst vergeben.
vordefinierte Rollen
Rolle | Bedeutung |
---|---|
guest | nicht eingeloggter Benutzer |
user | jeder eingeloggter Benutzer |
all | alle Benutzer, eingeloggt und Gäste. Objekte, auf welche die Rolle all Zugriff hat sind öffentliche ("public") Objekte |
admin | Diese Rolle kann durch den Authentifizierungsprovider zugewiesen werden, und erhält immer Zugriff auf alle Objekte. |
Zugriffsregeln
Für einige Objekte in der Konfiguration können Regeln hinterlegt werden, anhand derer entschieden wird ob und wie der Benutzer mit diesem interagieren kann.
Das Hinterlegen von diesen Regeln findet auf zwei Arten statt:
access
Die Eigenschaft access
sollte nicht mehr verwendet werden. Verwenden Sie
stattdessen permissions.read
. Sind beide Eigenschaften gesetzt wird
permissions.read
immer bevorzugt. access
wird mit einem zukünftigen
Release entfernt.
Die meisten Objekte für die eine Zugriffskontrolle möglich ist, haben eine
Eigenschaft access
:
/data/config.cx
{
access "allow all"
project+ {
access "allow myrole, deny all"
uid myproject
title "Mein Projekt"
}
}
permissions
permissions
definiert mit den Eigenschaften read
, write
, update
und
delete
die Berechtigungen von Rollen auf Objekte.
Zusätzlich gibt es permissions.edit
welches ermöglicht write
, update
und
delete
in einem Befehl auf den gleichen Wert zu setzen.
ACL
ACL Strings sind Zeichenketten die für die Eigenschaften des permissions
Blocks hinterlegbar sind.
Sie enthalten eine kommaseparierte Liste von Zugriffsdirektiven bestehend aus
allow <rolle>
oder deny <rolle>
.
Die Direktiven werden sequentiell überprüft bis eine dem zugreifenden User zugewiesene Rolle gefunden wird.
Dem Nutzer wird der Zugriff daraufhin entweder gewährt (allow
) oder
verwährt (deny
), und alle folgenden Direktiven werden ignoriert.
Ist für ein Objekt keine Zugriffsregelung hinterlegt wird das übergeordnete Objekt überprüft und die dort hinterlegten Regeln angewandt. Falls es kein übergeordnetes Objekt gibt, d.h. das Root-Objekt wird erreicht, wird der Zugriff verweigert.
In diesem Beispiel wird allen Zugreifenden Anwendern das Lesen aller
untergeordneten Objekte erlaubt, und lediglich Usern mit der Rolle schreibrolle
das editieren gestattet:
{
permissions.read "allow all"
permissions.edit "allow schreibrolle, deny all"
}
Berechtigungsstrategien
selektives deny
Wenn Ihre Projekte größtenteils öffentlich sind (oder wenn Sie überhaupt keine Berechtigung benötigen), können Sie in der App-Konfig allow
an all
vergeben:
/data/config.cx
{
permissions.read "allow all"
...
}
Wenn Sie nun den Zugriff auf ein Objekt, z. B. ein Projekt, einschränken wollen, benötigen Sie zwei Zugriffsregeln: eine, um eine bestimmte Rolle zuzulassen, und eine, um all
zu verwehren: ::
/data/config/projects/myproject.cx
{
uid myproject
title "Mein Projekt"
permissions.read "allow leserolle, deny all"
...
}
selektives allow
Auf der anderen Seite, wenn die meisten Ihrer Projekte ein Login erfordern, ist es einfacher, mit einer "deny all"-Regel zu beginnen:
/data/config.cx
{
permissions.read "deny all"
permissions.edit "deny all"
...
}
und dann explizit den Zugriff auf bestimmte Objekte zu erlauben:
/data/config/projects/myproject.cx
{
uid myproject
title "Mein Projekt"
permissions.read "allow leserolle"
permissions.edit "allow schreibrolle"
...
}
Bestimmte Aktionen müssen unter umständen für alle Anwender verfügbar sein um
sich einloggen zu können, und bei dieser Strategie explizit mit
permissions.read "allow all"
versehen werden. Für den Web-Formular basierten
Login wären dies die Aktion auth
, sowie wahrscheinlich die Aktion web
um das
Login-Formular als Webseite darstellen zu können.
Sitzungen
TODO dieser Abschnitt ist noch alt und muss überprüft werden.
Sitzungen werden in einer Sqlite Tabelle gespeichert, die sich in einem persistenten Ordner innerhalb des var
Ordners befindet. Dies bedeutet, dass die Sitzungen auch nach einem Neustart des Servers nicht unterbrochen werden.
Sie können die Lebenszeit einer Sitzung mit der Option sessionLifeTime
steuern.
TODO! ^CLIREF auth.sessions
Mit dem Kommandozeilen-Befehl gws auth sessions
können Sie die aktiven Sitzungen auflisten.