Auth & Aut

Cookies / web

Der Benutzer gibt auf einer Login Seite seinen Benutzernamen und sein Passwort ein. Die WebSuite überprüft diese und legt für den Benutzer in einer internen Datenbank eine Session an. Die Session hat einen langen, nicht erratbaren Namen welcher in einem Cookie hinterlegt wird. Der Browser des Benutzers schickt diesen Cookie bei jeder Anfrage an die GBD WebSuite automatisch mit, wodurch der Benutzer identifiziert werden kann.

Solange Benutzer nur über einen Webbrowser mit der GBD WebSuite interagiert, ist dies die beste und einzig nötige Authentifizierungsmethode.

Um diese Methode zu verwenden sind folgende Einträge in der Konfiguration vorzunehmen:

/data/config.cx

{
    actions+ { type auth }

    auth.methods+ {
        type web
        secure false
    }
}

Wenn nicht secure false gesetzt wird, verweigert die GBD WebSuite die Authentifizierung über unverschlüsselte Verbindungen.

Die [Auth Action](TODO LINK) aktiviert die Login und Logout Endpunkt die vom dem Formular angesprochen werden.

Sie können das Login Formular auf einer durch die GBD WebSuite bereitgestellten Web Seite einbinden:

/data/assets/index.cx.html

...
<script src="/_/webSystemAsset/path/util.js"></script>
@if user.isGuest
    <form onsubmit="gwsLogin(); return false" class="row">
        <input id="gwsUsername" name="username" placeholder="Benutzername">
        <input id="gwsPassword" name="password" type="password" placeholder="Passwort">
        <button id="loginButton">Einloggen</button>
    </form>

    <div id="loginWait"></div>

    <div id="loginErrorMessage">
        Anmeldung fehlgeschlagen!
    </div>
@else
    <button onclick="gwsLogout()">Ausloggen</button>
@end
...

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
    }
}

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

vordefinierte Rollen

access

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"
}

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"
    ...
}