Gewährung bedingter Rechte

• Nicht definierter Typ

Dieses Dokument richtet sich an Sicherheitsadministratoren, funktionale Manager und Integratoren. Es stellt das Prinzip der bedingten Rechte, deren Bewertung, die Verwaltungsschnittstelle und die zugehörige Verwaltungsfassade dar.

1. Was ist der Zweck eines bedingten Rechts?

Ein bedingtes Recht gewährt einer Gruppe nur Berechtigung, wenn der Benutzer bereits eine weitere Berechtigung für dasselbe sichere Objekt hat.

In der Sicherheitskonfiguration wird dieses Verhalten durch eine ConditionalPermissionGrant, rief Bedingte Abgabe in der Schnittstelle. Dieses Objekt enthält keine Liste von Geräten: Es beschreibt eine wiederverwendbare Regel durch Verknüpfung:

• Ein Titel und eine Beschreibung, die den Geschäftszweck erklären.
• eine Begünstigtengruppe;
• Ein sicherer Objekttyp.
• Erlaubnis erteilt;
• eine erforderliche Genehmigung, die bereits auf dasselbe Objekt wirksam sein muss.

Die von diesem Objekt übertragene Regel lautet wie folgt:

SI l’utilisateur appartient au groupe bénéficiaire
ET s’il possède la permission requise sur l’objet X
ALORS il reçoit la permission accordée sur ce même objet X

Stellen wir uns folgenden Fall in Immersive vor: Ein Nutzer muss die Karten seines Perimeters konsultieren und nur die Dateien der Geräte verwalten, die er bereits sehen darf.

Ihre Rechte basieren auf drei Familien unabhängiger Gruppen:

• Das Sicherheitsprofil Listing-Management stellt die funktionale Fähigkeit zur Verwaltung von Geräteaufzeichnungen dar;
• Die Geografische Gruppen, organisiert von nationaler Ebene bis zu den Regionen, Departements und Stationen, bestimmen die Karten und Orte, auf die sie zugreifen kann;
• Die Ausrüstungsgruppen, als Beleuchtung, CMV oder Aufzug, bestimmen die Familien der Geräte, für die die Genehmigung erteilt wird See ist effektiv.

Zwei Mitglieder der Listing-Management daher können verschiedene Umfangsbereiche haben: Man kann die Beleuchtungsanlagen einer Region sehen, während eine andere die Aufzüge einer einzelnen Abteilung sehen kann.

Die geschäftliche Frage lautet dann: Wie man den Mitgliedern des Kartenmanagements die Erlaubnis erteilt Modify ohne ihren Wirkungsbereich zu erweitern See ?

Ein erster Ansatz wäre, direkt zu gewähren Modify Zur Gruppe Listing-Management auf alle Gerätefamilien. Dieses Recht wäre jedoch viel zu weitgefasst: Alle Aktenmanager könnten alle betroffenen Familien verändern, unabhängig von ihrem eigenen Sichtbereich.

Siehe das Dokument Berechtigungen und Rechte sicherer Objekte

Es wäre möglich, die Modify für jeden Benutzer an jedem Gerät, das er sieht. Diese Lösung würde jedoch erhebliche Wartung erfordern, und jede Änderung der Rechte würde zu einer potenziellen Fehlerquelle werden.

Hier ist der Punkt, an dem die Bedingte Abgabe. Für die Gruppe Listing-Managementlautet die Regel wie folgt:

• wenn der Benutzer zur Gruppe gehört Listing-Management ;
• Und falls er es schon getan hat See auf einem Gerät;
• Also gewähre ihm Modify auf derselben Ausstattung.

Listing-Management kann somit eine rein funktionale Gruppe bleiben. Die Zugehörigkeit zu dieser Gruppe erweitert an sich nicht die sichtbare Ausrüstung. Sie wird zu einem Autorisierungspfad hin Modify nur dann, wenn bereits ein anwendbares Bedingungsrecht existiert See auf die getestete Ausrüstung.

Wir können dann das folgende bedingte Recht schaffen:

