Autorisierung¶
Die GBD WebSuite Autorisierung ist rollenbasiert, mit steckbaren Berechtigungsanbietern. Wenn sich der Benutzer anmeldet, werden seine Credentials nacheinander an alle konfigurierten Provider weitergegeben, wenn ein Provider die Credentials akzeptiert, gibt er eine Liste der Rollen für diesen Benutzer zurück.
Wenn der Benutzer ein Objekt anfordert, prüft der Server, ob eine der Rollen des Benutzers über ausreichende Berechtigungen verfügt, um das Objekt zu lesen, zu schreiben (z. B. beim Bearbeiten) oder auszuführen (z. B. eine Serveraktion). Wenn es keine expliziten Berechtigungen auf Objektebene gibt, wird das übergeordnete Objekt geprüft und so weiter. Um diese Prüfungen durchzuführen, liest der Server die access
jedes angeforderten Objekts.
Zugangsreglungen¶
In der Konfiguration können einige Typen von Objekten verknüpft sein mit``access`` Konfigurationen:
- main application
- server action
- project
- map
- layer
Zusätzlich definieren einige Aktionen interne access
Blöcke für bestimmte Befehle.
access
ist eine Liste von AccessRule
Objekten. Jede AccessRule
enthält
- der
type
der Regel - “erlauben” oder “verweigern”, - der
mode
- “lesen”, “schreiben”, “ausführen” oder eine Kombination davon, - die Liste der
role
Namen, auf die sich die Regel bezieht
Mit Hilfe der access
-Regeln kann der Berechtigungsprüfungsalgorithmus formal wie folgt beschrieben werden:
## Der Benutzer U fordert einen Berechtigungsmodus P (z. B. "lesen") für ein Objekt O
let currentObject = O
let userRoles = "roles" of the user U
loop
if currentObject has property "access"
## Überprüfen Sie die expliziten Zugriffsregeln:
for each Rule in currentObject.access
if (Rule.roles contains any of userRoles) and (Rule.mode contains P)
if Rule.type is "allow", return Access Granted
if Rule.type is "deny", return Access Denied
end if
end for
end if
## An dieser Stelle hat das aktuelle Objekt entweder keine "Zugriffsregeln",
## oder keine dieser Regeln passt zu den Rollen des Benutzers.
## Überprüfen Sie das übergeordnete Objekt, wenn es existiert.
if currentObject has a "parent"
let currentObject = currentObject.parent
continue loop
end if
## An diesem Punkt haben wir das Wurzelobjekt erreicht.
## und haben immer noch keine passende Regel gefunden.
## Verwenden Sie die Standardregel "Alle Anfragen ablehnen".
return Access Denied
end loop
Rollen¶
Es gibt einige vordefinierte Rollen, die in GWS eine besondere Bedeutung haben:
guest | Nicht eingeloggter Benutzer |
user | Jeder eingeloggter Benutzer |
everyone | Alle Benutzer, eingeloggt und Gäste |
admin | Administrator. Benutzer die diese Rolle haben, erhalten automatisch Zugriff auf alle Ressourcen |
Andernfalls können Sie beliebige Rollennamen verwenden, aber sie müssen gültige Bezeichnungen sein (d. h. mit einem lateinischen Buchstaben beginnen und nur Buchstaben, Ziffern und Unterstriche enthalten).
Berechtigungsstrategien¶
Da die Zugriffsregeln vererbt werden, müssen Sie als erstes die Root-Liste access
konfigurieren. Wenn Ihre Projekte größtenteils öffentlich sind (oder wenn Sie überhaupt keine Berechtigung benötigen), können Sie read
und write
an “everyone” vergeben:
## in der Hauptkonfiguration:
"access": [
{
"type": "allow",
"mode": ["read", "write"],
"role": ["everyone"]
}
]
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 “alle” zu verwehren:
## in the project config:
"access": [
{
"type": "allow",
"mode": ["read", "write"],
"role": ["members"]
},
{
"type": "deny",
"mode": ["read", "write"],
"role": ["everyone"]
}
]
Auf der anderen Seite, wenn die meisten Ihrer Projekte ein Login erfordern, ist es einfacher, mit einer “deny all”-Regel zu beginnen:
## in der Hauptkonfiguration:
"access": [
{
"type": "deny",
"mode": ["read", "write"],
"role": ["everyone"]
}
]
und erlauben dann explizit den Zugriff auf bestimmte Objekte
# in der Projektkonfigurationsdatei:
"access": [
{
"type": "allow",
"mode": ["read", "write"],
"role": ["members"]
}
]
Normalerweise ist es nicht notwendig, execute
Rechte speziell zu konfigurieren, aber wenn Sie sich dazu entschließen, sollten Sie darauf achten, dass zumindest asset
und auth
Aktionen von jedem ausführbar sind, andernfalls könnten sich Ihre Benutzer nicht einmal anmelden!
Berechtigungsanbieter¶
Datei¶
Der Dateianbieter verwendet eine einfache Json-Datei, um Autorisierungsdaten zu speichern. Der json ist nur ein Array von “user”-Objekten
[
{
"login": "user login",
"password": "sha512 encoded password",
"name": "display name for the user",
"roles": [ "role1", "role2", ...]
},
{
...
}
}
Der Name und der Speicherort der Datei ist Ihnen überlassen, geben Sie einfach ihren absoluten Pfad in der Konfiguration an. Um das verschlüsselte Passwort zu generieren, verwenden Sie den Befehl auth passwd
.
Ldap¶
Der ldap-Provider kann Benutzer gegen ein ActiveDirectory oder einen OpenLDAP-Server autorisieren. Sie sollten mindestens eine URL des Servers und ein Regelwerk konfigurieren, um LDAP-Filter auf GBD WebSuit Rollennamen abzubilden. Hier ist eine Beispielkonfiguration unter Verwendung des von forumsys. com bereitgestellten LDAP-Testservers.
{
"type": "ldap",
## the URL format is "ldap://host:port/baseDN?searchAttribute":
"url": "ldap://ldap.forumsys.com:389/dc=example,dc=com?uid",
## Anmeldeinformationen, um sich an den Server zu binden:
"bindDN": "cn=read-only-admin,dc=example,dc=com",
"bindPassword": "password",
## Filter auf Rollen abbilden:
"roles": [
## LDAP-Benutzer "euler" hat die GBD WebSuite Rolle "Moderatoren":
{
"matches": "(&(cn=euler))",
"role": "moderators"
},
## alle Mitglieder der LDAP-Gruppe "Mathematiker" haben die GBD WebSuite Rolle "Mitglieder":
{
"memberOf": "(&(ou=mathematicians))",
"role": "members"
}
]
}