Es ist sicherlich möglich, AzMan dafür zu verwenden. Ich habe mehrere Anwendungen mit dieser Form der Ressourcen- und rollenbasierten Sicherheit implementiert. AzMan ist tatsächlich sehr flexibel, und ich habe auch eine Ressourcenhierarchie implementiert (denke Windows-Dateisystem-Sicherheit), mit benutzerdefinierten Benutzern und Gruppen und voller Vererbung von Rollen in der Hierarchie, zusammen mit der Fähigkeit, Operationen auf jeder Ebene zu verweigern. Um dies zu tun, müssen Sie AzMan Scopes verstehen.
Mit AzMan Scopes können Sie einzelne Rollen/Operationssätze für eine bestimmte Ressource erstellen. Diese Ressource kann alles sein, was Sie wählen, es ist nur eine String-ID für AzMan. Diese Rollen/Operationen werden zusätzlich zu allen auf Anwendungsebene zugewiesenen Rollen hinzugefügt.
Die Art, wie ich es zuvor implementiert habe, ist die ID des Objekts als der Name des Bereichs zu verwenden. Idealerweise sollte dies eine GUID sein (obwohl es die MMC-Anwendung sehr unordentlich macht), aber Sie könnten auch ein "Typ-ID" -Format verwenden, d. H. "CustomerAlert-1" (viel freundlicher in der MMC-App). Wenn Sie AccessCheck in azman ausführen, übergeben Sie den Namen des Bereichs an AccessCheck (im Moment wird nur ein einziger Bereich benötigt, obwohl die AccessCheck-Definition ein Array zulässt).
Ich werde durch ein Beispiel laufen, wie dies zu tun (für alle anderen kämpfen) ...
- Operationen erstellen wie CustomerAlertView, CustomerAlertEdit, CustomerAlertDelete am Anwendungsebene.
- Erstellen Sie eine Rolle Definition namens CustomerAlertOwner auf Anwendungsebene.
- Fügen Sie alle die Vorgänge zur CustomerOwner Rolle hinzu. Erstellen Sie in Ihrer App einen Bereich namens "CustomerAlert-1".
- Erstellen Sie eine Rollenzuweisung namens "Owner" auf der Anwendungsbereich.
- Fügen Sie die CustomerAlertOwner Rollendefinition zur Rolle "Owner" hinzu.
- Fügen Sie dieser Owner-Rolle den Kunden/Benutzer "Dave" hinzu.
- Nun, wenn Sie eine Zugangsprüfung zu tun in etwa DeleteCustomerAlert(), können Sie einfach die ID der Operation CustomerAlertDelete passieren und der Typ/ID des Objekts, das Sie als Bereich dh löschen? " CustomerAlert-1"
für Objekteigenschaftsbasierte Zugriffskontrollen (dh aussperren Lese/schreiben von bestimmten Eigenschaften) gibt es 2 Ansätze, die ich von .. denken kann erste Operationen in den Objekten Umfang für jedes zuweisen Eigenschaft und Zugriffsart, zB PropertyNameGet, PropertyNameSet, PropertyAddressAdd. Sie können dies vereinfachen, indem Sie die Vorgänge auf Anwendungsebene erstellen und häufig verwendete Berechtigungssätze mithilfe von Aufgaben/Rollen gruppieren. Die andere Möglichkeit besteht darin, den Gültigkeitsbereich für jede Eigenschaft (CustomerAlert-1-Name) zu verwenden. Dies wäre jedoch unordentlich und nicht so effizient, da beim Zugriff auf ein bestimmtes Objekt mehrere Bereiche separat geladen werden müssen.
Sie sollten bedenken, dass Sie eine Operation in AzMan nicht explizit ablehnen können, Sie weisen dem Benutzer in der Anwendung/dem Bereich keine Rolle zu. Dies bedeutet, dass bestimmte Arten von Ressourcenhierarchien (Gruppen/Benutzer) usw. schwieriger zu implementieren sind.
Wenn Sie weitere Hilfe mit AzMan benötigen, zögern Sie nicht zu fragen .. Ich habe die meisten Szenarien abgedeckt.