Element	Wert
Titel	Anpassung der für die Listing-Manager sichtbaren Ausrüstung
Beschreibung	Erlaubt es Mitgliedern der Listing Management, nur die Geräte zu bearbeiten, auf denen See ist bereits wirksam.
Begünstigte Gruppe	Gestion Fiches
Sicherer Objekttyp	Equipment
Erteilte Erlaubnis	Modify
Erlaubnis erforderlich	See
Umfang	Die gleiche Ausrüstung

Wenn See gilt für ein Gerät – durch direkte oder indirekte Mitgliedschaft in einer Gruppe oder durch direkte Erlaubnis – Mitgliedschaft in Listing-Management dann macht es möglich, zu erhalten Modify auf derselben Ausstattung. Wenn See nicht wirksam ist, Modify bleibt abgelehnt.

2. Wie wird der Sichtbarkeitsperimeter aufrechterhalten?

Das bedingte Recht bezieht sich nicht direkt auf eine Region, eine Abteilung, eine Station oder eine bestimmte Gerätefamilie. Für jedes getestete Gerät entscheidet die Sicherheit zuerst, ob die Genehmigung vorliegt. See ist für den Nutzer wirksam. In diesem Beispiel gilt dies See Dies resultiert aus der Kreuzung zweier Dimensionen:

• Die Geografische Gruppen Bestimmen wobei Der Benutzer kann auf die Ausrüstung zugreifen;
• Die Ausrüstungsgruppen Bestimmen Welche Familien Ausrüstung ist für ihn sichtbar.

Diese Gruppen sind nicht in der Erfolgssteuer registriert. Sie tragen stromaufwärts zur Berechnung von bei See. Die bedingte Regel prüft dann nur zwei Dinge auf dem betroffenen Gerät:

• Ist der Benutzer in der funktionalen Gruppe Listing-Management ?
• Hat es bereits See Auf demselben Gerät?

Nehmen wir Alices Beispiel:

• Alice ist Mitglied der Gruppe Listing-Management ;
• seine geografische Hierarchie verschafft ihm Zugang zu einer Region;
• Seine Gerätegruppen ermöglichen es, die Beleuchtungsausrüstung in dieser Region zu sehen.

Mit dem Herrscher Gestion Fiches : Modify si See, das Ergebnis variiert für jedes Gerät:

Getestete Ausrüstung	Geographischer Umfang	Sichtbare Familie	See	Modify
Blitz in seiner Region	Erlaubt	Ja	Belegschaft	Gewährt
Aufzug in seiner Region	Erlaubt	Nein	Abwesend	Abgelehnt
Beleuchtung außerhalb deiner Region	Außerhalb des Geltungsbereichs	Ja	Abwesend	Abgelehnt

In allen drei Fällen gehört Alice weiterhin zu Listing-Management. Es ist das Vorhandensein oder Fehlen von See auf der zu testenden Ausrüstung, die bestimmt, ob Modify wird gewährt. Ein weiteres Mitglied der Listing-Management kann daher ein anderes Ergebnis erzielen, abhängig von den jeweiligen geografischen Gruppen und den eigenen Familien sichtbarer Geräte.

3. Wie wird eine Genehmigung bewertet?

Für einen regulären Nutzer folgt die Bewertung folgendermaßen:

1. eine ausdrückliche Ablehnung der angeforderten Erlaubnis zu beantragen;
2. wenn eine Ablehnung gilt, verweigern Sie den Zugang;
3. ansonsten eine direkte Genehmigung einholen;
4. falls keine direkte Autorisierung gilt, überprüfen Sie die aktiven bedingten Rechte;
5. zulassen, wenn mindestens eine anwendbare Regel ihre Bedingung erfüllt;
6. Ansonsten verweigern Sie den Zugang.

Damit eine bedingte Regel angewendet wird, müssen alle folgenden Bedingungen erfüllt sein:

• die Regel ist aktiv;
• Der Typ des Objekts entspricht dem in der Regel konfigurierten Typ.
• Die angeforderte Genehmigung entspricht der erteilten Erlaubnis;
• Der Nutzer gehört zur Begünstigtengruppe, entweder direkt oder über verschachtelte Gruppen.
• Die erforderliche Genehmigung gilt für dasselbe Objekt.

