„Resource Registry” változatai közötti eltérés

Innen: KIFÜ Wiki
(Szerepek a rendszerben)
(Működési elv)
77. sor: 77. sor:
 
Természetesen létezik Power User, aki mindent lát, mindenhez van jogosultsága, de csak nem várt esemény esetén aktivizálódik valahol az NIIF AAI környékén :), amúgy rendeltetésszerű működés esetén a szubszidiaritás elvét képviselve az intézményeké az őket érintő ügyekben a döntési jog.
 
Természetesen létezik Power User, aki mindent lát, mindenhez van jogosultsága, de csak nem várt esemény esetén aktivizálódik valahol az NIIF AAI környékén :), amúgy rendeltetésszerű működés esetén a szubszidiaritás elvét képviselve az intézményeké az őket érintő ügyekben a döntési jog.
  
===Működési elv===
 
  
[[Kép:Rr-abra.png]]
 
  
 
==Folyamatok==
 
==Folyamatok==

A lap 2010. február 25., 10:04-kori változata


Alapfogalmak

  • Attribútum: felhasználóra vonatkozó tulajdonság. A föderációban használt attribútumok listája itt érhető el.
  • SP: Service Provider - Szogáltatás: Webes alkalmazás, amelynek felhasználóit föderatívan, valamilyen IdP által autentikáltatja
  • IdP: Identity Provider - Azonosító szervezet: Feladata a felhasználó azonosítása, felhasználó attribútumainak kiadása SP-k részére
  • Föderáció: olyan intézmények halmaza, amelyek között lehetséges az azonosítási-információk átadása. Az intézmények - szabályozott keretek között - megbíznak a másik intézmény által kiállított azonosítási-információkban.
  • Entitás: a föderációt alkotó elem (IdP, SP)

Áttekintés

A Resource Registry az alakuló magyarországi felsőoktatási és kutatási föderáció (HREF) központi eleme, mellyel a föderációban résztvevő szolgáltatások (SP-k) és azonosító szervezetek (IdP-k) adminisztrálását lehet egy letisztult környezetben, elosztott jogosultságokkal végezni. A rendszer az egyes entitásokért felelős adminisztrátorok számára készül.

A rendszer a svájci SWITCH Intézet által fejlesztett rendszer alapjaira épül, PHP nyelven íródott, adatbázisként MySQL-t használ.

Funkciók

A rendszer saját adatbázisból dolgozik, minden funkciójának kimenete ezeken az adatokon alapul.

  • Föderáció-szintű feladata, hogy a központi metaadatot óránként generálja, melyet a résztvevő "entitások" használnak, ezzel garantálva egyfelől a föderáció egységességét, másfelől a megfelelő formátumú metaadat alkalmazásával megteremtse a lehetőséget, hogy a föderáció kiegészítő alkalmazásai (Discovery Service), ill. nemzetközi szintű együttműködésben - bizonyos keretek közt - más föderációk is dolgozhassanak ebből.
  • Az attribútum-szabályzat szintén föderációs szinten állítható, melyeket kiegészítve, az egyes IdP-k megadhatják, hogy mely attribútumokat milyen feltételekkel adják ki, ill. az egyes SP-k is deklarálhatják, hogy milyen attribútumok megléte esetén tudnak egyáltalán működni.
  • Egyénileg, az adott entitás adminisztrátorai által használhatók az egyes IdP-k, SP-k telepítését és konfigurálását megkönnyítő funkciók, melyek a megfelelő beállításokat webes felületen megadva letölthetővé teszik az ezen beállítások alapján automatikusan generált, és jó eséllyel minimális további kézi konfigurációt igénylő fájlokat. Fontos, hogy ezeket a fájlokat nem kötelező használni, ám segítséget jelenthetnek.

Shibboleth 2.x SP-hez:

  • shibboleth2.xml

Fontos, hogy ezt akkor lehet szinte egy az egyben használni, amennyiben az adott SP csak egy alkalmazást véd. Amennyiben több alkalmazás is igényes Shibbolethet egyazon hoszton, úgy kézzel kell szerkeszteni az xml-t.

  • attribute-map.xml
  • attribure-policy.xml

Ez a két fájl egy az egyben használható letöltés után, további konfigurációt alapesetben nem igényel.

Shibboleth 2.x IdP-hez:

  • attribute-resolver.xml

Ez csak egy keret fájl, a legtöbb olyan elem szerepel benne, amelyeket a helyi viszonyokra szabva már működhet az IdP, ám itt muszáj kézzel is szerkeszteni, pl. LDAP adatok...

  • attribure-filter.xml

Ez egyből használható, a rendszer e-mailt küld róla, ha a föderációba új SP került, így szükséges a frissített attribute-filter.xml letöltése az IdP-hez.

SimpleSamlPHP-hoz:

  • Fejlesztés alatt

Bejelentkezés a rendszerbe

A Resource Registry a https://rr.aai.niif.hu címen érhető el, és bejelentkezni csak föderatív azonosítás után lehet. A nyitóképernyőn a bejelentkezési lehetőségen túl mindössze általános, nyilvános információk érhetők el a föderáció aktuális állapotával kapcsolatban, ill. a rendszer használatához található segítség.

