Rollenbasierte Zugriffssteuerung mit dem Windows Server 2003-Autorisierungs-Manager

Veröffentlicht: 10. Apr 2003 | Aktualisiert: 22. Jun 2004
Von Mohan Rao Cavale

Auf dieser Seite

Einführung Einführung
Benutzerautorisierungsmodell in Windows NT 4.0 und Windows 2000 Benutzerautorisierungsmodell in Windows NT 4.0 und Windows 2000
Rollenbasierte Zugriffssteuerung Rollenbasierte Zugriffssteuerung
Autorisierungsspeicher Autorisierungsspeicher
Der Anwendungsentwicklungsprozess mit dem Autorisierungs-Manager Der Anwendungsentwicklungsprozess mit dem Autorisierungs-Manager
Identifizieren von Rollen und Aufgaben Identifizieren von Rollen und Aufgaben
Durchführen von Installationsaufgaben Durchführen von Installationsaufgaben
Initialisieren des Autorisierungs-Managers und Zugreifen auf den Speicher Initialisieren des Autorisierungs-Managers und Zugreifen auf den Speicher
Initialisieren des Clientkontexts bei Clientverbindungen Initialisieren des Clientkontexts bei Clientverbindungen
Implementieren des benutzerdefinierten Verhaltens gemäß den Rollen Implementieren des benutzerdefinierten Verhaltens gemäß den Rollen
Schlussfolgerung Schlussfolgerung

Einführung

Damit Anwendungen die Aufgaben durchführen können, für die sie konzipiert wurden, müssen sie Vorgänge durchführen und im Namen des Anwendungsbenutzers auf Systemressourcen zugreifen können, wobei diese Vorgänge und Ressourcen gleichzeitig vor unbefugtem Zugriff geschützt werden müssen. Bei den Betriebssystemen Microsoft Windows NT, Windows 2000 und Windows XP können Administratoren steuern, ob ein Prozess auf sicherungsfähige Objekte zugreifen oder verschiedene Systemverwaltungsaufgaben durchführen kann. Diese Steuerung erfolgt über ein objektzentriertes Autorisierungsmodell mithilfe von Zugriffssteuerungslisten (ACLs, Access Control Lists). Jedem Systemobjekt ist eine Liste von Vertrauensnehmern (Benutzerkonto, Gruppenkonto oder Anmeldesitzung) mit spezifischen Rechten für dieses Objekt zugeordnet. Dieses Modell ist gut zum Sichern des Zugriffs auf wohldefinierte, persistente Ressourcen geeignet. ACLs sind jedoch weniger für andere Anwendungstypen geeignet, z.B. für Anwendungen, die den Zugriff auf bestimmte Geschäftsprozesse einschränken.

In Windows Server 2003 Enterprise Edition wird eine komplementäre Autorisierungsschnittstelle, der so genannte Autorisierungs-Manager, eingeführt, der die rollenbasierte Zugriffssteuerung ermöglicht. Der Autorisierungs-Manager stellt ein natürliches Framework für Geschäftsprozessanwendungen bereit, bei denen das Organisationsmodell in der Anwendungssicherheitsumgebung dargestellt werden muss. Bei diesen Anwendungstypen vereinfacht dieser neue Satz von APIs und Verwaltungstools das Anwendungsdesign und die Anwendungssicherheitsverwaltung.

Benutzerautorisierungsmodell in Windows NT 4.0 und Windows 2000

Windows NT und Windows 2000 verfügen über ein objektzentriertes Autorisierungsmodell. Ein Ressourcen-Manager (RM) verwaltet seinen eigenen Satz von Objekten, die von einer Sicherheitsbeschreibung geschützt sind. Wenn ein Client den Zugriff auf eine Ressource anfordert, die durch einen RM geschützt ist, nimmt der RM die Identität des Clients an und führt einen Aufruf an die AccessCheck-API durch. Die AccessCheck-API wiederum überprüft das Clientsicherheitstoken, den gewünschten Zugriff auf das Objekt und die Sicherheitsbeschreibung des Objekts. Die AccessCheck-API kehrt zum RM zurück und antwortet mit "Ja" oder "Nein", wodurch der RM festlegen kann, ob dem Client der Zugriff auf das Objekt gestattet werden soll.

