Virtual Organization Membership Service

Az autorizáció kulcsszerepet játszik a Grid erőforrásainak elérésében. Az autentikációhoz hasonlóan az autorizáció esetében sem célszerű a jogosultsági információkat teljes egészében a végpontokon lokálisan felügyelni, mivel az erőforrásokat felhasználni kiváló személyek általában nem állnak közvetlen kapcsolatban az ezeket kezelő adminisztrátorokkal.

Célszerű bevezetni az alábbi fogalmakat:

ˇ Virtuális szervezetek (VO, Virtual Organizations): a közös adminisztrátori tartományban lévő felhasználókat, szervezeti egységeket és (esetleges) erőforrásokat tömörítő absztrakt entitások.

ˇ Erőforrás-szolgáltatók (RP, Resource Providers): a VO-k tagjai számára a saját házirendük szerint erőforrásokat (processzoridőt, hálózati eszközöket, tároló kapacitást) biztosító egységek.

Az autorizáció szemszögéből a Grid az erőforrás-szolgáltatók és a virtuális szervezetek közti megegyezéssel jön létre, melynek során az elérési jogosultságok megállapításába mindkét fél bele kíván szólni.

1. A felhasználó és a VO-ja közti kapcsolat leírása, ide értve azokat a csoportokat (groups), amelyeknek a felhasználó tagja, a felhasználó szerepköreit (roles) valamint explicit jogosultságait (capabilities).

2. Az erőforrások saját házirendje, mely a fenti információk alapján engedélyezi vagy megtiltja az erőforrás elérését.

Véleményünk szerint az 1. pont alá tartozó információkat célszerű a VO által felügyelt központi szerverben tárolni, míg a 2. pont házirendjeit kényelmes az erőforrások közvetlen közelében, egy helyi ACL-ben (access control list, hozzáférés-vezérlő lista) tartani.

Röviden leírjuk a jogosultság-eléréssel kapcsolatos követelményeket, és bemutatjuk az Európai DataGRID projekttel (EDG) együttműködésben fejlesztett, a VO-szintű tagsági információkat kezelő új szolgáltatást, a Virtual Organization Membership Service-t (VOMS).

A VOMS a Grid Security Infrastructure (GSI) által biztosított autentikációs és jogosultság-delegációs megoldásokra épít.

Jogosultság-elérési követelmények

Az erőforrás-elérések jogosságának ellenőrzését a VO-kal történő megegyezés szerint maguk az erőforrások végzik.

Egy felhasználó egyszerre több VO-nak is tagja lehet. Egy VO-n belül felhasználói csoportok és alcsoportok tetszőlegesen bonyolult szerkezetét alakíthatjuk ki, az adott VO-n belüli különböző felhasználói szerepek megkülönböztetése céljából. Egy felhasználó tetszőleges számú csoportba sorolható.

A felhasználókat a VO egészére nézve és csoportokra lebontva egyaránt tetszőleges számú szerepkörrel (role) és explicit jogosultsággal (capability) ruházhatjuk fel.

Az erőforrás által végzett jogosultság-ellenőrzés részletei alapvetően az erőforrás és a VO közti megállapodásnak megfelelően, a VO által szolgáltatott információkra (csoport-tagságok, szerepkörök, jogosultságok) alapozva kerülnek meghatározásra, azonban az erőforrás-szolgáltatók helyi szinten bármikor felülbírálhatják a VO attribútumait (pl. egyes felhasználók egyedi letiltása érdekében). Ebből következően a felhasználóknak továbbra is igazolniuk kell magukat; a VOMS által szolgáltatott autorizációs információk önmagukban nem elegendők az erőforrások igénybevételéhez.

A VOMS rendszer

A felhasználói információkat egy relációs adatbázisban tároljuk; a VOMS szerver lényegében egy felületet biztosít ezen adatbázis eléréséhez.

A VOMS rendszer az alábbi részekből áll:

ˇ Végfelhasználói szerver (vomsd): fogadja a kliensek kéréseit, és egy attribútum-tanúsítvány formájában átadja egy felhasználóról rendelkezésre álló adatokat.

ˇ Végfelhasználói kliens (User client): a felhasználó (proxy) tanúsítványa segítségével kapcsolatba lép a végfelhasználói szerverrel, és átveszi a felhasználó csoport-, szerepkör- és explicit jogosultság-információit.

