A SharePoint jogosultságkezelése és a Kerberos
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.
![colorcoding[1]](http://aghy.hu/wp-content/uploads/2009/06/colorcoding1.png "colorcoding[1]")
![6a00d8341d3df553ef011570e61a5a970b-pi[1]](http://aghy.hu/wp-content/uploads/2009/06/6a00d8341d3df553ef011570e61a5a970bpi1.png "6a00d8341d3df553ef011570e61a5a970b-pi[1]")
