Yleinen kuvaus

Analysis Services sallii minkä tahansa MDX lauseen käytön autentikointiin dimensioissa.
Näin, voidaan mallintaa tietoturvaa kuutioihin tallennetun datan mukaan.
Esimerkiksi, MDX kaavalla voidaan sallia käyttäjälle näkyväksi informaatio kaupan myymälässä jossa hän työskentelee, mutta ei muista kaupan myymälöistä. Tällainen skenaario ei kuitenkaan sovellu hyvin roolipohjaiseen tietoturvaan, koska jouduttaisiin luomaan henkilökohtainen rooli jokaiselle järjestelmän käyttäjälle. Siinä tapauksessa voidaan luoda dataan pohjautuva järjestelmä – eli dynaaminen autentikointi.

Dynaamisen autentikoinnin avulla voidaan toteuttaa yksi rooli kaikkia käyttäjiä varten ja jolla sitten UserName MDX funktiota tietoturvamäärityksissä roolin räätälöinnissä jokaiselle käyttäjälle erikseen.
Kun käytetään laajaa ja monimutkaista yhdistelmää tietoturva asetuksissa (autentikoinnit), tämä tekniikka on suositeltava sen takia että sillä voidaan toteuttaa helpommin ja yksinkertaisemmin ylläpidettävä järjestelmä verrattuna muihin toteutustapoihin.  Kun uusi käyttäjä tai uusia käyttäjiä lisätään järjestelmää, olemassa olevaa roolia muutetaan sopivaksi – automaattisesti.
Funktio, UserName palauttaa stringin (tekstityyppinen muuttuja) joka sisältää ko. käyttäjän domain nimen ja käyttäjätunnuksen (domain\Username) Windows AD tai local username tietojen mukaisesti Analysis Services loginia varten. Tällä tavalla voidaan verrata MDX funktion palauttamaa arvoa kannassa olevaan tietoon organisaation käyttäjistä (epmloyees/työntekijät/resurssit).

Esimerkki

On eri mahdollisuuksia yhdistellä UserName funktion palauttamat arvot kuution jäsenten kanssa (members). Suoraviivaisempia tapoja on lisätä sarake käyttäjätunnuksille ja käyttäjien nimille sekä rakentaa ulottuvuus attribuutti (dimensio) siitä. Esimerkiksi jos lisään user_name sarakkeen dbo.employee tauluun testikannassa – saadaan silloin tehtyä myös uusi attribuutti Employee dimension kuutiossa. Avain kenttä saa arvon employee_id : stä ja UserName kentästä myyjä_nimi tai Employee login nimeä vastaavan arvon.

Esimerkkinä tein uuden roolin nimeltä DynamicRole ja lisäsin siihen kaikki käytäjät – tässä on syytä kokeilla myös muillakin ryhmillä kun ‘Everyone’ Esimerkiksi Laajatoikeudenhaltijat ja suppeatoikeudenhaltijat – ryhmät tms. Lisäksi käytän kuutiota Sales and Employees. Tässä kuutiossa on measure ryhmä (measuregroup) niin kuin Warehouse ja Sales kuutiossakin, mutta siinä on lisäksi Employee dimensio johon on laitettu vielä granulariteetti Storen- tiedon mukaan (Employee ja store id). Nyt voin käyttää User Name ja Employee attribuuttia kohdistamaan kuution käyttäjän nimen mukaan. Voin myös asettaa storet näkymään vain niin, että sen storen työntekijät näkevät vain ne – eivätkä muita. On myös mahdollista asettaa käyttäjiä (employees) niin että useita storeja tulee tietyille käyttäjille (employees) tai tehdä näistä vaihtoehdoista johdettuja yhdistelmiä.

Eri vaihtoehdoista on tässä esimerkki, niin että vain oma store tulee näkyville. Seuraavassa MDX funktio AllowedSet ominaisuuden muutos Store cube dimensiossa:

Filter(
[ Store] . [Store] . [ Store]. members,
[ Store] . [Store] . currentmember.properties( “key”) =
Exists(
[ Employee] .[ Store]. [ Store] . members,
StrToMemeber ( “Employee. [ “+UserName() +” ]”, CONSTRAINED)
). Item( 0) . Properties( “key”) )

Tässä käytän StrToMember MDX funktiota hakemaan Employee jäsenen (Employee member) attribuutti hierarkiasta UserName attribuutin ja yhdistämään vastaavat UserName tiedot MDX funktion palauttamasta tiedosta. Tämä edellyttää että store id löytyy myös employee ulottuvuudesta joten nämä ulottuvuudet voidaan liittää toisiinsa (vrt. Relaatiokannan join)

Ja nyt, kun autentikointi on määritetty dynaamisesti, voidaan todeta kuutiossa sama selaamalla Dynamic Role ryhmän käyttäjällä – että data on filtteroitu vain kyseessä olevan käyttäjän ‘store’n mukaan ja muut tiedot eivät ole näkyvissä.

