CiAgICA8IS0tIExpbmtlZEluIC0tPgogICAgPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPgogICAgICAgIF9saW5rZWRpbl9wYXJ0bmVyX2lkID0gIjEyMzUwNzMiOwogICAgICAgIHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyA9IHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyB8fCBbXTsKICAgICAgICB3aW5kb3cuX2xpbmtlZGluX2RhdGFfcGFydG5lcl9pZHMucHVzaChfbGlua2VkaW5fcGFydG5lcl9pZCk7CiAgICA8L3NjcmlwdD48c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CiAgICAgICAgKGZ1bmN0aW9uKCl7dmFyIHMgPSBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic2NyaXB0IilbMF07CiAgICAgICAgICAgIHZhciBiID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7CiAgICAgICAgICAgIGIudHlwZSA9ICJ0ZXh0L2phdmFzY3JpcHQiO2IuYXN5bmMgPSB0cnVlOwogICAgICAgICAgICBiLnNyYyA9ICJodHRwczovL3NuYXAubGljZG4uY29tL2xpLmxtcy1hbmFseXRpY3MvaW5zaWdodC5taW4uanMiOwogICAgICAgICAgICBzLnBhcmVudE5vZGUuaW5zZXJ0QmVmb3JlKGIsIHMpO30pKCk7CiAgICA8L3NjcmlwdD4KICAgIDxub3NjcmlwdD4KICAgICAgICA8aW1nIGhlaWdodD0iMSIgd2lkdGg9IjEiIHN0eWxlPSJkaXNwbGF5Om5vbmU7IiBhbHQ9IiIgc3JjPSJodHRwczovL3B4LmFkcy5saW5rZWRpbi5jb20vY29sbGVjdC8/cGlkPTEyMzUwNzMmZm10PWdpZiIgLz4KICAgIDwvbm9zY3JpcHQ+CiAgICA8IS0tIEVuZCBMaW5rZWRJbiAtLT4KICAgIA==
Generic filters
Exact matches only
Search in title
Search in excerpt
Search in content

OLAP-Berechtigungen ohne anwendungs-
spezifische AD-Gruppen

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.

Erstellen der Repository-Gruppen für OLAP-Berechtigungen ohne anwendungsspezifische AD-Gruppen im DeltaMaster Repository

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

) x1

Die 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
) x1

Die 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.

Einzige Ebene der neuen Benutzerdimension in DeltaMaster ETL

Abbildung 2: Einzige Ebene der neuen Benutzerdimension

 

Neue Kennzahlengruppe in DeltaMaster ETL

Abbildung 3: Neue Kennzahlengruppe

 

Zuordnung der Benutzerdimension zur neuen Kennzahlengruppe in DeltaMaster ETL

Abbildung 4: Zuordnung der Benutzerdimension zur neuen Kennzahlengruppe

 

Neu angelegte Kennzahlen in DeltaMaster ETL

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:

Neue OLAP-Rolle für die Datenbank zur für OLAP-Berechtigungen ohne anwendungsspezifische AD-Gruppen

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 {}
END

Mittels 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.

Konfiguration der Rolle "DeltaMaster User" für OLAP-Berechtigungen ohne anwendungsspezifische AD-Gruppen

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.