Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Beispiel 4: Zugriffskontrolle für mehrere Mandanten mit RBAC und ABAC
Um das RBAC-Beispiel aus dem vorherigen Abschnitt zu erweitern, können Sie Benutzern Attribute hinzufügen, um einen hybriden RBAC-ABAC-Ansatz für die mehrinstanzenfähige Zugriffskontrolle zu erstellen. Dieses Beispiel enthält dieselben Rollen wie das vorherige Beispiel, fügt jedoch das Benutzerattribut und den Kontextparameter hinzu. `account_lockout_flag` `uses_mfa` Das Beispiel verfolgt auch einen anderen Ansatz zur Implementierung der mehrinstanzenfähigen Zugriffskontrolle mithilfe von RBAC und ABAC und verwendet einen gemeinsamen Richtlinienspeicher anstelle eines anderen Richtlinienspeichers für jeden Mandanten.
Dieses Beispiel stellt eine mehrinstanzenfähige SaaS-Lösung dar, bei der Sie Autorisierungsentscheidungen für Mandant A und Mandant B treffen müssen, ähnlich wie im vorherigen Beispiel.
Um die Benutzersperrfunktion zu implementieren, fügt das Beispiel das Attribut `account_lockout_flag` dem `User` Entitätsprinzipal in der Autorisierungsanfrage hinzu. Dieses Flag sperrt den Benutzerzugriff auf das System und gewährt dem gesperrten Benutzer `DENY` alle Rechte. Das `account_lockout_flag` Attribut ist der `User` Entität zugeordnet und gilt so lange, `User` bis das Kennzeichen in mehreren Sitzungen aktiv aufgehoben wird. In dem Beispiel wird die `when` Bedingung zur Auswertung `account_lockout_flag` verwendet.
Das Beispiel fügt auch Details zur Anfrage und Sitzung hinzu. Die Kontextinformationen geben an, dass die Sitzung mithilfe der Multi-Faktor-Authentifizierung authentifiziert wurde. Um diese Überprüfung zu implementieren, verwendet das Beispiel die `when` Bedingung, um das `uses_mfa` Flag als Teil des Kontextfeldes auszuwerten. Weitere Informationen zu bewährten Methoden für das Hinzufügen von Kontext finden Sie in der [Cedar-Dokumentation](https://docs.cedarpolicy.com/auth/entities-syntax.html).
```
permit (
principal in MultitenantApp::Role::"allAccessRole",
action in [
MultitenantApp::Action::"viewData",
MultitenantApp::Action::"updateData"
],
resource
)
when {
principal.account_lockout_flag == false &&
context.uses_mfa == true &&
resource in principal.Tenant
};
```
Diese Richtlinie verhindert den Zugriff auf Ressourcen, es sei denn, die Ressource befindet sich in derselben Gruppe wie das `Tenant` Attribut des anfordernden Prinzipals. Dieser Ansatz zur Aufrechterhaltung der Mandantenisolierung wird als *One Shared Multi-Tenant Policy Store-Ansatz* bezeichnet. Weitere Informationen zu Designüberlegungen für verifizierte Berechtigungen für mehrinstanzenfähige SaaS-Anwendungen finden Sie im Abschnitt [Überlegungen zum Entwurf verifizierter Berechtigungen für mehrere Mandanten](avp-design-considerations.md).
Die Richtlinie stellt außerdem sicher, dass der Principal Mitglied von `allAccessRole` und ist und seine Aktionen auf und beschränkt. `viewData` `updateData` Darüber hinaus überprüft diese Richtlinie, ob dies der Fall `account_lockout_flag` ist `false` und ob der Kontextwert für als `uses_mfa` bewertet wird. `true`
In ähnlicher Weise stellt die folgende Richtlinie sicher, dass sowohl der Prinzipal als auch die Ressource demselben Mandanten zugeordnet sind, wodurch ein mandantenübergreifender Zugriff verhindert wird. Diese Richtlinie stellt außerdem sicher, dass der Principal Mitglied von ist, `viewDataRole` und beschränkt seine Aktionen auf. `viewData` Darüber hinaus wird überprüft, ob der Wert `account_lockout_flag` ist `false` und ob der Kontextwert für als `uses_mfa` bewertet wird. `true`
```
permit (
principal in MultitenantApp::Role::"viewDataRole",
action == MultitenantApp::Action::"viewData",
resource
)
when {
principal.account_lockout_flag == false &&
context.uses_mfa == true &&
resource in principal.Tenant
};
```
Die dritte Richtlinie ähnelt der vorherigen. Die Richtlinie erfordert, dass die Ressource Mitglied der Gruppe ist, die der Entität entspricht, die vertreten wird durch`principal.Tenant`. Dadurch wird sichergestellt, dass sowohl der Prinzipal als auch die Ressource Mandant B zugeordnet sind, wodurch ein mandantenübergreifender Zugriff verhindert wird. Diese Richtlinie stellt sicher, dass der Principal Mitglied von ist, `updateDataRole` und beschränkt Aktionen auf. `updateData` Darüber hinaus überprüft diese Richtlinie, ob der Wert `account_lockout_flag` ist `false` und ob der Kontextwert für als `uses_mfa` bewertet wird. `true`
```
permit (
principal in MultitenantApp::Role::"updateDataRole",
action == MultitenantApp::Action::"updateData",
resource
)
when {
principal.account_lockout_flag == false &&
context.uses_mfa == true &&
resource in principal.Tenant
};
```
Die folgende Autorisierungsanfrage wird anhand der drei zuvor in diesem Abschnitt erörterten Richtlinien bewertet. In dieser Autorisierungsanfrage `Alice` stellt der Principal vom Typ `User` und mit dem Wert von eine `updateData` Anfrage mit der Rolle`allAccessRole`. `Alice`hat das Attribut`Tenant`, dessen Wert ist`Tenant::"TenantA"`. Die Aktion`Alice`, die ausgeführt werden soll, ist `updateData,` und die Ressource, auf die sie angewendet werden soll, ist `SampleData` vom Typ`Data`. `SampleData`hat `TenantA` als übergeordnete Entität.
`Alice`Kann gemäß der ersten Richtlinie im `` Richtlinienspeicher die `updateData` Aktion für die Ressource ausführen, vorausgesetzt, dass die Bedingungen in der `when` Klausel der Richtlinie erfüllt sind. Die erste Bedingung erfordert, dass das `principal.Tenant` Attribut ausgewertet wird`TenantA`. Die zweite Bedingung erfordert, dass das Attribut `account_lockout_flag` des Prinzipals `false` Die letzte Bedingung erfordert`uses_mfa`, dass `true` der Kontext Da alle drei Bedingungen erfüllt sind, gibt die Anfrage eine `ALLOW` Entscheidung zurück.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "updateData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"context": {
"contextMap": {
"uses_mfa": {
"boolean": true
}
}
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"attributes": {
{
"account_lockout_flag": {
"boolean": false
},
"Tenant": {
"entityIdentifier": {
"entityType":"MultitenantApp::Tenant",
"entityId":"TenantA"
}
}
}
},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "allAccessRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Tenant",
"entityId": "TenantA"
}
]
}
]
}
}
```