Sans faire tout un article sur la sécurité dans Analysis Services, je vais traiter d’un point de détail suite à la question d’un client.

La problématique (simplifiée) est la suivante : sur un  cube avec un nombre important d’utilisateurs, presque chacun doit seulement avoir accès un une partie des données.

La répartition des droits se fait simplement en sliçant (aucun rapport avec le tennis ) sur les valeurs d’une dimension.
Prenons comme exemple la dimension produit du cube Adventure Works. Imaginons que chaque utilisateur doit voir SA catégorie (et uniquement celle-là).

Comment implémenter la sécurité ?

Déjà, restons sur du natif en nous appuyant sur la sécurité SSAS à savoir les rôles. Deux approches viennent à l’esprit.

• créer un Role par utilisateur – et affecter les bons membres de la dimension
• créer un Role par catégorie – et affecter les utilisateurs

La difficulté est que la cardinalité de la dimension et le nombre d’utilisateurs sont équivalents, ce qui ne milite ni pour l’un ni pour l’autre des choix.

Pourtant, connaitre comment Analysis Services résout les permissions va nous orienter vers une solution.
Que se passe t-il quand un utilisateur est dans plusieurs Roles ?

• son contexte de sécurité contient les différents rôles
• la requête est exécutée pour les différents rôles du contexte d’exécution
• les différents résultats sont fusionnés

Attention, la fusion des résultats est vraiment une UNION et ne tient pas compte des DENY qu’il pourrait y avoir, contrairement au SQL. Ce point nous montre que dans le cas de rôles par catégorie, l’implémentation d’exceptions sera difficile (et on se doute bien qu’il y en aura ).

Toutefois, ce n’est pas ce point précis qui me fait choisir la première solution. Lorsqu’un utilisateur est dans plusieurs rôles, la requête est “exécutée” pour chaque rôle et la fusion des CellSet se fait après. Ces opérations sont plus couteuses que de connaitre dès le départ les droits et interdiction de l’utilisateur courant.

Je créerai donc un Role par utilisateur.

Evidemment, j’ai dit qu’il y avait un grand nombre d’utilisateurs (2000 dans mon cas), ce qui entraîne une maintenance complexe.

Je vous rassure tout de suite, pour maintenir tout cela, la configuration des rôles passera par du code .NET (ou Powershell) afin de donner aux administrateurs une interface plus ergonomique (moins vrai en Powershell ).

using Microsoft.AnalysisServices;
/* ... */
Server s = new Server();
s.Connect("data source=caolila;integrated security=SSPI");
Database d = s.Databases["AW"];

Role r = d.Roles.Add("Cat_User1234");
r.Members.Add(new RoleMember("CAOLILA\\User1234"));

CubePermission cubePermission = d.Cubes["Sales"].CubePermissions.Add(r.ID);
cubePermission.Read = ReadAccess.Allowed;
Dimension dim = d.Dimensions.GetByName("Product");
DimensionAttribute attribute = dim.Attributes.GetByName("Category");
CubeDimensionPermission cubedimPermission = cubePermission.DimensionPermissions.Add(dim.ID);
cubedimPermission.Read = ReadAccess.Allowed;
AttributePermission attributePermission = cubedimPermission.AttributePermissions.Add(attribute.ID);
attributePermission.AllowedSet = "{[Product].[Category].&[1]}";
cubePermission.Update();

PS : comme d’habitude en matière de sécurité, la complexité n’est pas la solution technique mais les processus d’attribution des droits que l’on met en place dans les applicatifs.
Simplifier les règles peut souvent éviter de monter des usines à gaz. Je recommande souvent de calquer sur des modèles de la vie réelle, même si nos systèmes d’information n’ont souvent pas de limite. (tips : appuyez vous sur les UO ou les groupes de l’Active Directory)

UPDATE: Benny Austin vient juste de publier un article bourré de code AMO pour piloter la sécurité SSAS. C’est ici : ssas-using-amo-to-secure-analysis-service-cube