Obwohl das objektzentrierte Modell einfach ist, weist es gewisse Einschränkungen auf. Es kann z.B. Fragen wie "Welche Aktionen können an diesem Objekt durchgeführt werden?" beantworten. Andererseits kann es keine Antwort auf die Frage "Welche Aktionen kann der Benutzer in dieser Anwendung durchführen?" geben. Derartige Modelle erfordern, dass Administratoren das Organisationsmodell des Unternehmens in Berechtigungen für Objekte übersetzen, wobei jedes Objekt über eine Liste von Zugriffsberechtigungen verfügt, die den verschiedenen Benutzern und Gruppen in der Organisation zugewiesen sind. Damit ein Anwendungsentwickler eine bestimmte Anwendungsrolle unterstützen kann, muss er alle Objekte im System auflisten und dem Benutzer die entsprechenden Zugriffsberechtigungen zuweisen. Darüber hinaus handelt es sich bei den für die Objekte gewährten Berechtigungen um Berechtigungen auf sehr niedriger Ebene (z.B. Lesezugriff oder Zurückschreiben), die sich oft nicht leicht in Abstrahierungen auf höherer Ebene übersetzen lassen.

Je umfassender die Objektauflistungen oder Hierarchien, umso mehr unterschiedliche Punkte gibt es, an denen Administratoren die Berechtigungen verwalten müssen. Dies führt zu einem erhöhten Verwaltungsaufwand. Dieser Aufwand lässt sich durch die wohlüberlegte Verwendung von Ressourcen- und Benutzergruppen reduzieren. Dies setzt jedoch eine konsistente Verwendung und Koordination unter den einzelnen Administratoren sowie eine genaue Definition der Ressourcengruppen voraus. Bei Windows NT-Gruppen ist es leichter, Benutzer mit spezifischen Rechten zusammenzufassen. Aber auch hier muss der Administrator den Objektzugriff den Organisationsprozessen zuordnen. Windows NT-Gruppen müssen außerdem von einem Domänenadministrator erstellt und verwaltet werden.

Rollenbasierte Zugriffssteuerung

Die rollenbasierte Zugriffssteuerung ist im Gegensatz dazu ein benutzerzentriertes Autorisierungsmodell. Anstatt Objekte im System für jeden Benutzer aufzulisten und Rechte zuzuweisen, können Administratoren bei der rollenbasierten Zugriffssteuerung die Zugriffssteuerung im Hinblick auf die Organisationsstruktur eines Unternehmens angeben. Bei der rollenbasierten Zugriffssteuerung wird ein zentrales Objekt (eine "Rolle") bereitgestellt, dem ein Benutzer für die Durchführung einer bestimmten Arbeitsaufgabe zugewiesen ist. Eine Rolle beinhaltet implizite Autorisierungsberechtigungen für einen bestimmten Satz von Ressourcen.

Bei der rollenbasierten Zugriffssteuerung werden Berechtigungen nicht über Rechte auf niedriger Ebene vergeben, sondern über Abstrahierungen auf höherer Ebene, die den Anwendungsvorgängen und -aufgaben entsprechen. Vorgänge werden als einzelne Einheit ausgeführt, während hingegen Aufgaben aus mehreren Vorgängen (und anderen Aufgaben) bestehen können. Verwenden wir als Beispiel eine Anwendung, bei der Benutzer den Projektstatus angeben, zur Ansicht veröffentlichen und anzeigen können. Der Status wird in einer webbasierten Oberfläche angegeben, veröffentlicht und angezeigt. Nach der Veröffentlichung wird die Datenbank aktualisiert und eine E-Mail-Nachricht an interessierte Empfänger gesendet. In Abbildung 1 ist ein Beispiel dafür dargestellt, wie Vorgänge auf niedriger Ebene zum Erstellen von Aufgaben auf höherer Ebene verwendet werden können.


