Frage Erstellen eines Plattformberechtigungserlaubnismodells


Ein wichtiger Teil der Sicherheit einer PaaS-Authentifizierung (PaaS) besteht darin, die Rechte oder Berechtigungen einer bestimmten Anwendung oder eines Benutzers entweder auf Benutzer- / App-Basis oder auf einer bestimmten Basis zu begrenzen und / oder zu definieren Per-Authentifizierung Basis.

Das allgemeine Berechtigungsmodell, das in modernen Plattform- oder Produkt-APIs gefunden wird, basiert auf einer Idee von "Bereiche". In meiner Forschung GitHub, Facebook, Instagram, Etsy (und mehr) verwenden diese Art der Berechtigungsmodellierung in ihren OAuth-Implementierungen. Dieses "Scopes" -Modell scheint sich jedoch nur damit zu befassen, wie externe (dh Drittanbieter-) Anwendungen auf Daten eines authentifizierten Benutzers zugreifen.

Intern scheinen Berechtigungsmodelle entweder auf ein "rollen" -basiertes Modell (Admin, Moderator, Benutzer usw.) oder eine Reihe anderer benutzerdefinierter Implementierungen ausgerichtet zu sein.

Meine Frage ist das: "Welches Berechtigungsmodell würde am besten zu einem modernen PaaS passen, das seine Benutzer sowohl vor bestimmten Aktionen als auch vor dem Zugriff von Drittanbieter-Anwendungen auf die Daten eines Benutzers schränken möchte und wie kann dies auf eine leistungsbewusste Weise geplant werden?"

Meine ersten Recherchen führten mich zu einer internen und externen Nutzung eines bereichsbasierten Berechtigungsmodells. Leider ist die Architektur eines solchen Systems nicht trivial. Ich habe mehrere Methoden zum Erstellen einer solchen Architektur gesehen:

  1. Der AR-freundliche relationale DB-Weg:

    • Erstellen mehrerer Tabellen mit Join-Tabellen für eine Viele-zu-Viele-Beziehung zwischen einer Liste von Berechtigungen, den verfügbaren Berechtigungen eines Benutzers, dem Token eines Benutzers und den aktiven Berechtigungen eines Benutzer-Tokens.

    • Ein Benutzer kann sich mit einem Token authentifizieren und so viele Berechtigungen angeben, dass er für dieses Token verfügbar ist bis zu die Berechtigungen, die ursprünglich für diesen Benutzer festgelegt wurden

  2. Der clevere Bit-Maskier-Weg:

    • Verwenden einer einfachen Ganzzahlspalte in einem Datensatz zum Speichern eines ganzzahligen Werts

    • Auf den Integer-Wert wird auf binäre Weise zugegriffen, wobei bitweise Operatoren verwendet werden, um die Berechtigungen eines Benutzers oder seines Tokens durch Darstellen einer Berechtigung als ein einzelnes Bit festzulegen, abzurufen (toggeln)

Sie scheinen für beide Pros und Contras zu sein. Der AR-freundliche Weg scheint eine sehr flexible Lösung zu sein, aber es scheint auch, als könnte es ein ernsthafter Leistungseinbruch sein, da mehrere Verbindungen / Abfragen ausgeführt werden müssten und ORM-Modellinstanzen erstellt werden müssten jeder authentifizierte Anruf. Die Bitmaskierungsmethode scheint sehr schnell und effizient zu sein, wäre aber weniger intuitiv zu entwickeln und wäre fehleranfälliger. Bit-Masking scheint auch eine limitierende Lösung zu sein, da es nur ein sehr "binäres" Berechtigungsmodell (kann oder kann nicht) ohne Mittelweg- / Happy-Medium erlauben würde und dass es die Berechtigungen beschränken würde ein hartes 64-Bit-Limit basierend auf Hardwarebeschränkungen.

Gibt es eine andere Methode der Berechtigungsmodellierung oder -architektur, an der ich vermisse / nicht denke? Oder bin ich auf dem richtigen Weg und die Leistungsbeurteilung ist nicht so wichtig (soweit die relationale Methode geht), wie ich es ausgemacht habe?

Ich danke dir sehr!

tl; dr:

Welches Berechtigungsmodell würde am besten zu einem modernen PaaS passen, das sowohl seine Benutzer vor bestimmten Aktionen schränken als auch Anwendungen von Drittanbietern vom Zugriff auf die Daten eines Benutzers abhalten möchte, und wie könnte dies auf eine leistungsbewusste Weise geplant werden?


14
2017-07-16 18:38


Ursprung


Antworten:


Ich würde mit einem Blick auf Spring Security ACL beginnen. Sie verwenden Bitmasken und können (relativ) leicht in einen Cache wie zB Eccache integriert werden. Wenn Sie JPA für den Datenzugriff verwenden, können Sie auch den JPA-Cache verwenden.

http://static.springsource.org/spring-security/site/docs/current/reference/springsecurity.html

Das Schema:

http://static.springsource.org/spring-security/site/docs/3.0.x/reference/appendix-schema.html

OAuth:

http://static.springsource.org/spring-security/oauth/


1
2017-07-24 19:02