Steuerung des Zugriffs auf Daten

Im Hinblick auf die Anwendungssicherheit spielen die Konzepte Authentifizierung und Autorisierung eine entscheidende Rolle.

Sehen Sie sich das Video an, um einen Überblick über Authentifizierung und Autorisierung zu erhalten.

Wir haben in unserer Anwendung noch keine Berechtigungen konfiguriert. Das bedeutet, dass es derzeit keine Einschränkungen gibt und alle Requests weiterhin vollen Zugriff auf die gesamte Anwendung haben. In dieser Lektion erfahren Sie, wie Sie den Zugriff auf die Anwendung einschränken.

In einer Produktivumgebung werden standardmäßig alle Endpunkte authentifiziert, auch wenn keine Einschränkungen konfiguriert sind. Die Authentifizierungsmethode ist frei anpassbar. Der Einfachheit halber wird eine Reihe von Authentifizierungsmethoden sofort einsatzbereit unterstützt, um die häufigsten Szenarien abzudecken. Wenn es aus geschäftlichen Gründen erforderlich ist, anonymen Benutzern offene Endpunkte bereitzustellen, müssen zusätzliche Maßnahmen ergriffen werden. Das Konfigurieren der Authentifizierung für die Produktivumgebung wird in diesem Kurs nicht behandelt.

Wie wir bereits gesehen haben, ist beim Testen der Anwendung in der Entwicklungsumgebung keine Authentifizierung erforderlich. Später wird gezeigt, wie die Authentifizierung für die Testumgebung konfiguriert wird.

Im Folgenden untersuchen wir Annotationen, mit denen Sie den Zugriff auf Geschäftsdaten auf einer detaillierten Ebene steuern können. Sie können die besprochenen Annotationen direkt in die .cds -Dateien einfügen, in denen die Services definiert sind. In unserem Fall wäre dies die Datei cat-service.cds für den CatalogService und die Datei admin-service.cds für den AdminService.

Es empfiehlt sich jedoch, die Berechtigungsannotationen in verschiedenen CDS-Dateien zu speichern, um sie von der tatsächlichen Service-Definition zu trennen. Dadurch bleiben die eigentlichen Service-Definitionen übersichtlich und konzentrieren sich nur auf die Struktur. Außerdem können Sie Berechtigungsmodellen separate Verantwortlichkeiten und Lebenszyklen zuweisen.

Wir folgen dieser Best Practice und legen separate .cds -Dateien an, um die Zugriffsregeln für den CatalogService und den AdminService zu modellieren. Wir nennen diese Dateien cat-service-auth.cds bzw. admin-service-auth.cds und speichern sie im srv-Ordner unseres Projekts, genau wie die Dateien mit den Service-Definitionen.

Sehen wir uns zunächst die Datei cat-service-auth.cds an, mit der wir den Zugriff auf den CatalogService steuern (siehe folgende Abbildung).

In dieser Datei importieren wir die Definitionen der Autoren und Dokumentenmappenentitäten sowie die Definition der submitOrder-Aktion aus dem CatalogService-Modell über die Richtlinie using .

Die Autoren und die Dokumentenmappenentität werden über die annotate -Direktive mit @readonly annotiert, um den Zugriff für alle Benutzer auf den schreibgeschützten Zugriff zu beschränken.

Als Grundlage für die Zugriffskontrolle können Sie konzeptionelle Rollen entwerfen, die anwendungsspezifisch sind. Benutzer können mehrere Rollen haben, die von einem Administrationsbenutzer in der Berechtigungsverwaltungslösung der Plattform zugeordnet werden.

Neben den anwendungsspezifischen Benutzerrollen unterstützt CAP auch einige vordefinierte sogenannte Pseudorollen, wie z.B. authenticated-user. Diese Rolle bezieht sich auf Benutzer, die erfolgreich authentifiziert wurden.

Im gezeigten Beispiel wird die Annotation @requires verwendet, um zu steuern, dass nur authentifizierte Benutzer die Aktion submitOrder ausführen dürfen.

Schauen wir uns nun die Datei admin-service-auth.cds an, die die Zugriffskontrolle für den AdminService enthält (siehe folgende Abbildung).

Auch hier verwenden wir zunächst die Richtlinie using , um die zu annotierenden Definitionen (Autoren und Dokumentenmappenentität) aus dem AdminService-Modell zu importieren.

Die Entität Autoren ist mit @(requires: 'admin')annotiert. Dadurch wird festgelegt, dass nur Benutzer mit der anwendungsspezifischen Administratorrolle auf die Entität Autoren zugreifen können.

Um Berechtigungen für die Entität Bücher zu definieren, wird die Annotation @restrict verwendet. Sie legt fest, dass nur Benutzer mit der anwendungsspezifischen Administratorrolle READ-, CREATE- und UPDATE-Vorgänge für die Dokumentenmappenentität ausführen dürfen. DELETE-Operationen sind auch nur für Benutzer mit der Admin-Rolle erlaubt, mit der zusätzlichen Einschränkung, dass nur Bücher mit Bestand 0 gelöscht werden dürfen.

Die @constrait-Annotation stellt ein Array mit einer beliebigen Anzahl von Berechtigungsobjekten bereit, wobei jedes Berechtigungsobjekt die folgende Struktur hat:

1
{ grant: <events>, to: <roles>, where: <filter-condition> }

Die Eigenschaften des Privilegobjekts sind wie folgt definiert:

• grant

  ein oder mehrere Ereignisse (z.B. READ, CREATE, UPDATE und DELETE), für die das Privileg gilt

• to

  eine oder mehrere Benutzerrollen oder Pseudorollen, für die das Privileg gilt (optional)

• where

  eine Filterbedingung, die den Zugriff auf Instanzebene weiter einschränkt (optional)

Eine Anforderung besteht eine Einschränkung, die aus einem Array von Privilegien besteht, wenn mindestens eines der Privilegien erfüllt ist.

Nachdem wir nun gesehen haben, wie Berechtigungen mithilfe von Annotationen definiert werden, möchten wir als Nächstes die Authentifizierung betrachten. Die erfolgreiche Authentifizierung eines Benutzers bildet die Grundlage, um Berechtigungsprüfungen durchführen zu können.

CAP wird mit einer Reihe vorkonfigurierter Authentifizierungsstrategien ausgeliefert.

In der Produktion wird standardmäßig die Authentifizierungsstrategie jwt verwendet. Die Benutzeridentität sowie die zugeordneten Rollen und Benutzerattribute werden zur Laufzeit von einer gebundenen Instanz des Service User Account and Authentication (UAA) bereitgestellt. Dies erfolgt in Form eines JWT-Tokens im Authorization -Header eingehender HTTP-Requests.

Während der Entwicklung wird standardmäßig die Authentifizierungsstrategie mocked verwendet. Diese Authentifizierungsstrategie verwendet die Standardauthentifizierung mit vordefinierten Mock-Benutzern. Optional können Sie zusätzliche Benutzer über die Datei package.json definieren, wie in der folgenden Abbildung dargestellt:

1
cds env get requires.auth

Die simulierte Authentifizierung verwendet die Standardauthentifizierung. Sie können daher den Header Authorization mit dem Authentifizierungsschema Basic in Ihren Anforderungen zu Testzwecken verwenden. Die Anmeldeinformationen werden in der Form <user>:<password> angegeben, wie im folgenden Beispiel gezeigt:

12
GET <service_url>/Books
Authorization: Basic catuser:abcd1234

Im Video erfahren Sie, wie Sie dem CDS-Modell Einschränkungen hinzufügen.