Zugriffsrechte

Zugriffsrechte werden im JSON-Format definiert und legen die Zugriffsberechtigungen für einen Dienst fest.

Eine Zugriffsrechte-Datei hat die folgende Struktur:

{
  "policies": [],         (1)
  "fallbackPolicies": [], (2)
  "restrictions": {},     (3)
  "properties": {}        (4)
}

1	Eine Liste von Zugriffsrechten für einen Dienst.
2	optional: Zugriffsrechte, welche genutzt werden, wenn kein passendes Zugriffsrecht für die Rollen einer Person gefunden wird.
3	optional: Eindeutig benannte Einschränkungen, welche in den Zugriffsrechten referenziert werden können.
4	optional: Eindeutig benannte Eigenschaften, welche in der Datei referenziert werden können.

Automatische Vervollständigung und Syntaxprüfung

Das hier beschriebene JSON-Format für Zugriffsrechte ist auch als JSON-Schema beschrieben. Mithilfe des Schemas können Sie sicherstellen, dass Ihre JSON-Datei den Vorgaben entspricht. Außerdem können Editoren wie Visual Studio Code auf Basis des Schemas Vorschläge, Beschreibungen sowie eine automatische Vervollständigung für Elemente bei der Eingabe anbieten.

Fügen Sie der JSON-Datei die folgende "$schema" Eigenschaft hinzu, um die automatische Vervollständigung zu aktivieren:

{
    "$schema": "https://raw.githubusercontent.com/conterra/secman-open-resources/1.0.0/schema/policies.schema.json",
    "policies": []
}

Eine Kopie des JSON-Schemas ist Teil der security.manager for OGC Auslieferung und verfügbar unter [SECMAN_DIST]/resources/policies.schema.json. Damit können Sie die automatische Vervollständigung auch nutzen, wenn Sie in Ihrer Umgebung keinen Zugriff auf https://raw.githubusercontent.com/conterra/secman-open-resources/… haben. Um diese Kopie zu verwenden, passen Sie die $schema Eigenschaft wie folgt an:

{
    "$schema": "[SECMAN_DIST]/resources/policies.schema.json",
    "policies": []
}

Ersetzen Sie [SECMAN_DIST] mit dem konkreten Pfad.

`policies`

Liste von Zugriffsrechten, die für den Zugriff auf einen Dienst gelten.

Ein einzelnes Zugriffsrecht ist eine Kombination aus Layern, Rollen und optionalen Einschränkungen:

"policies":[
  {
    "layers": ["layerA", "layerB"],                   (1)
    "roles": ["roleA", "roleB"],                      (2)
    "restrictions": ["restrictionA", "restrictionB"]  (3)
  }
]

1	Layer, auf die Zugriff gewährt werden soll
2	Rollen, für die das Zugriffsrecht gilt
3	optional: weitere Einschränkungen der Layer

`layers`

Liste der Layer-Namen oder Feature Types-Namen, auf die eine Rolle Zugriff haben soll.

Jeder Eintrag muss ein eindeutiger Name eines Layers oder Feature-Types sein. Der Ausdruck "layers": ["*"] umfasst alle Layer und Feature-Types eines Services.

Bei Web Feature Services (WFS) wird der Name eines Feature-Types verwendet. Dieser muss ohne Namespace-Prefix angegeben werden. Beachten Sie für WFS die Limitierungen für Feature Types.

Bei Web Map Services (WMS) wird der Name eines Layer verwendet.

`roles`

Liste der Rollen, für die das Zugriffsrecht gilt.

Neben den Rollen des Identitätsanbieters gibt es drei vordefinierte Rolle:

enhancedSecurity_any: Diese Rolle gilt für alle Personen.
enhancedSecurity_anonymous: Diese Rolle gilt für alle nicht authentifizierten Personen.
enhancedSecurity_authenticated: Diese Rolle gilt für alle authentifizierten Personen.

`restrictions`

Referenzen auf zusätzliche Einschränkungen, die beim Zugriff auf einen Layer durchgesetzt werden sollen.

Die Verwendung von restrictions ist optional. In restrictions können IDs von Einschränkung referenziert werden, die für das Zugriffsrecht gelten. Die Einschränkungen selber werden im restrictions-Objekt auf oberster Ebene der JSON-Datei definiert.

Die Einschränkungen, die in einem Zugriffsrecht referenziert werden, gelten immer für alle in diesem Zugriffsrecht angegebenen Layer. Wenn Sie für unterschiedliche Layer unterschiedliche Einschränkungen definieren möchten, müssen Sie dazu separate Zugriffsrechte angelegen.

`fallbackPolicies`

Liste von "Fallback-Zugriffsrechten", die angewendet werden, wenn für die Rollen einer Person kein anderes Zugriffsrecht gefunden werden kann.

Fallback-Zugriffsrechte sind optional. Standardmäßig erlaubt der security.manager for OGC keinen Zugriff, falls für die Rollen einer Person keine Zugriffsrechte gefunden werden können. Mit den Fallback-Zugriffsrechten ändern sie dieses Verhalten und erlauben diesem Personenkreis den Zugriff auf bestimmte Daten.

Jeder Eintrag innerhalb der fallbackPolicies definiert dabei ein Fallback-Zugriffsrecht. Innerhalb dieses Fallback-Zugriffsrechts können die aus Zugriffsrechten bekannten Eigenschaften layers und restrictions verwendet werden. Die Eigenschaft roles darf nicht benutzt werden.

