Das Fehlen von anwendungsspezifischen Active-Directory-Gruppen bei der Einrichtung von Berechtigungen auf OLAP-Datenbanken endet oft in der unübersichtlichen Zuordnung einzelner Benutzer zu Datenbankrollen. Dieser Beitrag beschreibt einen Ansatz, wie anstelle von AD-Gruppen die im Repository gepflegten Zuordnungen für dynamische OLAP-Berechtigungen genutzt werden können. Dafür ist die Modellierung einer Benutzerdimension und einer zusätzlichen Kennzahlengruppe im Datenmodell notwendig. Die neue Kennzahlengruppe kann dann in OLAP-Rollen genutzt werden, um zu unterscheiden, welcher Anwendergruppe ein Benutzer zugeordnet wurde.
Ausgangslage
Berechtigungen auf Microsofts Analysis-Services-Datenbanken lassen sich hervorragend über das Berechtigungskonzept abbilden, das in den Analysis Services bereitgestellt wird. Die Unterscheidung, welche Berechtigungen für welchen Benutzer gelten, werden meist über Active-Directory-Gruppen (AD-Gruppen) zugewiesen, um eine unübersichtliche Zuordnung von einzelnen Benutzern auf den Datenbankservern zu vermeiden. Jedoch stehen aus unterschiedlichen Gründen nicht immer anwendungsspezifische AD-Gruppen zur Verfügung.
Dieser Blog beschreibt die Möglichkeit, Anwendergruppen aus DeltaMaster Repository so im Datenmodell einzubinden, dass diese als Ersatz für AD-Gruppen fungieren können. Dazu wird zunächst eine fiktive Problemstellung beschrieben und anschließend sowohl die relationale als auch die OLAP-Modellierung skizziert. Abschließend wird beschrieben, wie Erweiterungen vorgenommen werden können und wo mögliche Stolpersteine liegen.
Problemstellung
Zur Veranschaulichung wird ein fiktives Szenario für eine Reporting-Anwendung in DeltaMaster angenommen. Auf die Anwendung sollen die folgenden Gruppen mit entsprechenden Einschränkungen zugreifen können:
| Gruppe | Berechtigung |
| Administratoren | Keine Einschränkung |
| Vertretergruppe Luxus | Dürfen nur Auswertungen für Luxusmodelle sehen |
| Vertretergruppe Sonstige | Dürfen nur Auswertungen für Sonder- und Standardmodelle sehen |
Es wird nur eine AD-Gruppe bereitgestellt, welche den generellen Zugriff auf die Datenbank ermöglichen soll.
Beim Datenmodell handelt es sich um das Vertriebsreporting der Chair AG, einem fiktiven Stühlehersteller.
Die Berechtigungspflege
Die hier beschriebene Lösung basiert auf den Tabellen des Repository in DeltaMaster. Eine vorhandene Installation ist also zwingend notwendig. Anschließend können die in der Problemstellung beschriebenen Rollen angelegt werden.
Nach dem Anlegen der Benutzergruppen werden die einzelnen Benutzer der Anwendung im Repository ihrer jeweiligen Gruppe zugeordnet. Dies ist die einzige Stelle bei diesem Ansatz, bei dem einzelne Benutzer zugeordnet werden müssen.
Abbildung 1: Erstellen der Repository-Gruppen
Modellierung
Um die dynamischen OLAP-Berechtigungen in DeltaMaster Repository zu nutzen, muss eine Benutzerdimension und eine zusätzliche Kennzahlengruppe modelliert werden. Diese Modellierung wird sowohl im relationalen Modell, als auch im OLAP-Modell vorgenommen.
Relationales Modell
Damit das zugrundeliegende Datenmodell später weiß, welcher Benutzer welcher Gruppe zugeordnet wird, wird für diesen Zweck eine eigene Kennzahlengruppe angelegt. Wenn das Datenmodell bisher noch nicht über eine Benutzerdimension verfügt, so muss auch diese angelegt werden. Die Kennzahlengruppe verfügt dann über ein Flag je Anwendergruppe, welches jeweils eine 1 ausgibt, wenn der Benutzer zugeordnet ist, bzw. eine 0, wenn keine Zuordnung existiert. Das SQL für die Benutzerdimension kann wie folgt aussehen und mit ein paar String-Operationen komplett aus dem Repository aufgebaut werden:
CREATE VIEW [dbo].[V_Import_DIM_Benutzer] AS
SELECT DISTINCT
CONCAT('Domäne\', x1.Member) AS BenutzerID
,x1.MemberName AS BenutzerName
--select *
FROM Member m
LEFT JOIN Role_Member rm
ON m.MemberID = rm.MemberID
--Domäne auflösen
CROSS APPLY (
SELECT
SUBSTRING(
m.MemberName
, CHARINDEX('(', m.MemberName, 1) + 1
,(CHARINDEX('@', m.MemberName, 1)-CHARINDEX('(', m.MemberName, 1)-1)
) AS Member
,SUBSTRING(m.MemberName, 0,CHARINDEX('(', m.MemberName)) AS MemberName
) x1Die Verweise auf die Repository-Tabellen „Member“ (Tabelle mit den angelegten Benutzern) und „Role_Member“ (Tabelle mit der Zuordnung der Benutzer zu den Rollen) sind in diesem Beispiel als Datenbanksynonyme angelegt worden und verweisen auf die DeltaMaster-Repository-Datenbank.
Da in den meisten Fällen nur eine Domäne verwendet wird, kann diese der Einfachheit halber im SQL statisch angegeben werden, so wie es auch im Beispiel gemacht wurde.
Auch für die relationale Aufbereitung der neuen Kennzahlengruppe kann auf das Repository verwiesen werden:
CREATE VIEW [dbo].[V_Import_FACT_Rechte_Anwendergruppe] AS
SELECT DISTINCT
CONCAT('Domäne\', x1.Member) AS BenutzerID
, IIF(rmAdmin.RoleID IS NULL, NULL, 1) AS Flag_Admin
, IIF(rmLuxus.RoleID IS NULL, NULL, 1) AS Flag_Vertrieb_Luxus
, IIF(rmSonstige.RoleID IS NULL, NULL, 1) AS Flag_Vertrieb_Sonstige
FROM Member m
--Admin
LEFT JOIN Role_Member rmAdmin
ON m.MemberID = rmAdmin.MemberID AND rmAdmin.RoleID = 1
--Vertrieb Luxus
LEFT JOIN Role_Member rmLuxus
ON m.MemberID = rmLuxus.MemberID AND rmLuxus.RoleID = 2
--Vertrieb Sonstige
LEFT JOIN Role_Member rmSonstige
ON m.MemberID = rmSonstige.MemberID AND rmSonstige.RoleID = 3
--Domäne auflösen
CROSS APPLY (
SELECT
SUBSTRING(m.MemberName, CHARINDEX('(', m.MemberName, 1) + 1, (CHARINDEX('@', m.MemberName, 1)-CHARINDEX('(', m.MemberName, 1)-1) ) AS Member
) x1Die einzelnen Joins lesen über die entsprechende ID einer Rolle aus, ob eine Benutzer-ID dieser Rolle zugeordnet ist.
OLAP-Modell
Nach der Anlage im relationalen Modell müssen die Dimension und die Kennzahlengruppe in DeltaMaster ETL angelegt und verknüpft werden.
Abbildung 2: Einzige Ebene der neuen Benutzerdimension
Abbildung 3: Neue Kennzahlengruppe
Abbildung 4: Zuordnung der Benutzerdimension zur neuen Kennzahlengruppe
Abbildung 5: Neu angelegte Kennzahlen
OLAP-Berechtigungen
Im Anschluss an die Aufbereitung des angepassten Datenmodells können die OLAP-Berechtigungen eingerichtet werden. Da nur eine AD-Gruppe zur Verfügung steht, welcher alle Anwender zugeordnet sind, kann analog auch nur eine OLAP-Rolle für die Datenbank angelegt werden:
Abbildung 6: Neue OLAP-Rolle
Dieser Rolle ist anschließend die vorhandene AD-Gruppe zuzuordnen.
Unter Dimensionsdaten muss für die Dimension „Produkt“ die entsprechende MDX-Abfrage hinterlegt werden:
CASE WHEN
--Admin-User
(StrToMember('[Benutzer].[Benutzer].[Benutzer].&['+USERNAME()+']'),[Measures].[Flag_Admin])>0
--Dann darf alles eingesehen werden
THEN {[Produkt].[ProdukthauptgruppeID].Members}
--Vertrieb für Luxusmodelle
WHEN ( StrToMember('[Benutzer].[Benutzer].[Benutzer].&['+USERNAME()+']'),[Measures].[Flag_Vertrieb_Luxus])>0
--Dann nur Produkthauptgruppe 1 (Luxusmodelle)
THEN [Produkt].[ProdukthauptgruppeID].&[1]
--Vertrieb für Sonstige Modelle
WHEN ( StrToMember('[Benutzer].[Benutzer].[Benutzer].&['+USERNAME()+']'),[Measures].[Flag_Vertrieb_Sonstige])>0
--Dann nur Produkhauptgruppe 2 und 3
THEN {[Produkt].[ProdukthauptgruppeID].&[2], [Pro-dukt].[ProdukthauptgruppeID].&[3]}
--Ansonsten Zugriff verweigern
ELSE {}
ENDMittels CASE-Anweisung kann dann je Anwendergruppe entschieden werden, welcher Ausschnitt der Dimensionsdaten angezeigt wird. Über den ELSE-Teil wird sichergestellt, dass ein Anwender, der gar keine Berechtigungen über das Repository erhalten hat, im Zweifel gar keine Daten sehen kann.
Abbildung 7: Konfiguration der Rolle „DeltaMaster_User“
Erweiterungen
Die hier beschriebene Lösung kann unkompliziert erweitert werden, wenn neue Anwendergruppen notwendig werden. Für diese muss lediglich ein neues Flag angelegt und die Logik im CASE-Statement der OLAP-Rolle erweitert werden.
Besonderheiten
Bei der hier beschriebenen Lösung gibt es zwei mögliche Stolpersteine, die zu beachten sind:
1. Verweigerungen nicht vergessen
Wenn mehrere Cubes oder OLAP-Datenbanken existieren, bei denen der Zugriff immer über dieselbe AD-Gruppe ermöglicht wird, ergeben sich spezielle Anforderungen für Dimensionen mit sensiblen Daten. Ein Beispiel kann eine Mitarbeiterdimension sein, die personenbezogene Daten enthält. Um sicherzugehen, dass diese nur von Anwendern eingesehen werden können, welche auch im Repository der Anwendung zugeordnet sind, empfiehlt sich für solche Dimensionen eine Berechtigung, die Einsicht in diese Daten vollständig gewährt oder verweigert:
IIF(
(StrToMember('[Benutzer].[Benutzer].[Benutzer].&['+USERNAME()+']')
,[Measures].[Flag_DarfDatenSehen]) >0
,[Mitarbeiter].[MitarbeiterID].Members
,{}
)2. IDs beachten
Sollte es in der Systemarchitektur für eine Test- und Produktivumgebung jeweils ein Repository geben, sind vor der Durchführung von Änderungen und der Produktivsetzung die IDs der Rollen zu überprüfen. Die beiden hier beschriebenen Views verweisen explizit auf entsprechende IDs, welche in unterschiedlichen Systemumgebungen abweichen können.
Zusammenfassung
Die in diesem Blog beschriebene Lösung ist eine passende Alternative, wenn die Erstellung mehrerer AD-Gruppen aus unterschiedlichen Gründen nicht möglich ist. Die Zuordnung von Benutzern zu Gruppen erfolgt dann stattdessen in DeltaMaster Repository. Zum Berechtigen eines Anwenders sind also zwei Schritte notwendig: Die Zuordnung zur zentralen AD-Gruppe für den allgemeinen DeltaMaster-Zugriff (wenn nicht ohnehin schon vorhanden) und die Zuordnung in DeltaMaster Repository.