azmanroles01.gif

Abbildung 1. Vorgänge auf niedriger Ebene werden zum Erstellen von Aufgaben auf höherer Ebene verwendet


Beim rollenbasierten Zugriffssteuerungsmodell ist die Rolle die Schnittstelle, die ein Administrator zum Verwalten von Berechtigungen und Zuweisungen verwendet. So kann ein Unternehmen z.B. eine Rolle namens "Ingenieur" erstellen, die entsprechend den Berechtigungen definiert ist, die Ingenieure für ihre Arbeit benötigen. Jedem neu eingestellten Ingenieur wird sofort die Rolle "Ingenieur" zugewiesen, und er verfügt somit sofort über alle erforderlichen Berechtigungen für diese Aufgabe. Andererseits wird jeder Ingenieur, der die Stelle als Ingenieur verlässt, aus der Rolle "Ingenieur" entfernt und verfügt nicht mehr über den Zugriff als Ingenieur. Da eine Rolle den Zugriff im Hinblick auf das Organisationsmodell eines Unternehmens gewährt, ist dies eine intuitivere und natürlichere Methode, mit der Administratoren die Zugriffssteuerung festlegen können. Während sich ACLs gut für wohldefinierte, persistente Ressourcen eignen, liegen die Stärken des rollenbasierten Modells im Schutz von Workflows oder Gruppen von mehreren unterschiedlichen Vorgängen (z.B. "Lesen von der Datenbank", "E-Mail senden"), die von der Anwendung ausgeführt werden müssen. In Anlehnung an das vorherige Beispiel zeigt Abbildung 2 die Rolle "Ingenieur" (Engineer) mit der Berechtigung zum Angeben und Anzeigen des Status, die Rolle "Manager" mit der Berechtigung zum Veröffentlichen und Anzeigen des Status und die Rolle "Leitender Mitarbeiter" (Executive) mit der Berechtigung zum Anzeigen des Status.


azmanroles02.gif

Abbildung 2. Zugriffsworkflow für rollenbasierte Berechtigungen


Wenn eine Rolle erst einmal definiert ist, kann sie leicht verwaltet werden. Der schwierigere Teil der Aufgabe besteht darin, die Rolle zu definieren und die Zugriffskriterien anzugeben. Die Erfahrung zeigt jedoch, dass die Rollenzugriffsspezifikationen nach dem Definieren der Rollen selten geändert werden. Eher wird die Mitgliedschaft in einer Rolle geändert. Grundsätzlich gilt: Leicht durchführbare Aktivitäten können häufig und schwer durchführbare Aktivitäten sollen selten ausgeführt werden.

Mit der rollenbasierten Zugriffssteuerung in Windows Server 2003 Enterprise Edition können Benutzer auch in Gruppen zusammengefasst werden. Rollenbasierte Zugriffssteuerungsgruppen sind den Gruppen im Verzeichnisdienst Active Directory® ähnlich, werden jedoch für einen bestimmten Satz von Anwendungen, eine einzelne Anwendung oder einen Bereich innerhalb einer Anwendung verwaltet.

