sql - titel - title-tag




Wie geht man am besten mit mehreren Berechtigungstypen um? (4)

Mir begegnet oft das folgende Szenario, in dem ich viele verschiedene Arten von Berechtigungen anbieten muss. Ich verwende hauptsächlich ASP.NET / VB.NET mit SQL Server 2000.

Szenario

Ich möchte ein dynamisches Berechtigungssystem anbieten, das mit verschiedenen Parametern arbeiten kann. Angenommen, ich möchte entweder einer Abteilung oder nur einer bestimmten Person Zugriff auf eine Anwendung geben. Und so tun, als hätten wir eine Reihe von Anwendungen, die weiter wachsen.

In der Vergangenheit habe ich eine der folgenden zwei Möglichkeiten gewählt, die ich dafür kenne.

1) Verwenden Sie eine einzelne Berechtigungstabelle mit speziellen Spalten, die zum Bestimmen der Anwendung der Parameter verwendet werden. Die speziellen Spalten in diesem Beispiel sind TypeID und TypeAuxID. Das SQL würde ungefähr so ​​aussehen.

SELECT COUNT(PermissionID)
FROM application_permissions
WHERE
(TypeID = 1 AND TypeAuxID = @UserID) OR
(TypeID = 2 AND TypeAuxID = @DepartmentID)
AND ApplicationID = 1

2) Verwenden Sie für jeden Berechtigungstyp eine Zuordnungstabelle und fügen Sie alle zusammen.

SELECT COUNT(perm.PermissionID)
FROM application_permissions perm
LEFT JOIN application_UserPermissions emp
ON perm.ApplicationID = emp.ApplicationID
LEFT JOIN application_DepartmentPermissions dept
ON perm.ApplicationID = dept.ApplicationID
WHERE q.SectionID[email protected]SectionID
  AND (emp.UserID[email protected]UserID OR dept.DeptID[email protected]DeptID OR
 (emp.UserID IS NULL AND dept.DeptID IS NULL)) AND ApplicationID = 1
ORDER BY q.QID ASC

Meine Gedanken

Ich hoffe, dass die Beispiele Sinn machen. Ich habe sie zusammen gepflastert.

Das erste Beispiel erfordert weniger Arbeit, aber keiner von ihnen fühlt sich wie die beste Antwort. Gibt es einen besseren Weg, damit umzugehen?


Die Art und Weise, wie ich normalerweise über Codierungs-Berechtigungssysteme gehe, besteht aus 6 Tabellen.

  • Benutzer - das ist ziemlich einfach es ist Ihre typische Benutzer Tabelle
  • Gruppen - das wäre auch für Ihre Abteilungen
  • Rollen - Dies ist eine Tabelle mit allen Berechtigungen, die im Allgemeinen auch einen von Menschen lesbaren Namen und eine Beschreibung enthält.
  • Users_have_Groups - Dies ist eine Many-to-Many-Tabelle mit den Gruppen, zu denen ein Benutzer gehört
  • Users_have_Roles - eine weitere Many-to-Many-Tabelle mit den Rollen, die einem einzelnen Benutzer zugewiesen sind
  • Groups_have_Roles - die letzte Many-to-Many-Tabelle, welche Rollen jede Gruppe hat

Am Anfang einer Benutzersitzung würden Sie eine Logik ausführen, die jede Rolle, die sie zugewiesen haben, entweder im Verzeichnis oder durch eine Gruppe herausholt. Dann codieren Sie gegen diese Rollen als Ihre Sicherheitsberechtigungen.

Wie ich schon sagte, ist es das, was ich normalerweise tue, aber Ihr Revier kann variieren.


Ein Ansatz, den ich in verschiedenen Anwendungen verwendet habe, ist eine generische PermissionToken-Klasse mit einer veränderbaren Value-Eigenschaft. Dann fragen Sie die angeforderte Anwendung ab, sie zeigt Ihnen, welche PermissionTokens benötigt werden, um sie zu verwenden.

Die Versandanwendung könnte Ihnen zum Beispiel sagen, dass sie Folgendes benötigt:

new PermissionToken()
{
    Target = PermissionTokenTarget.Application,
    Action = PermissionTokenAction.View,
    Value = "ShippingApp"
};

Dies kann offensichtlich auf Erstellen, Bearbeiten, Löschen usw. erweitert werden. Aufgrund der benutzerdefinierten Value-Eigenschaft können beliebige Anwendungen, Module oder Widgets ihre eigenen erforderlichen Berechtigungen definieren. YMMV, aber das war immer eine effiziente Methode für mich, die ich gut skalieren konnte.


Zusätzlich zu den Lösungen von John Downey und jdecuyper habe ich am Ende / Anfang des Bitfelds ein "Explicit Deny" -Bit hinzugefügt, damit Sie additive Berechtigungen nach Gruppen, Rollenmitgliedschaften und Subtrahieren von Berechtigungen basierend auf expliziter Verweigerung ausführen können. Einträge, ähnlich wie NTFS funktioniert, erlaubterweise.


Ehrlich gesagt, würden die ASP.NET Membership / Roles Features perfekt für das beschriebene Szenario funktionieren. Das Schreiben eigener Tabellen / Procs / Klassen ist eine großartige Übung und Sie können sehr genaue Kontrolle über winzige Details erhalten, aber nachdem ich dies selbst getan habe, bin ich zu dem Schluss gekommen, dass es besser ist, einfach die eingebauten .NET-Elemente zu verwenden. Eine Menge vorhandener Code wurde entwickelt, um das zu umgehen, was gut ist. Das Schreiben von Grund auf hat ungefähr 2 Wochen gedauert und war nicht annähernd so robust wie .NETs. Sie müssen so viel Mist programmieren (Passwortwiederherstellung, automatische Sperre, Verschlüsselung, Rollen, eine Berechtigungsschnittstelle, Tonnen von Procs, usw.) und die Zeit könnte besser woanders verbracht werden.

Sorry, wenn ich deine Frage nicht beantwortet habe, bin ich wie der Typ, der sagt, c # zu lernen, wenn jemand eine vb-Frage stellt.







permissions