A SharePoint alapú rendszerek tervezése során gyakran kell szembesülnöm azzal, hogy sokak számára a SharePoint jogosultságkezelése egyfajta misztikum (értem ezalatt az üzemeltetőket, fejlesztőket és végfelhasználókat egyaránt). Pedig a dolog nem is olyan nagy ördöngősség.
A SharePoint maga nem végez felhasználó-hitelesítést (authentication), ezt a feladatot valamelyik alatta lévő rétegre, az ASP.NET-re vagy az IIS-re bízza. Mivel leggyakrabban intranetes portálok kialakítására használják a SharePointot, alapértelmezés szerint az IIS Windows Integrated Authentication van bekapcsolva, ez a felhasználókat az Active Directoryból vagy a helyi számítógép felhasználói közül veszi.
A SharePoint jogosultságkezelése tehát alapértelmezésben Active Directory-alapú, de van lehetőségünk más authentikációs módot is választani (pl. Extranet esetében javasolt a Form Based Authentication, FBA). Ahhoz, hogy a különféle típusú felhasználókat és felhasználói csoportokat egységesen kezelhessük, SharePoint oldalon is lehetőségünk van csoportok definiálására, valamint felhasználók közvetlen hozzáadására. Ezekbe a csoportokba egyedi felhasználók vagy AD csoportok is tartozhatnak, ám SharePoint csoportok egymásba szervezésére nincs lehetőségünk. A különféle tartalmakhoz ezeket a SharePoint csoportokat (valamint az AD csoportokat és felhasználókat) rendelhetjük hozzá különféle jogosultságokkal.
Fontos, hogy azok a felhasználók, akik vagy közvetlenül, vagy valamilyen csoporton keresztül nem kerültek hozzárendelésre semmilyen SharePoint tartalomhoz, nem férhetnek hozzá ezekhez, még csak nem is láthatják ezek létezését. Egyetlen kivétel lehet csupán: ha engedélyeztük az Anonymous hozzáférést (pl. Internet esetében). Ebben az esetben a nem nyilvántartott felhasználók az általános anonim hozzáférési jogokat kapják meg.
A hozzáférést több szinten definiálhatjuk, s ezek között fentről lefelé öröklődhetnek a jogosultságok, vagy minden szinten egyedi jogosultságokat definiálhatunk. Ezek a jogosultsági szintek, tartalmi oldalról a következők:
- site collection
- site
- lista / dokumentumtár
- mappa
- listaelem / dokumentum
Sajnos jogosultságok más dimenzió mentén történő meghatározására nincs lehetőségünk. Így nem határozhatjuk meg, hogy az adott elem bizonyos oszlopait csak a felhasználók egy köre láthassa, s másik oszlophalmazt pedig másik felhasználói csoport. Ugyancsak nincs lehetőségünk arra sem, hogy listanézetekhez definiáljuknk hozzáférési szabályokat.
Jogosultsági szintek, elemi jogok
A fentieken túl természetesen azt is meg kell mondanunk, hogy az adott felhasználó(k), csoport(ok) milyen joggal fér(nek) hozzá az adott tartalmakhoz. Ezt úgy valósíthatjuk meg, hogy az egyes tartalom-csoport(/user) párokhoz hozzárendelünk előre definiált jogosultsági szinteket. Például a Tartalomszerkesztő csoport tagjai a Közérdekű Hírek listához "módosítási" és "értesítésküldő" jogosultsági szinten férnek hozzá.
Ezek a jogosultsági szintek elemi jogokból épülnek fel. Az alapértelmezett, beépített szinteken túl természetesen nekünk is van lehetőségünk újabb jogosultsági szintek definiálására (pl. az "értesítésküldő" szintet senki ne keresse by default ;-)). Néhány elemi jogosultság, melyekből építkezhetünk:
- lista elem létrehozása
- lista elem szerkesztése
- lista elem törlése
- dokumentumverziók megtekintése
- dokumentumverziók törlése
- kivétel felüldefiniálása
- figyelmeztetések küldése/kezelése (más felhasználóknak is!)
- jogosultságok kezelése
- tartalmak létrehozása
- webhelyszerkezet módosítása
- személyes nézet létrehozása
- stb.
Az elemi jogok között olyanokat is találunk, melyek egymásra épülnek, ám szerencsére ezt a SharePoint automatikusan kezeli helyettünk: ha olyan jogot adunk a jogosultsági szintet, amely más jogokra is épít, akkor vizsgálat után bekapcsolja valamennyi szükséges elemi jogot.
Kerberos
A Kerberos az MIT által kifejlesztett, ticketing-alapú authentikációs módszer, amely a jelszó alapú hitelesítés legfontosabb gyengeségeit hivatott kiküszöbölni: A kliens kérésekre a Kerberos szerver egy authentikációs jegyet (ticket) biztosít, amennyiben a kérés érvényes felhasználói azonosítót (user credential) és szolgáltatásazonosítót (Service Principal Name, SPN) tartalmaz. A kliens ezután ezt a ticket-et használja a hálózati erőforrás (esetünkben SharePoint) eléréséhez.
Microsoft Office SharePoint Server 2007 esetében az alábbi egységeket védhetjük Kerberos alapú hitelesítéssel:
- MOSS 2007 és SQL Server közötti kommunikáció;
- SharePoint Central Administration Web Application;
- Shared Services Administration Web Application;
- egyéb, tetszőleges webalkalmazás (felhasználói tartalmak, funkciók, stb.);
- Shared Service-ek.
MOSS 2007 intranet környezet esetében a Kerberos konfigurációja utólag, a telepítést és egyéb beállításokat követően történik. A gördülékeny működés érdekében ezért azt szoktam javasolni, hogy a SharePoint környezet kialakítása az alapértelmezett NTLM authentikációval történjen, s csak később, fokozatosan kerüljön bevezetésre a Kerberos.
Néhány trükk
1. A ticketing miatt a Kerberos csak hosszabb session-ök esetében lesz gyorsabb, mint az egyszerű NTLM. Ezért a Kerberos bevezetése előtt mindenképp érdemes a felhasználói szokásokat, a különféle session-ök időtartamát naplózni és elemezni. Bob Fox és Spence Harbar egyik prezentációjában találtam az alábbi, igen beszédes összehasonlítást:
2. Kerberos alapú hitelesítést SSP-kre csak a SharePoint Infrastructure Updates (vagy természetesen az SP2) telepítése után alkalmazhatunk.
3. Egy tévhiedelem szerint a MOSS 2007 csak akkor tudja Kerberos-alapú webalkalmazásaink tartalmait felindexelni, ha az a default porton ül (TCP 80 vagy SSL 443), más portok esetében csak NTLM-mel vagy Basic Authentication-nel. – Felejtsük el, ugyanis mindez egyetlen mozdulattal kiküszöbölhető! Mégpedig úgy, ha a nem-alapértelmezett porton található webalkalmazásunkra Host Header-t definiálunk – ekkor ugyanis a SharePoint máris képes lesz bejárni és indexelni annak tartalmát.
Ide kapcsolódik a következő változás is. A HUNSUG eddig egy zártkörű site-ot tudhatott magáénak, ám egyre nagyobb igény mutatkozott egy igazi közösségi site iránt. Ezért született meg a HUNSUG hivatalos Facebook oldala, ahol ezentúl minden fontos információt, eseményt, akciót, állásajánlatot, stb. megosztunk Veletek, egymással. Csatlakozz Te is, hogy ne maradj le semmiről!
René Hézser írja le, hogyan lehet PS-ből letölteni minden előkövetelményt, és hogyan lehet szintén PS-ből automatikusan telepíteni is azokat: 