Der Autorisierungs-Manager führt zwei Arten von anwendungsspezifischen Gruppen ein:

  • Anwendungsbasisgruppe: Die Anwendungsbasisgruppe enthält ähnlich wie Windows NT-Gruppen eine Liste von Mitgliedern. Anders als Windows NT-Gruppen enthält sie auch eine zusätzliche Liste für Nichtmitglieder. Die Liste der Nichtmitglieder lässt Ausnahmen zu. Es kann somit eine große Gruppe verwendet werden, von der eine kleinere Gruppe oder auch bestimmte Benutzer ausgeschlossen werden.

  • LDAP-Abfragegruppe: Eine von einer LDAP-Abfrage (Lightweight Directory Access Protocol) für die Attribute des Kontos eines bestimmten Active Directory-Benutzers definierte Gruppe. Zum Zeitpunkt des Zugriffs wird die LDAP-Abfrage ausgeführt, um festzustellen, ob der Benutzer ein Mitglied dieser Gruppe ist. Dies ermöglicht eine flexible Gruppenmitgliedschaft, die aufgrund des Active Directory-Kontoobjekts des Benutzers immer aktuell ist. So könnte z.B. eine Gruppe "Manager" eine LDAP-Abfrage enthalten, die alle Benutzer umfasst, die anderen direkt vorgesetzt sind.

Die Einfachheit des Autorisierungs-Managers liegt in seiner Implementierung der rollenbasierten Zugriffssteuerung. Autorisierungsadministratoren entwerfen Rollen als Auflistungen von Aufgaben, die von einer Anwendung unterstützt werden, und weisen dann der Rolle Benutzer und Gruppen zu, um ihnen das Ausführen dieser Aufgaben zu ermöglichen. Anwendungsentwickler verwenden gesicherte logische Objekte, die sowohl im Kontext der Anwendung als auch im Kontext des Sicherheitsverwaltungsmodells sinnvoll sind, wodurch die Anwendungsentwicklung und die Verwaltung vereinfacht werden.

Autorisierungsspeicher

Das objektbasierte Autorisierungsframework verwaltet die Zugriffsrechte in DACLS für die Objekte. Beim rollenbasierten Modell jedoch werden die Sicherheitsinformationen an einem von den Objekten getrennten Ort, nämlich in einem Richtlinienspeicher, verwaltet.

Wenn eine Anwendung, die den Autorisierungs-Manager verwendet, initialisiert wird, werden die Autorisierungsrichtlinieninformationen von einem Speicher geladen. In Windows Server 2003 Enterprise Edition ermöglicht der Autorisierungs-Manager das Speichern der Autorisierungsrichtlinie in Active Directory oder in Dateien im XML-Format. Administratoren im System, das den Autorisierungsrichtlinienspeicher enthält, haben umfassenden Zugriff auf den Speicher, weshalb sich der Autorisierungsrichtlinienspeicher in einem vertrauenswürdigen System befinden muss.

Beim Verwenden des Active Directory-Speichers erstellt der Autorisierungs-Manager Active Directory-Objekte für den Speicher selbst sowie untergeordnete Objekte für alle Anwendungsgruppen, Anwendungen, Vorgänge, Aufgaben, Rollen und Bereiche. Das Bereichsobjekt kann in diesem Bereich erstellte Aufgaben, Rollen und Gruppen enthalten.

Der Autorisierungs-Manager ermöglicht auch das Speichern der Autorisierungsrichtlinie im XML-Format in einer in einem NTFS-Dateisystem gespeicherten Datei (geschützt durch eine ACL). Der XML-Speicher kann sich auf demselben Computer befinden wie ein Autorisierungs-Manager-Server oder kann auch remote gespeichert werden. Zur Unterstützung des Umbenennens von Objekten enthält das XML-Format GUIDs (Globally Unique IDentifiers). Dadurch wird das direkte Bearbeiten der XML-Datei erschwert und nicht unterstützt. Der Speicher kann mithilfe der Autorisierungs-Manager-MMC-Benutzeroberfläche oder über die Schnittstellen des Autorisierungs-Managers, die Skriptingsprachen wie VBScript und Jscript® unterstützen, bearbeitet werden.

Der Anwendungsentwicklungsprozess mit dem Autorisierungs-Manager