Esimerkiksi alla olevassa kuvassa on dataa vain Meksikon store numero 12 ta, koska Irina
Gorbach (käytetty login) sattuu olemaan tämän storen työntekijä.

General asetukset

Membership asetukset

Data Sources asetukset

Cubes asetukset

Cell Data asetukset

Dimensions asetukset

Dimension data asetukset ja MDX

NonEmpty( [Store].[Store].[Store].members,

Exists(
[Employee].[Store].[Store].members,
{LinkMember([Employee].[User Name].[User Name].members("["+UserName()+"]"),[Employee].[Employees])}
)*[Measures].[Store Sales]
)

Kun dimensioiden tietoturva-asetuksen on määritelty dynaamiseksi, on näkyvissä vain ja ainoastaan se data joka liittyy sinun omalle tunnukselle.

Dimensio tietoturva-arkkitehtuuri

Käyttäjä joka hakee dataa analysis serviceltä voi kuulua useisiin eri rooleihin. Tämän takia Analysis services tutkii dimensio oikeudet jokaiselle käyttäjän roolille. Jos järjestelmässä on useita tietoturva rooleja määritettynä, kasvattaa se eri yhdistelmien kokoa huomattavastikkiin. Analysis services pitää sisällään hyvin skaalautuvan mekanismin joka mahdollistaa jopa isojenkin dimensioiden nopean tietoturvan soveltamisen/tutkimisen. Analysis services ei luo, ja lataa muistiinsa dimensioiden kopiota sallittuine attribuutteineen, vaan sen sijaan pitää muistissaan pienen rakenteen datasta nimeltä CubeAttributeSecurity. Tämä datarakenne on liittymä Analysis services kantaan toteuttamaan ilmentymän sallittujen tai kiellettyjen jäsenten näkyvyyden. Tämän datarakenteen fyysinen esittäminen riippuu monista tekijöistä.  Joissakin tapauksissa Analysis services käyttää bittikartta tietoja pakatussa muodossa ja voi verrata tai ‘vähentää’ halutusta joukosta sallittuja tai kiellettyjä jäseniä. Joissakin tapauksissa on taas luotava materialisoitu bittikartta kuvaamaan bittitasolla eri attribuutteja. Pahimmassakin tapauksessa tarvitaan vain materialisoida bittikartta, dimensioiden tietoturva-asetusten käyttämä bittimäärä ei voi olla enempää kun dimension jäsenten määrä jaettuna kahdeksalla. “CubeAttributeSecurity” on tiedostoluokka ja sitä voidaan käyttää ja säilöä muistissa ja levyllä dynaamisesti, sen mukaan miten muistinhallintalogiikka päättää. Jos käyttää useita tietoturvarooleja, AS iteroi “CubeAttributeSecurity” tietoja jokaisella roolilla ja käyttää loogisia operaattoreita asetusten ja rakenteen mukaisesti. Tämä tekniikka tekee operaatiosta erittäin nopean yksinkertaisuutensa takia..

Dimensio tietoturva, solujen tietoturva ja  MDX Skriptit

Analysis Services asettaa dimensiotietoturvan ennen MDX skriptin tarkistusta/suoritusta, ja asettaa solukohtaisen tietoturvan MDX skriptin tarkistuksen/suorituksen jälkeen.

Se, että tämä on mahdollistaa, vaatii Analysis servicen iteroimaan läpi kaikki AttribuuttiPermissions objektit, tarkistaa MDX funktiot ja niiden sallitus ja kielletyt  asetukset (Allowed & DeniedSets) jokaisen aktiivisen roolin osalta ja rakentaa CubeAttributeSecurity datarakenteet. Tämän jälkeen Analysis Services tarkistaa oletus jäsen ominaisuudet AttributePermission objektin MDX funktioiden osalta. Jos useammalla kun yhdellä roolilla on default member määritettynä, ensinmäisen roolin default member ‘voittaa’. Jos ei ole mahdollista päätellä mikä rooli pätee ensimmäisenä, Analysis services ottaa käyttöön dimensio tietoturvan. Siitä lähtien, kaikki operaatiot suoritetaan suojattuina. Jos dimensio tietoturva-asetuksen rajoittavat jotakin default jäsentä, järjestelmä ei pysty käyttämään jatkotoimenpiteissä. Se vuoksi Analysis Services muuttaa default jäsenet default jäseniksi, joilla on rajoitteita. Tavallisesti, jos attribuutti on aggregoitavissa, se on ALL jäsen. Muussa tapauksessa ylimmäisenä oleva jäsen voi tulla default jäseneksi.   
Analysis Services ottaa käyttöön kaikki kelvolliset ‘visual totals’ mahdollisuudet ja lopulta arviot MDX skriptin.
Sen jälkeen Analysis Services arvio ja tarkistaa skriptin ja lisää sen global scope muistiin