Mehrere Regeln können dieselbe Berechtigung gewähren. Sie funktionieren als Alternativen: Alles, was benötigt wird, ist, dass eine durchsetzbare Regel erfolgreich ist. Eine Regel kann nur eine erforderliche Erlaubnis ausdrücken. Abhängigkeiten können verkettet werden. Zum Beispiel kann eine Berechtigung von Modify, was wiederum von See. Zyklen wie Modify si See und See si Modify sind verboten.

4. Umfang der Regeln

Eine Regel ist für eine definiert Sicherer Objekttyp, aber sein Zustand wird auf einer Präziser Zweck von dieser Art.

Wenn der Nutzer hat See Bei Ausrüstung 125 kann die Regel dies gewähren Modify auf der Ausrüstung 125. Die Tatsache des Besitzes See Auf Ausrüstung 126 gewährt auf Ausrüstung 125 nichts.

Die aktuelle Version unterstützt nur den Scope Gleicher Zweck :

• Die erteilte Erlaubnis und die erforderliche Erlaubnis gehören zum gleichen sicheren Typ.
• sie werden mit derselben Objektkennung ausgewertet;
• Eine Genehmigung, die sich auf einer Station, einer Abteilung oder einer anderen Ausrüstung befindet, erfüllt nicht die Bedingung anstelle des zu prüfenden Objekts.

5. Konzeptionelles Datenmodell

ConditionalPermissionGrant ist das Objekt, das ein bedingtes Gesetz darstellt. Jedes Vorkommen beantwortet folgende Frage:

Für die Mitglieder dieser Gruppe, für welche Art von Objekt, welche Erlaubnis sollte erteilt werden, wenn welche andere Erlaubnis bereits für dasselbe Objekt gilt?

Die Regel enthält keine Benutzer- oder Geräte-ID. Sie beschreibt eine wiederverwendbare Beziehung zwischen Sicherheitsobjekten; das Ergebnis wird dann für Benutzer und Objekt zum Zeitpunkt der Zugriffskontrolle berechnet.

5.1 Verwandte Objekte und Kardinalitäten

Jedes bedingte Recht steht genau im Zusammenhang mit:

• a Group, die die Begünstigtengruppe bestimmt;
• a SecurizedObjectTypeDefinition, was die Art des betreffenden Objekts bezeichnet;
• a Permission In der Rolle verliehen ;
• a Permission In der Rolle Erforderlich.

Umgekehrt kann jedes dieser Objekte mit Null, eins oder mehreren bedingten Rechten verwendet werden.

Sicherheitsobjekt	Rolle im bedingten Recht	Kardinalität für eine Regel
Group	Gruppe, deren Mitglieder von der Regel profitieren können.	Genau eine
SecurizedObjectTypeDefinition	Die Art der Objekte, auf denen die Regel ausgewertet wird.	Genau eine
Permission — Gewährte Rolle	Erlaubnis erhalten, wenn die Bedingung erfüllt ist.	Genau eine
Permission — Erforderliche Rolle	Erlaubnis, die bereits für dasselbe Objekt gelten muss.	Genau eine

5.2 Daten, die von der Regel übertragen werden

Daten	Bedeutung
Identifier	Eindeutige technische Identifikatorin des bedingten Rechts.
Title	Ein verpflichtender Titel, begrenzt auf 255 Zeichen, der die geschäftliche Absicht zusammenfasst.
Description	Eine optionale Erklärung, begrenzt auf 2.048 Zeichen, die Administratoren nützlichen Kontext bietet.
BeneficiaryGroupIdentifier	Referenz der Begünstigtengruppe. Die direkte oder indirekte Zugehörigkeit des Nutzers zu dieser Gruppe wird während der Bewertung überprüft.
SecuredObjectTypeIdentifier	Referenz auf den Typ des sicheren Objekts, zum Beispiel Equipment.
GrantedPermissionIdentifier	Verweis auf die Berechtigung, die die Regel erzeugen kann, zum Beispiel Modify.
RequiredPermissionIdentifier	Verweise zum Beispiel auf die Berechtigung, die bereits für dasselbe Objekt gelten muss See.
IsEnabled	Aktiver oder inaktiver Zustand. Nur aktive Regeln nehmen an der Bewertung teil.
RowVersion	Die Version, die verwendet wird, um eine gleichzeitige Änderung zu erkennen und zu verhindern, dass ein Administrator eine neuere Aktion stillschweigend überschreibt.

