Die zwei Rechte-Matrizen

Worum es geht

Wenn von „der Rechte-Matrix“ die Rede ist, sind oft zwei verschiedene Tabellen gemeint. Sie beantworten verschiedene Fragen, und nur eine davon liegt in CIAS.

• Matrix A sagt, wie ein Recht getragen wird: Ist es eine Realm-Rolle, eine Client-Rolle, eine Rolle in einem Mandanten, eine Gruppe oder ein Attribut? Wo steht es im Token? Wer darf es vergeben? Das ist CIAS.
• Matrix B sagt, was ein Recht erlaubt: Darf diese Rolle dieses Modell lesen, über dieses Feld in ein anderes Modell gehen, diese Zeile sehen? Das ist die Anwendung, bei CodamAI meist CDMS.

Die beiden Matrizen nebeneinander

Matrix A: wie ein Recht getragen wird

Ein Recht kann auf fünf Arten an einer Person hängen. Jede Art landet an einer anderen Stelle im Token.

Ein paar Begriffe dazu:

• Eine Realm-Rolle gilt im ganzen Keycloak-Realm, also für alle Module zugleich. Deshalb sind Realm-Rollen für das reserviert, was Module übergreift, etwa platform-admin und die beiden Kontextwechsel-Rollen. Ein Modul meldet nie eine Realm-Rolle an.
• Eine Client-Rolle gehört zum Client eines Deployments, etwa cdms-backend. So hat jede Rolle einen zweiteiligen Namen: cdms-backend / hr-employee-read.
• Delegation ist eine Liste am Rollenkatalog: Wer eine dieser Rollen hat, darf die Rolle weitergeben. Ohne Delegation vergibt nur ein Plattform-Administrator.

Global oder im Mandanten

Die spannende Zeile ist die dritte. Läuft eine Anfrage unter einem dynamischen Mandanten, und hat die Person dort eigene Rollen, dann ersetzen diese Rollen die global vergebenen Client-Rollen. Sie werden nicht addiert.

Realm-Rollen sind davon nie betroffen. Sie gelten immer.

Damit eine global vergebene Client-Rolle nicht still wirkungslos bleibt, lehnt CIAS sie ab, wenn der Heimatmandant der Person ein dynamischer Mandant ist. Die Rolle muss dann im Mandanten vergeben werden. Den Ablauf im Detail zeigt Effektive Rollen: global oder im Mandanten.

Attribute sind auch Rechte

Ein Attribut sieht nicht aus wie ein Recht, wirkt aber wie eines. projects = alpha, beta am Konto bedeutet in CDMS: Diese Person sieht nur Zeilen der Projekte alpha und beta. Ein Wert mehr ist mehr Reichweite, und * schaltet den Filter ab. Deshalb gehören Attribute in Matrix A: CIAS führt, wer sie schreiben darf, und prüft beim Schreiben die Obergrenze.

Matrix B: was ein Recht erlaubt

Matrix B steht im Modell der Anwendung. Bei CDMS wird sie im Hub modelliert und in den Code generiert.

CDMS liest dafür nur das Token. Es fragt CIAS nicht, ob eine Rolle „eigentlich“ vergeben sein sollte.

Wer beantwortet welche Frage?

Warum CIAS keine Modell-Operations-Matrix hat

Man könnte meinen, es wäre praktisch, wenn CIAS auch wüsste, dass hr-employee-read das Modell employee lesen darf. Dann könnte eine CIAS-Oberfläche alles auf einen Blick zeigen. CIAS hält diese Tabelle trotzdem absichtlich nicht:

• Sie wäre eine Kopie des Berechtigungsmodells jeder Anwendung. Kopien laufen auseinander.
• Bei jeder Abweichung würde das Token gewinnen, denn CDMS prüft das Token und nicht CIAS. Die CIAS-Oberfläche würde dann eine falsche Antwort zeigen.
• Nur die Anwendung weiß, was ihre Rollen bedeuten. Deshalb meldet sie ihre Rollen bei CIAS an, statt dass CIAS sie erfindet.

Weiter

• Realm-Rolle, Client-Rolle, Organisationsrolle
• Wie eine Rolle aus dem Code ins Token kommt
• Die drei Ebenen im Überblick: Matrix B aus Sicht von CDMS