Die Integration der rollenbasierten Zugriffssteuerung in einer Anwendung verläuft in der Regel folgendermaßen:

  • Zum Zeitpunkt der Anwendungsentwicklung geben Sie die Rollen an, implementieren Vorgänge und fassen Vorgänge zu Aufgaben zusammen.

  • Zum Zeitpunkt der Installation rufen Sie die entsprechenden APIs für das Erstellen eines Autorisierungsspeichers sowie das Erstellen von Vorgängen und Aufgaben (sowie ggf. einiger anfänglicher Rollen, die für die Anwendung erforderlich sind) auf.

  • Zur Laufzeit initialisiert die Anwendung den Autorisierungs-Manager, um eine Verbindung zum Autorisierungsspeicher herzustellen, und stellt anschließend eine Verbindung zu dem Bereich des Speichers her, der für die Anwendung spezifisch ist.

  • Wenn ein Client eine Verbindung mit Ihrer Anwendung herstellt, wird ein Clientautorisierungskontext erstellt.

  • Sie implementieren das benutzerdefinierte Verhalten gemäß den Rollen. Sie haben nun die Möglichkeit, die Rollen für den entsprechenden Benutzer abzurufen und eine andere Benutzeroberfläche entsprechend dieser Rolle anzuzeigen (so sieht ein "Manager" z.B. etwas anderes als ein "Consultant"). Wenn ein Vorgang durchgeführt wird, wird AccessCheck aufgerufen. Die Rolle, in der sich der Benutzer befindet, wird aufgelistet. Jede Aufgabe für jede Rolle wird überprüft, um festzustellen, ob sich der angeforderte Vorgang daraus ableiten lässt.


Verwenden wir als Beispiel eine einfache Webanwendung, mit der Benutzer Kosten einreichen können. Alle Benutzer dürfen Kosten einreichen. Nach dem Einreichen können die Kosten genehmigt werden, jedoch nur von einem Manager. Wenn Benutzer eine Verbindung mit der Anwendung herstellen, sehen sie den Teil der Oberfläche, der für das Einreichen von Kosten bestimmt ist. Nur Manager können den Teil der Benutzeroberfläche einsehen, der für das Genehmigen von Kosten bestimmt ist.


azmanroles03.gif

Abbildung 3. Beispiel für eine rollenbasierte Zugriffssteuerung: Manager


azmanroles04.gif

Abbildung 4. Beispiel für eine rollenbasierte Zugriffssteuerung: Expense User (Kostenbenutzer)

Identifizieren von Rollen und Aufgaben

Die vorherige Beispielanwendung weist zwei Rollen auf: Expense User (Kostenbenutzer), der Kosten einreichen kann, sowie Manager, der Kosten einreichen und genehmigen kann. Der Rolle Expense User ist die Active Directory-Gruppe Jeder zugewiesen. Die Rolle Manager jedoch besteht aus den LDAP-Gruppen-Managern. Die Gruppe Managers ist durch folgende LDAP-Abfrage definiert:

(title=Manager)

In unserer Beispielanwendung gibt es zwei Vorgänge: submit (einreichen) und approve (genehmigen). Es wird eine Aufgabe erstellt, Submit Expense (Kosten einreichen), die aus dem submit-Vorgang besteht. Es wird eine weitere Aufgabe erstellt, Approve Expense (Kosten genehmigen), die aus dem approve-Vorgang besteht.

Durchführen von Installationsaufgaben

Der Autorisierungs-Manager stellt eine COM-basierte Schnittstelle bereit, die Entwickler während der Installation für die Erstellung eines Autorisierungsspeichers und aller für die Ausführung der Anwendung erforderlichen Anwendungen, Rollen, Aufgaben und Vorgänge verwenden können. Das folgende VBScript kann mit Windows Scripting Host ausgeführt werden, um die Beispielkostenanwendung zu installieren.