Titel und Beschreibung werden nur verwendet, um die Regel in der Verwaltungsoberfläche zu identifizieren und zu erklären. Sie nehmen nicht an der Berechnung des Anspruchs teil. IsEnabled, entscheidet jedoch, ob die Regel angewendet werden kann.

5.3 Integritätsregeln

Die Konfiguration schützt die folgenden Regeln:

• Die Gruppe, der sichere Typ und beide Berechtigungen sind erforderlich und müssen existieren.
• Der sichere Typ muss beim Erstellen einer Regel aktiv sein.
• Die gewährten und erforderlichen Berechtigungen müssen unterschiedlich sein und beide zum ausgewählten Typ gehören.
• Die gleiche Kombination Gruppe + Typ + Erteilte Erlaubnis + Erforderliche Erlaubnis Kann nur einmal gespeichert werden, selbst wenn die bestehende Regel inaktiv ist.
• Die Erstellung oder Reaktivierung einer Regel wird verweigert, wenn sie einen Zyklus von Abhängigkeiten zwischen Berechtigungen einführt.
• Das Löschen einer Gruppe, eines Typs oder einer Berechtigung, die noch von einer Regel referenziert wird, wird blockiert.
• Wenn eine Zustandsänderung oder -löschung auftritt, kann die bekannte Version der Regel eine gleichzeitige Änderung erkennen.

Daher eine einzige Regel Gestion Fiches : Modify si See kann auf alle aktuellen und zukünftigen Geräte angewendet werden. Allerdings produziert sie keine Produktion Modify als für Geräte, auf denen See tatsächlich vom Nutzer erhalten wird.

6. Verwaltungsoberfläche

Die Seite ist zugänglich von Sicherheit, dann Bedingte Rechte. Seitdem gibt es auch Zugang Konfigurationsrechte mit der Aktion Verwaltung von bedingten Rechten.

In der aktuellen Benutzeroberfläche ist diese Seite nur für das Konto gedacht Cerebrate.

6.1 Auswahl des Objekttyps

Der Typ Secure Object wird als klickbarer Link angezeigt.

1. klicken Sie auf den angezeigten Typ;
2. Wählen Sie im Auswahlfenster einen Typ.
3. Das Fenster schließt sich automatisch;
4. Die Seite lädt die Regeln des gewählten Typs neu.

Das Fenster bietet nur die in Sicherheit konfigurierten Typen an.

6.2 Lesen der bestehenden Regeln

Für den ausgewählten Typ zeigt die Tabelle Folgendes an:

Säule	Inhalt
Status	Actif oder Inactif.
Begünstigte Gruppe	Der Name der Gruppe und, sofern verfügbar, ihr Distinguished Name.
Erteilte Erlaubnis	Erlaubnis, die durch die Regel vorgegeben wird.
Bedingung für dasselbe Objekt	Eine Berechtigung, die der Nutzer bereits haben muss.
Aktionen	Die Regel aktivieren, deaktivieren oder löschen.

Aktive Regeln werden vor inaktiven Regeln angezeigt.

6.3 Hinzufügen einer Regel

Wie füge ich eine Regel hinzu?

1. Wählen Sie den Typ des sicheren Objekts aus.
2. in Neues bedingtes Recht, klicken Sie auf Wähle eine Gruppe ;
3. Wählen Sie die Begünstigtengruppe in dem Fenster aus, das nur die Gruppen anzeigt.
4. wählen Sie die erteilte Erlaubnis;
5. eine andere erforderliche Erlaubnis wählen;
6. Klicken Sie auf In den Warenkorb legen ;
7. Überprüfen Sie die Bestätigungsmeldung und die neue aktive Leitung.

Der Hinzufügen-Button wird nach der Auswahl der Gruppe verfügbar, solange der Typ aktiv ist und mindestens zwei Berechtigungen hat.