A rendszerbe történő bejelentkezéshez elengedhetetlen, hogy a felhasználót azonosító IdP az alábbi attribútumokat átadja a Resource Registry-nek.

Szerepek a rendszerben

A Resource Registrybe csak föderatív azonosítás után lehet belépni.

Felhasználó

  • Lehetősége van rá, hogy a föderációhoz szolgáltatást (SP-t) regisztráljon, amely jóváhagyás után élesedhet.

SP adminisztrátor

  • Ő felelős egy, vagy több, már jóváhagyott SP-ért, ill. elbírálhat felhasználói SP ajánlásokat.

IdP adminisztrátor

  • Az általa regisztrált és karbantartott IdP-ért felelős.

RR adminisztrátor

  • A Resource Registry-n belül tevékenykedő felhasználók jogosultságaiért felelős, ő adhat hozzá egyes entitásokhoz újabb adminisztrátorokat, ill. bírálhat el IdP-ket, és SP-ket.

Alapértelmezés szerint, aki be tud lépni, a legegyszerűbb felhasználói jogosultságokat kapja, bármilyen magasabb szintű szerepkört RR adminisztrátor delegálhat számára, a magasabb jogkörrel járó felelősségi kört pontosan körülhatárolva. (Pl. A RR adminsiztrátor a felhasználót az őt azonosító IdP adminisztrátorává tehet, amely nyomán a felhasználó pontosan ezt az egy IdP-t hangolhatja, de felhasználói jogosultságokat már nem oszthat tovább)

Fontos, hogy az RR-ben az egyes szerepek egy-egy intézmény adminisztrálásához köthetők, ily módon megvalósítva az elosztott jogosultságkezelést. Egy példán keresztül bemutatva ez azt jelenti, hogy egy felhasználó ha szeretne SP-t felvenni a föderációba, akkor azt csak az őt azonosító intézmény hatókörébe teheti meg, ami azt is jelenti, hogy az adott intézményhez tartozó, RR adminisztrátor jogosultsággal rendelkező felhasználó hagyhatja ezt a regisztrációs-, vagy módosítási kérelmet jóvá. Ugyanez az adminisztrátor csak a saját intézményéhez tartozó entitásokra vonatkozóan oszthat, vagy vonhat vissza jogosultságokat.

Természetesen létezik Power User, aki mindent lát, mindenhez van jogosultsága, de csak nem várt esemény esetén aktivizálódik valahol az NIIF AAI környékén :), amúgy rendeltetésszerű működés esetén a szubszidiaritás elvét képviselve az intézményeké az őket érintő ügyekben a döntési jog.


Folyamatok

SP regisztráció