"fallbackPolicies":[{
  "layers": ["layerA"],
  "restrictions": ["restrictionB"]
}]

Verwenden Sie fallbackPolicies nicht gemeinsam mit Zugriffsrechten für die enhancedSecurity_any-Rolle. Die Zugriffsrechte für enhancedSecurity_any greifen für jede:n Nutzer:in, sodass die fallbackPolicies niemals angewendet werden.

`restrictions`

Liste von eindeutig benannten Einschränkungen, die in den Zugriffsrechten und "Fallback-Zugriffsrechten" referenziert werden können.

Eine Regel kann den Zugriff auf Layer begrenzen, indem Sie ihr Einschränkungen (Restrictions) zuordnen. Sie wird als Key-Value-Paar aus dem Namen der Einschränkung (Key) und einem Objekt, welches die Einschränkung definiert (Value), definiert. Der Name einer Einschränkung darf nur aus den Zeichen a-z, A-Z, 0-9 sowie '_' (Unterstrich) und '-' (Minus) bestehen. Er muss mit einem Buchstaben beginnen.

{
  "policies": [
    {
      "layers": ["layerA", "layerB"],
      "roles": ["roleA"],
      "restrictions": ["restrictionA"] (1)
    }
  ],
  "restrictions": { (2)
    "restrictionA": (3)
    {
      "type": "spatial", (4)
      // ...
    }
  }
}

1	Referenz auf eine Einschränkung innerhalb eines Zugriffsrechts
2	Objekt in dem alle Einschränkungen definiert werden
3	Key einer Einschränkung
4	Art der Einschränkung. Akzeptierte Werte sind `"spatial"` und `"readonly"`.

Sie können folgende Arten von Einschränkungen definieren:

Räumlich: Zugriff auf ein räumliches Gebiet einschränken
Editierung: Editieren von Geometrien und Attributen verbieten

Räumliche Einschränkung

Räumlichen Einschränkungen beschränken den Zugriff auf ein räumliches Gebiet. Dieses Gebiet wird in einer GeoJSON-Datei definiert.

Eine räumliche Einschränkung enthält die folgenden Eigenschaften:

"restrictions": {
  "europe-only": {               (1)
    "type": "spatial",           (2)
    "source": "europe.geojson",  (3)
    "spatialOperation": "within" (4)
  }
}

1	ID der Einschränkung.
2	Typ der Einschränkung.
3	Name der GeoJSON-Datei, die die Geometrien für die räumliche Einschränkung enthält
4	Nur WFS, optional: Räumliche Operation für den Vergleich der Geometrien mit den Features eines Feature Types.

type

Typ der Einschränkung.

Für räumliche Einschränkungen muss der Wert "spatial" sein.

source

Name der GeoJSON-Datei.

Die Geometrien der GeoJSON-Dateien definieren den erlaubten Bereich der räumlichen Einschränkung.
Die Datei muss im gleichen Verzeichnis wie die Zugriffsrechte-Datei liegen und diese Anforderungen für Geometrien erfüllen.

spatialOperation

Räumliche Operation, die festlegt, wie die räumliche Einschränkung auf die Features eines Feature Type angewendet wird.

Folgende räumliche Operationen werden unterstützt:

intersect: Alle Features, die die Geometrie schneiden, werden zurückgegeben. Dies ist der Standardwert.
within: Alle Features, die komplett innerhalb der Geometrie liegen, werden zurückgegeben.

Editier-Einschränkungen

Das Editieren von Transactional Web Feature Services (WFS-T) kann durch einen Vollzugriff für eine Rolle erlaubt werden. Das bedeutet, dass für diese Rolle der Zugriff auf alle Layer ohne Einschränkungen erlaubt sein muss.

Falls das Editieren für diese Rollen verboten werden soll, so kann eine Editier-Einschränkung ergänzt werden:

{
  "policies": [
    {
      "layers": ["*"],
      "roles": ["roleA"],
      "restrictions": ["no-edit"] (1)
    }
  ],
  "restrictions": {
    "no-edit": { (2)
      "type": "readonly" (3)
    }
  }
}

1	Der Vollzugriff für `roleA` wird durch die Editier-Einschränkung eingeschränkt
2	ID der Einschränkung
3	Editier-Einschränkungen sind von Typ `readonly`

Diese Eigenschaft hat lediglich einen Effekt auf WFS-T mit einem Vollzugriffsrecht.

`properties`

{
    "policies": [
        {
            "layers": ["0"],
            "roles": ["${propertyA}"] (1)
        }
    ],
    "properties": { (2)
        "propertyA": "41477fa98f444444855e1e0b7b132b45" (3)
    }
}

1	Referenz auf eine Property innerhalb eines Zugriffsrechts
2	Objekt in dem alle Properties definiert werden
3	Eine Property bestehend aus einem Schlüssel-Wert-Paar

Das properties-Element besteht aus Schlüssel-Wert-Paaren, mit denen Sie Werte definieren können, die Sie an anderer Stelle in dieser Datei über ihren Schlüssel referenzieren können. Die Werte müssen Strings sein. Die Schlüssel müssen mit einem Buchstaben beginnen und dürfen nur aus den Zeichen a-z, A-Z, 0-9 sowie '_' (Unterstrich) und '-' (Minus) bestehen. Sie können die Werte in anderen Elementen verwenden, indem Sie diese mit ${schluessel_name} referenzieren. Auf diese Weise können Sie Werten beschreibende Namen geben.