6.4 Deaktivieren, Reaktivieren oder Löschen

Deaktivieren Entfernt sofort den bedingten Beitrag, ohne die Definition zu löschen. Diese Aktion ist für einen Test oder eine vorübergehende Aussetzung geeignet.

Aktivieren Gibt die Regel nach einer neuen Überprüfung der Abhängigkeitszyklen an den Dienst zurück.

Löschen Löscht die Definition nach Bestätigung. Um sie wiederherzustellen, muss sie neu erstellt werden.

Wenn ein anderer Administrator die Regel zwischen der Anzeige und der angeforderten Aktion geändert hat, wird die Registrierung abgelehnt. Die Seite muss dann neu geladen werden, bevor sie neu gestartet werden kann.

7. Admin-Fassade und Sicherheits-API

Die Verwaltungsoberfläche des Enhancers verändert die Sicherheitsdaten niemals direkt. Seine Aktionen laufen durch eine gemeinsame Verwaltungsfassade, die die Grenze zwischen der Schnittstelle und der Sicherheitsdomäne bildet. Die gleichen Geschäftsaufträge sind nun für Integrationen über die HTTP Web API von SecurityController. Egal, ob eine Bestellung vom Enhancer oder der API stammt, sie wird an dieselbe Fassade übertragen und profitiert daher von denselben Validierungen.

7.1 Verfügbare Verwaltungsanordnungen

Betrieb	Route HTTP	Erwartete Informationen	Ergebnis
Beratung	GET /api/Security/ConditionalPermissionGrants	Optionaler Filter securedObjectTypeIdentifier.	Eine Liste aller passenden Regeln, aktiv oder inaktiv, mit ihren IDs und Versionen.
Erstellen Sie	POST /api/Security/ConditionalPermissionGrants	Titel, optionale Beschreibung, Gruppe, sicherer Typ, erteilte Erlaubnis und erforderliche Erlaubnis.	Erstellen Sie eine aktive Regel und geben Sie deren Version zurück.
Ändere den Bundesstaat	PATCH /api/Security/ConditionalPermissionGrants/{identifier}/Enabled	Der neue Staat und die bekannte Version der Regel.	Aktivieren oder deaktivieren und die neue Version zurückgeben.
Löschen	DELETE /api/Security/ConditionalPermissionGrants/{identifier}	Bekannte Version der Regel.	Die Regel wird gelöscht.

Die RowVersion wird in Base64 in JSON-Vermittlungen dargestellt. Nach einem neuen oder geänderten Zustand muss der Aufrufer den neu zurückgegebenen Wert für seine nächste Operation auf der Regel behalten.

Es gibt keine Reihenfolge, um eine bestehende Definition global zu ändern. Um die Gruppe, den Typ oder eine der Berechtigungen zu ändern, musst du die neue Regel erstellen, sie validieren und dann die alte deaktivieren oder löschen.

7.2 Fassadensteuerungen

Die Fassade wendet systematisch folgende Schutzmaßnahmen an:

• der Autor wird anhand des authentifizierten Kontexts bestimmt;
• Nur Cerebrate und die Plattform-Root-Administratoren können diese Konfiguration ändern.
• die Gruppe und der Typ müssen existieren;
• Der Typ muss zum Zeitpunkt der Entstehung aktiv sein.
• Beide Berechtigungen müssen existieren, unterschiedlich sein und zum gewählten Typ gehören.
• Duplikate und Zyklen werden abgelehnt;
• jede Änderung wird in einer atomaren Transaktion erfasst;
• Eine versiege, die veraltet ist, führt zu einer Antwort 409 Conflict anstatt eine jüngere Änderung zu überschreiben;
• Nach der Validierung wird die Sicherheitsdomäne neu geladen und die Änderung an andere Instanzen gemeldet.
• Die Quelle der Operation und der Autor werden in die Serverprotokolle geschrieben.

8. Auswirkungen von Veränderungen