ˇ Adminisztrátori szerver (vomsadmind): fogadja a kliensek kéréseit és megfelelő ellenőrzések után frissíti a VOMS adatbázist.

ˇ Adminisztrátori kliens (Admin client): a VO adminisztrátorok használják új felhasználók vagy csoportok létrehozásához, a tagsági információk kezeléséhez stb.

Műveletek

Végfelhasználói oldal

Figyelembe kell vennünk azt a természetes követelményt, hogy a VOMS bevezetésével a felhasználóknak lehetőleg minél kevesebb változással kelljen szembesülniük. Ezért a VOMS információk lekérését és a proxy tanúsítványba építését nem külön kliensprogrammal oldottuk meg, hanem a proxy tanúsítvány létrehozására szolgáló jól ismert grid-proxy-init programot egészítettük ki ezekkel a lépésekkel. A VOMS tagsági információkat egyelőre egy ad-hoc szerkezetű, a szerver által aláírt ,,pszeudo-tanúsítványban" adjuk vissza, mely a felhasználó adatai mellett tartalmazza a VOMS szerver azonosító információit is. (A következő kiadásban a pszeudo-tanúsítványt szabványos attribútum-tanúsítványra fogjuk cserélni.)

A felhasználó egyszerre több VOMS szervertől származó pszeudo-tanúsítvánnyal is rendelkezhet.

A tanúsítványban tárolt autorizációs információk felhasználásához a Globus Gatekeepernek a szokásos tanúsítvány-ellenőrzésen felül a proxy tanúsítványba épített pszeudo-tanúsítványt is fel kell dolgoznia. Ez egy LCAS plug-in segítségével könnyen megoldható. A pszeudo-tanúsítvány a proxy tanúsítvány egy opcionális kiterjesztése, így a proxy továbbra is használható a VOMS információk feldolgozására fel nem készített szolgáltatások elérésére.

Adminisztrátori oldal

Az adminisztrátori kliensek két típusa (grafikus felületű és parancssori változat) ugyanazt a szervert használja az adatbázis módosításához. A szerver SOAP protokoll felett érhető el, így a VOMS könnyedén OGSA szolgáltatássá alakítható. A szolgáltatás funkcióit három csoportba osztjuk: a Core interfész a végfelhasználói funkciók SOAP feletti elérésére szolgál, az Admin interfész a VOMS adatbázis adminisztrátori funkcióit tartalmazza, és a History interfész szolgál a korábbi adatbázis-állapotok lekérdezésére.

Ez utóbbi interfész segítségével az adatbázis tetszőleges korábbi állapotát lekérdezhetjük. Az adatbázis valamennyi táblájában nyilvántartjuk, hogy az egyes sorokat ki és melyik tranzakcióban hozta létre. A tranzakciókat adatbázis-szinten egyedi, szekvenciális sorszámmal azonosítjuk. A már létrehozott sorokat sohasem módosítjuk, és nem is töröljük -- az érvényüket vesztett adatokat archív táblákba tesszük át. Az elévült adatok online tartásával bármikor módunkban áll olyan kérdésekre választ adni, mint pl. ,,tagja volt-e az F felhasználó tavaly szeptember 6-án a G csoportnak", vagy ,,melyik adminisztrátor adta hozzá az F felhasználót a G csoporthoz".

Biztonsági megfontolások

A VOMS szerver a jogosultsági információk kiadása előtt elvégzi a szokásos GSI biztonsági ellenőrzéseket a felhasználó tanúsítványán (ismert, megbízott hitelesítő hatóság által kiadott, érvényes, nem visszavont tanúsítvány). A kiadott attribútumok egyetlen tanúsítványhoz kötődnek, attól elválasztva nem használhatók.

A VOMS szerver titkos kulcsának megszerzésével tetszőleges attribútumhalmaz generálható, amivel a VO-val kapcsolatban lévő potenciálisan bármelyik erőforrás jogosulatlanul elérhető. A szerver puszta megbénításával is jelentős károk okozhatók, hiszen VOMS szerver nélkül a felhasználók nem tudják lekérni attribútumaikat, így az erőforrások sem használhatóak. Elengedhetetlen feltétel tehát a VOMS szerver integritásának védelme.

További fejlesztések

A következő időszak feladatai közé tartozik az attribútum-tanúsítványok használata, adatbázis-replika mechanizmusok kidolgozása, valamint lejárati határidő-megadási lehetőségek kidolgozása a VOMS tanúsítványokra és a csoport-tagsági információkra.