Bárki, akit a rendszer föderatív azonosítással beléptett, kezdeményezheti egy SP föderációba történő felvételét, ehhez az „SP adminisztráció“ oldalon az „Új SP regisztrálása“ c. menüpontot kell választani. Varázsló segít a regisztrációban, melynek mindössze a telepített SP metaadatának nyilvánosan elérhető url-jét kell megadni (alapértelmezés szerint: https://#HOSTNAME#/Shibboleth.sso/Metadata), majd az automata a lehető legtöbb beállítási paramétert megpróbálja kiolvasni az xml-ből, és egyből beírni az adatbázisba az új SP adatai közé. Mivel minden adatot nem lehetséges az alapértelmezett metaadatból kinyerni, így a regisztráló felhasználónak néhány további adatot kell megadnia ahhoz, hogy véglegesíthesse az SP regisztrációs kérelmet. Ezeket hat csoportra lehet osztani.

  • Alapinformációk: itt kerülnek megadásra az alapvető, leíró információk, melyek az SP nevét, leírását tartalmazzák, ill. a legfontosabb azonosító, az entityID. Az adatok egy része (pl: entityID) kiderül már a metaadatból is, így a beviteli mezőt már az automata kitöltötte.

RrSP1.png


  • Kapcsolattartók: ha a metaadatból nem derül ki, akkor kézzel kell megadni technikai, adminisztratív, általános...stb. kapcsolattartó személyeket, akik adatai a központi metaadatban is szerepelni fognak.

RrSP2.png


  • SP Service Locations: különböző bindingok elérhetőségei – ezt az automata az esetek nagy hányadában jól kiolvassa a metaadatból, emberi módosítást a legritkább esetben igényel.

RrSP3.png


  • Tanúsítványok: az SP által használt tanúsítványokat kell PEM formátumban megadni – ehhez is segítséget nyújt varázsló helyben, amelynek a webszerver címét kell megadni, ami után az automata beolvassa a tanúsítvány(oka)t.

RrSP4.png


  • Kötelező attribútumok: itt lehetséges azon attribútumok megadása, melyek kiadása elvárt az IdP-től, amelyek nélkül az SP által védett alkalmazás nem használható.
  • Hallgatóság: megadhatók, milyen jellegű IdP-k érhetik el az adott SP-t, ill. amennyiben ez a szabályzás nem lenne elegendő, úgy egyesével is megadhatók IdP-k aszerint, hogy felhasználói használhatják-e az SP-t, vagy sem.

Akár regisztráltunk, akár módosítottunk, a változásokat jóvá kell hagynia az Önt azonosító intézet RR adminisztrátorai közül valakinek.

IdP regisztráció

A föderációba új IdP-t - mivel a regisztrálandó IdP-t üzemeltető kolléga még nem tud belépni a Resource Registry-be - egy, a föderációs adminisztrációért felelős kolléga tud regisztrálni. Ehhez szükséges, hogy az IdP, minden kapcsolódó programmal együtt telepítve legyen, és az alapértelmezett, telepítéskor generált metaadat egy meghatározott url-en elérhető legyen. Ehhez a telepítéshez pl. a https://wiki.aai.niif.hu oldalon található Wiki szolgál segítségül.

Ha sikerült az IdP regisztrációja, és kezdeti beállítása, akkor be kell tudni lépni az RR-be, ahol a további adminisztráció elvégezhető. Nagyon fontos, hogy az IdP-n bármilyen módosítás azonnal érvénybe lép, így rossz beállítás esetén akár az IdP által hitelesíthető felhasználók belépése is ellehetetlenülhet.

Az alábbi képeken látható, hogy milyen módosítások végezhetők el egy IdP-hez kapcsolódóan.

  • Alapinformációk: IdP neve, leírása, jellege – technikai ismereteket nem igénylő, leíró jellegű információk

RrIdp1.png


  • Technikai információk: EntityID, és különböző bindingok elérhetőségei – ezt az automata az esetek nagy hányadában jól kiolvassa a metaadatból, emberi módosítást a legritkább esetben igényel.

RrIdp2.png


  • Tanúsítványok: az IdP által használt tanúsítványokat kell PEM formátumban megadni – ehhez is segítséget nyújt varázsló helyben, amelynek a webszerver címét kell megadni, ami után az automata beolvassa a tanúsítvány(oka)t.

RrIdp3.png


  • Kapcsolattartók: ha a metaadatból nem derül ki, akkor kézzel kell megadni technikai, adminisztratív, általános...stb. kapcsolattartó személyeket, akik adatai a központi metaadatban is szerepelni fognak.

RrIdp4.png


A további négy beállítás némi hozzáértést igényel, lévén az alapértelmezett metaadatból nem olvashatók ki. A rendszer ezeket az értékeket a föderációs szabályoknak, megállapodásoknak megfelelően készíti elő, legtöbb esetben nincs szükség módosításra, ám ha mégis, bármilyen speciális igény okán, akkor nagy odafigyeléssel kell beállítani.

  • Támogatott attribútumok: beállítandó, hogy az IdP mely attribútumokat, milyen formában támogatja. A föderációs szinten kötelezőket mindenképp támogatnia kell.
  • Általános attribútum kiadási szabályok: beállítható, hogy amennyiben egy SP az adott attribútumot kötelezően, ill. opcionálisan kiadandóként kéri, akkor az IdP hogyan viselkedjen. Ezek a szabályok általánosak, minden, a föderációban résztvevő SP-r vonatkoznak.
  • Speciális attribútum kiadási szabályok: beállíthatók külön-külön egyes SP-kkel való viselkedés, amennyiben indokolt az általános szabályoktól való eltérés.
  • Telepítési és környezeti információk: leíró információk, amelyek pl. hiba esetén segítséget adnak a hiba elhárítójának, hogy milyen rendszerrel lesz dolga. Emellett statisztikai célokat is szolgál.

attribute-filter generálása

Az attribute-filter.xml a Shibboleth IdP egyik fontos konfigurációs fájlja, amelyben megadhatjuk, hogy az IdP milyen feltételek teljesülése milyen attribútumokat (ne) adjon ki a hozzáforduló SP-nek. További részletek a filter működéséről.

A föderációban résztvevő IdP-k számára a Resource Registry dinamikusan generálja a attribute-filter.xml-t, amely mindig a

https://rr.aai.niif.hu/gen_attribute-filter.php/href/IDP_NEVE/attribute-filter.xml címen érhető el. 

A generátor az alábbi szempontokat veszi figyelembe:

  • Az IdP milyen speciális - egy-egy SP-re külön meghozott - attribútum kiadási szabályokat deklarált
  • Az SP milyen jellegű IdP-k felhasználói számára engedélyezte a szolgáltatás használatát
  • Az SP az előzőeken túl milyen kivételes szabályokat állított fel

A generált attribútum filter alapvetően tiltó jellegű, tehát az IdP pontosan azokat az attribútumokat és pontosan azoknak az SP-knek adhatja ki, melyek megadásra kerültek a beállításoknál, az "egyébként ág": NEM.

Lévén a generátor három szempont alapján állítja össze a filter fájlt, míg az IdP adminisztrátorának ezek közül csak egyre van teljes rálátása, így az IdP-t úgy kell konfigurálnia, hogy egy automata pl. minden órában letölti a fenti címről az adott IdP-re vonatkozó attribute-filter.xml-t, amely szintén automatikusan, immár a legújabb változtatásokat is tartalmazva, aktivizálódik.