'--- Admin-Manager-Objekt initialisieren 
Dim pAzManStore 
Set pAzManStore = CreateObject("AzRoles.AzAuthorizationStore") 
'--- Neuen Speicher für Kostenanwendung erstellen 
' AZ_AZSTORE_FLAG_CREATE   = 0x1, 
' AZ_AZSTORE_FLAG_MANAGE_STORE_ONLY   = 0x2, 
' AZ_AZSTORE_FLAG_BATCH_UPDATE   = 0x4, 
'--- Neuen XML-basierten Speicher für Kostenanwendung erstellen 
pAzManStore.Initialize 1+2, "msxml://C:\JetAzStore.xml" 
'--- Neuen AD-basierten Speicher für Kostenanwendung erstellen 
'pAzManStore.Initialize 1+2, "msldap://CN=MyWebAppsAzStore,CN=Program Data,DC=azroles,DC=com" 
pAzManStore.Submit 
Dim App1 
Set App1 = pAzManStore.CreateApplication("JetExpense") 
App1.Submit 
'--- Vorgänge erstellen ----------------------- 
Dim Op1 
Set Op1=App1.CreateOperation("Submit") 
Op1.OperationID = CLng(55) 
Op1.Submit 
Dim Op2 
Set Op2=App1.CreateOperation("Approve") 
Op2.OperationID = CLng(56) 
Op2.Submit 
'--- Aufgaben erstellen ------------------------------ 
Dim Task2 
Set Task2 = App1.CreateTask("Submit Expense") 
Task2.BizRuleLanguage = CStr("VBScript") 
Task2.AddOperation CStr("Submit") 
Task2.BizRule = "Dim Amount" & vbnewline  & _ 
 "AzBizRuleContext.BusinessRuleResult = FALSE" & vbnewline & _ 
 "Amount = AzBizRuleContext.GetParameter( " & Chr(34) & _ 
   "ExpAmount" & Chr(34) & ")"  & vbNewLine & _ 
 "If Amount < 500 Then AzBizRuleContext.BusinessRuleResult = TRUE" 
Task2.Submit 
Set Task2 = App1.CreateTask("Approve Expense") 
Task2.BizRuleLanguage = CStr("VBScript") 
Task2.AddOperation CStr("Approve") 
Task2.BizRuleImportedPath = "javascript:void(null);" 
Task2.Submit 
'--- Rollendefinitionen erstellen ------------------------------ 
Set Task3 = App1.CreateTask("Expense User") 
Task3.AddTask CStr("Submit Expense") 
Task3.IsRoleDefinition = TRUE 
Task3.Submit 
Set Task3 = App1.CreateTask("Manager") 
Task3.AddTask CStr("Submit Expense") 
Task3.AddTask CStr("Approve Expense") 
Task3.IsRoleDefinition = TRUE 
Task3.Submit 
'--- Anfängliche Bereiche und Rollen erstellen ------------------------------ 
'--- nur ein Bereich in dieser Anwendung (alternativ verwenden wir keinen Bereich) 
Set RoleA=App1.CreateRole("Expense User") 
RoleA.AddTask("Expense User") 
RoleA.Submit 
Set RoleB=App1.CreateRole("Manager") 
RoleB.AddTask("Expense User") 
RoleB.AddTask("Manager") 
RoleB.Submit 
'--- Anwendungsgruppe erstellen -------------------------- 
Set Group1 = App1.CreateApplicationGroup("Managers") 
Group1.Type = 1 
Group1.LdapQuery = "(title=Manager)" 
Group1.Submit 
'--- Demo - jeden zur Rolle Expense User hinzufügen -------------------------- 
RoleA.AddMember("S-1-1-0") 
RoleA.Submit 
'--- Demo - Manager zur Rolle Manager hinzufügen -------------------------- 
RoleB.AddAppMember("Managers") 
RoleB.Submit

Initialisieren des Autorisierungs-Managers und Zugreifen auf den Speicher

Der Autorisierungs-Manager stellt eine COM-basierte Schnittstelle bereit. Die ProgID für das primäre Objekt, den Autorisierungsspeicher, ist Azroles.AzAuthorizationStore. Die Anwendung muss das AzAuthorizationStore-Objekt erstellen und durch Verweisen auf den entsprechenden Autorisierungsspeicher initialisieren.

