Jedan od razloga uspjeha Microsoft SharePoint Servera je zasigurno jako dobro razrađen koncept sigurnosti koji on nudi. Iako je sigurnost oduvijek bila tema u poslovnim aplikacijama, ona se uglavnom svodila administratorsko dodjeljivanje prava određenim korisnicima, ili u boljem slučaju korisničkim grupama.

Zahtjev za dodjelom određenih prava pojedinom korisniku je, shodno tome, morao ići do vrha administrativne piramide. Dodjelu prava, u takvom slučaju, čak i kada je promjena prava minimalna i dešava se na najnižem nivou, administratorima mora da odobri neko iz uprave.

Posljedica svega je dugotrajan i često naporan proces dodjele i promjene prava, koji korisnici najčešće pokušavaju da izbjegnu. Korisnici traže druge načine kako da riješe određeni problem, što neminovno dovodi do zastoja i problema u funkcioniranju cijele aplikacije.

SharePoint je vrlo demokratičan alat, a njegova hijerarhijski organizirana struktura daje mogućnosti korisnicima da pitanja pristupa i prava rješavaju unutar manjih timova, prilagođenih zadacima za koje su određeni i potrebnom nivou prava. Pojednostavljeno, ukoliko je nova kolegica stigla u tim, i potrebno joj je dodijeliti određena prava na zajedničke dokumente i procese koji se koriste unutar tima, ta prava ne mora dodijeliti glavni administrator unutar firme  - ukoliko se koncept ispravno postavi, dovoljan je direktni pretpostavljeni, ili čak kolega.

Ovaj članak će pokušati dati objašnjenja, smjernice i pravce, na koji način funkcionira koncept prava u SharePointu, na šta moramo obratiti pažnju, i gdje se mogu pojaviti eventualni problemi.
 

Securable Objects
 

U SharePointu, od njegovih početaka, imamo koncept nivoa objekata nad kojima možemo postaviti određene sigurnosne postavke. Riječ je o konceptu securable objects, "objekti koje možemo osigurati", i čija hijerarhija u potpunosti prati hijerarhiju koju SharePoint koristi za smještanje informacija.

SharePoint Site Collection je osnovna "vododijelnica" u postavljanju sigurnosnih koncepata u SharePointu. To znači da objekti unutar jedne SharePoint Site Collection mogu nasljeđivati i dijeliti koncepte sigurnosti, a objekti koji su smješteni u različitim kolekcijama moraju neminovno imati potpuno različite sigurnosne postavke.

Ovdje je svo vrijeme riječ o "objektima" - radi se, zapravo, o istim onim entitetima koji se koriste za organizaciju podataka: sajt (SharePoint Site), SharePoint liste (ili biblioteke - Document Library), folderi, i elementi (List Itemi u listama ili Dokumenti u bibliotekama). I to upravo tim hijerarhijskim redom:

U prethodnom dijagramu, u uokvirenom dijelu vidimo ove objekte kojima možemo odrediti nivoe sigurnosti. Linije između njih ukazuju da se sigurnosne postavke standardno nasljeđuju između objekata koji imaju direktnu roditeljsku vezu: jedan SharePoint Site nasljeđuje sve postavke sigurnosti od "roditeljskog" SharePoint Sitea, SharePoint liste i biblioteke nasljeđuju postavke sigurnosti od roditeljskih SharePoint Siteova, folderi od listi i biblioteka, a stavke u listama, odnosno dokumenti u bibliotekama, nasljeđuju postavke sigurnosti od foldera kojima pripadaju.

Princip nasljeđivanja se može prekinuti na svakom od ovih nivoa: svakom od spomenutih objekata možemo postaviti sigurnosne postavke neovisno od njegovog roditelja. Tada svi niži objekti, kojima je ovaj objekat roditelj, nasljeđuju nove postavke sigurnosti, bez mogućnosti da preskoče "generaciju" i naslijede postavke sigurnosti od objekta koji je dva nivoa iznad.

Pošto je najniži nivo objekta kojemu se mogu dati postavke sigurnosti stavka u listi, odnosno dokument u biblioteci, jasno je da moramo dobro paziti kako ćemo planirati sigurnosni koncept: ukoliko budemo postavljali postavke sigurnosti za svaki fajl u nekoj biblioteci koja broji 15.000 dokumenata, evidentno je da je takav posao nemoguće raditi ručno, a automatiziranje postavljanja sigurnosnih postavki na nivou fajla u tako velikim bibliotekama može značajno opteretiti resurse. U takvim slučajevima je mnogo bolje ponovo razmisliti o konceptu sigurnosti koji je izabran, i da li je njega moguće nekako poboljšati.

Gdje su ograničenja u konceptu securable objects i nasljeđivanja postavki sigurnosti? Prvo i osnovno ograničenje je da je "gornja granica" Site Collection. Objekti koji se nalaze u različitim kolekcijama, ne mogu međusobno dijeliti sigurnosne postavke. Drugo ograničenje je da se sigurnosne postavke mogu nasljeđivati isključivo od roditeljskih objekata - jedan objekat ne može naslijediti postavke drugog objekta, ako taj objekat ne leži u hijerarhiji direktno iznad njega. Treće, i posljednje ograničenje, je da je najniži nivo postavljanja sigurnosnih postavki element u listi, odnosno dokument u biblioteci.

Iako se dugo razmišljalo o tome da se u SharePoint Server 2010 uvede postavljanje sigurnosnih postavki na nivou kolona (fields), gdje bi se moglo odrediti da određene grupe korisnika ne vide ili ne mogu mijenjati određene kolone elemenata, od toga su u Microsoftu, na kraju, radi očuvanja jasne i direktne logike sigurnosnih postavki, odustali.