Veränderung	Erwartete Wirkung
Erstellung einer Regel	Die Regel wird für bestehende und zukünftige Objekte aktiv, sobald die Sicherheitsdomäne aktualisiert wird.
Hinzufügen eines Benutzers zur Begünstigtengruppe	Der Nutzer kann von der Regel gemäß den erforderlichen Berechtigungen profitieren.
Rückzug aus der Begünstigtengruppe	Der Nutzer profitiert auf diesem Weg der Mitgliedschaft nicht mehr von der Regel.
Hinzufügen oder Entfernen der erforderlichen Berechtigung für ein Objekt	Die bedingte Erlaubnis erscheint oder verschwindet für dasselbe Objekt.
Außerdienststellung	Die Definition bleibt sichtbar, nimmt aber nicht mehr an Entscheidungen teil.
Reaktivierung	Die Regel nimmt nach der Validierung erneut an Entscheidungen teil.
Löschung	Die Regel verschwindet; direkte Rechte bleiben unverändert.

9. Aktuelle Grenzen

Der aktuelle Mechanismus erlaubt nicht:

• Wählen Sie einen einzelnen Nutzer als Begünstigten aus.
• Benötigt mehrere Berechtigungen gleichzeitig in einer einzigen Regel.
• Verwende die Erlaubnis eines anderen Objekts als Bedingung.
• verbinden zwei verschiedene Objekttypen in derselben Regel;
• eine explizite Weigerung zu ignorieren;
• eine zyklische Abhängigkeit schaffen;
• die Verwaltung direkt über eine dedizierte öffentliche API-Webroute offenlegen.

Zum Beispiel zwei Pflichtbedingungen auszudrücken See und Approve, muss das Modell geändert werden. Zwei getrennte Regeln würden derzeit bedeuten See oder Approve.

10. Fehlerbehebung

Symptom	Prüfungen
Ein CP-Mitglied sieht die Ausrüstung, kann sie aber nicht bearbeiten	Überprüfen Sie, ob die Regel aktiv ist, dass ihr Typ und ihre Berechtigungen korrekt sind, dass der Benutzer zu CP gehört und dass es keine Ablehnungen gibt Modify trifft nicht zu.
Ein CP-Mitglied kann zu viel Ausrüstung modifizieren	Suche nach einem direkten Recht Modify zu weit gefasst, und dann den Ursprung seiner Rechte zu überprüfen See.
Die erwartete Gruppe erscheint in der Auswahl nicht	Überprüfen Sie, dass das Objekt als Gruppe in der Sicherheitsdomäne existiert, und laden Sie die Seite neu.
Der Hinzufügen-Button bleibt nicht verfügbar	Überprüfen Sie die Auswahl der Gruppe, den aktiven Status des Typs und das Vorhandensein von mindestens zwei Berechtigungen.
Die Ergänzung wird abgelehnt	Überprüfen Sie, dass die Berechtigungen unterschiedlich sind, dass sie zum gewählten Typ gehören, dass die Regel nicht bereits existiert und dass sie keinen Zyklus erzeugt.
Eine Klage wird nach einer alten Ansicht abgelehnt	Reload-Seite: Eine weitere Änderung hat wahrscheinlich die Regelversion geändert.
Die Deaktivierung scheint keine Wirkung zu haben	Überprüfe, ob ein direktes Recht oder eine andere bedingte Regel noch die Erlaubnis gewährt.

11. Checkliste für die Indienststellung

• Der relevante sichere Typ ist aktiv.
• Gewährte und erforderliche Berechtigungen gehören zu diesem Typ.
• Die Empfängergruppe entspricht dem erwarteten funktionalen Profil.
• Die erforderliche Genehmigung stellt korrekt den zu behaltenden Umfang dar.
• Die Regel dupliziert keine bestehende Regel.
• Es wird kein Zyklus von Abhängigkeiten eingeführt.
• Direkte, zu weit gefasste Rechte, wurden identifiziert.
• Explizite Ablehnungen wurden überprüft.
• Verschachtelte Gruppen wurden überprüft.
• Der Rechtetester bestätigt das Ergebnis bei einem sichtbaren und einem nicht sichtbaren Objekt.
• Die Regel wurde von einem echten CP- oder Master Records-Nutzer validiert.