'--------------- Autorisierungsspeicherobjekt erstellen -------------- 
Set AzManStore = CreateObject("Azroles.AzAuthorizationStore") 
'--------------- Gewünschten Speicher laden -------------- 
AzManStore.Initialize 0, "msxml://C:\JetAzStore.xml"

Die Autorisierung kann auf globaler Ebene im Speicher stattfinden (das heißt Definitionen sind für alle im Speicher definierten Anwendungen verfügbar) oder auf spezifische Anwendungen zugeschnitten sein. Ein Manager in einer Anwendung kann somit über vollkommen andere Rechte als ein Manager in einer anderen Anwendung verfügen. Das Autorisierungsspeicherobjekt kann zum Öffnen der entsprechenden Anwendung verwendet werden.

'--------------- Anwendung öffnen -------------- 
Set App = AzManStore.OpenApplication ("JetExpense")

Initialisieren des Clientkontexts bei Clientverbindungen

Die Anwendung muss anschließend den Clientkontext initialisieren, um eine Verbindung zwischen dem Benutzer und seiner Rolle herzustellen.

'--------------- Clientkontext erstellen -------------- 
Set CCHandle = App.InitializeClientContextFromToken(0, 0)

Implementieren des benutzerdefinierten Verhaltens gemäß den Rollen

Nach der Erstellung eines Clientkontexts haben Anwendungen die Möglichkeit, die Rolleninformationen zum Benutzer abzufragen, um eine rollenbasierte Benutzeroberfläche anzuzeigen. In unserem Beispiel wird der Bereich Approve Expense der Benutzeroberfläche nur für Benutzer der Rolle Manager angezeigt. Die IAzClientContext::GetRoles-Methode listet die Rollenmitgliedschaften des Benutzers auf.

'--------------- Rolle für Benutzer festlegen -------------- 
Manager = False 
Roles = CCHandle.GetRoles() 
For each Role in Roles 
   Response.Write Role 
 If ( StrComp( Role, "Manager", 1 ) = 0 ) Then 
   Manager = True 
   End If 
Next 
Set CCHandle = Nothing 
set App = Nothing 
Set AzManStore = Nothing

Wenn ein Client eine Anforderung ausgibt oder ein anderes Ereignis das Ausführen einer Aufgabe durch die Anwendung auslöst, muss die Anwendung zunächst feststellen, ob die Ausführung der Aufgabe autorisiert ist. Zu diesem Zweck wird IAzClientContext::AccessCheck aufgerufen. Ist der Zugriff autorisiert, gibt AccessCheck Null zurück.

Names(0) = "ExpAmount" 
Values(0) = 0 
Names(1) = "Param2 for BizRule - Name" 
Values(1) = "Param2 for BizRule - value" 
Scopes(0) = Empty 
Operations(0) = 55 
'-------- AccessCheck ----------------------------------------- 
' Überprüfen, ob der aktuelle Benutzer Kosten entsprechend den an  
' AccessCheck übergebenen Parametern einreichen darf (in unserem Fall nur Kostenbetrag 
' und durchzuführender Vorgang) 
Results = CCHandle.AccessCheck("Submit Expense", Scopes, Operations, Names, Values) 
If Results(0) = 0 Then ' Zero = NO_ERROR 
   Result = "accepted." 
Else 
   Result = "denied." 
End If

Schlussfolgerung

Die rollenbasierte Zugriffssteuerung in Windows Server 2003 Enterprise Server bietet ein vereinfachtes Entwicklungsmodell für Geschäftsanwendungen. Sowohl Administratoren als auch Entwickler können von dem natürlichen Framework profitieren, das ihnen ermöglicht, Organisationsstrukturen und Geschäftsprozesse effizient zu modellieren.


Anzeigen: