Vorgehensschritte am Beispiel Adventure Works

Voraussetzung zur Erprobung der dynamischen Security ist ein Windows-Benutzername (Domäne\Name) und ein äquivalenter Namenseintrag  in der betreffenden Dimension. Dafür wird im Folgenden eine zusätzliche Spalte RealAccount in der DIM Employee erzeugt (VPCPLAYIMAGE\Benutzername), welche den Benutzernamen enthalten soll. Der Name ergibt sich hierbei aus der E-Mailadresse (aus AW) und muss dem Windows-Anmeldenamen entsprechen.

MS Visual Studio à AdventureWorks à AdventureWorks.dsv à DimEmployee (Kontextmenü)à benannte Abfrage ändern: SELECT ergänzen um Spalte:

‘VPCPLAYIMAGE\’ + LEFT(EmailAddress,PATINDEX(‘%@%’, EmailAddress) – 1) AS RealAccount

In Windows soll nun der Beispielnutzer VPCPLAYIMAGE\amy0 angelegt werden, welcher auch in AW zu finden ist (Windows Computerverwaltung).

Im nächsten Schritt soll eine neue Rolle namens DynamicEmployees angelegt werden, in welcher für den neuen RealAccount Attributsicherheit definiert wird.

Rollen(Kontextmenü) à Neue Rolle: DynamicEmployees à Reiter: Mitgliedschaften à amy0 hinzufügen

Im ersten Schritt soll die Attributsicherheit durch das dynamische Eintragen des Benutzernamens mittels der Username-Funktion als zulässige Elementgruppe wie folgt realisiert werden:

Rolle: DynamicEmployeeà Reiter: Dimensionsdaten à Dimension: AdventureWorks DW.Employee à Attributhierarchie: RealAccount à Reiter: Erweitertà Zulässige Elementgruppe

STRTOSET(“{[Employee].[Real Account].&[" + UserName() + "]}”)

Eine mögliche Erweiterung des vorigen Statements durch einen UnknownUser ist empfohlen, um bei Nichterkennen des Benutzernamens aus Sicherheitsgründen einen Nutzer ohne Rechte zu haben. Dieser Nutzer muss dementsprechend zuvor auch in AW angelegt werden (VPCPLAYIMAGE\UnknownUser). Die zugehörige Erweiterung lautet:

IIF(FILTER([Employee].[Real Account].MEMBERS,[Employee].[Real Account].MEMBER_NAME UCASE(UserName())).COUNT=0,STRTOMEMBER(“[Employee].[Real Account]. &[VPCPLAYIMAGE\UnknownUser]“),STRTOMEMBER(“[Employee].[Real Account].[" + UserName() + "]“))

Bei Verwendung des MS SQL-Management Studios oder des MS Analysis Services internen Browsers wird nun bei Anmeldung durch einen Testnutzer (hier:  VPCPLAYIMAGE\amy0) wie gewünscht der Nutzername und die Daten wie bspw. der Reseller Sales Amount nur für amy0 und Personen höherer Hierarchie herausgegeben, wenngleich dieser für alle Employees abgefragt wurde.

SELECT [Measures].[Reseller Sales Amount] ON COLUMNS,[Employee].[Employee].MEMBERS ON ROWS FROM [Adventure Works]

Anpassungen bei Zugriff durch MS Excel Frontend

Beim Zugriff auf den Cube mittels Excel gibt es hingegen nun ohne die Durchführung weiterer Maßnahmen ein Zugriffsproblem auf Namensebene. Bei der MS Excel-Variante besteht kein Zugriff auf die Parents und es wird somit ein Fehler hervorgerufen. Das Problem ist, dass MS Excel sich die kompletten Properties einschließlich der Employees Parent-Child-Beziehung holt, worauf der Nutzer keinen Zugriff hat. Somit wird im Unterschied zum Zugriff ohne MS Excel standardmäßig kein Zugriff auf Employees gewährt. Die Fehlermeldung lautet: „Die Abfrage oder das Öffnen der Tabelle konnte nicht durchgeführt werden. [..]“. Um die Mitgabe der Properties zu vermeiden, kann dieses unter MS Excel wie folgt durchgeführt werden:

MS Excel à Daten: Verbindung mit Cube herstellen à Optionen: Optionen à Anzeige à Kontextbezogene Quickinfos anzeigen (nein), Eigenschaften in Quickinfos anzeigen (nein)

Somit sind die Properties ausgeschaltet und mittels MS Excel kann nun auch Zugriff auf Employees und die Daten des entsprechenden Nutzers gewährt werden.

Anhand dieser Vorgehensweise soll es möglich sein, mit einfachen Mitteln eine dynamische Security zu realisieren ohne einen gewaltigen Pflegeaufwand auf Nutzerebene hervorzurufen.