7.6. Szabványok és törekvések

Az egyszerűsített bejelentkezési technikákat és megoldásokat már évek óta alkalmazzák. A szövetségi azonosítás menedzsment gyökerei a bejelentkezési technológiában vannak. Ebben a fejezetben először áttekintjük az eID kialakítására tett kísérleteket, majd bemutatjuk a SAML (Security Assertion Markup Language) nyelvet.

7.6.1. Az eID szabványosítása

A szövetségi ID menedzsment szükségessé teszi, hogy az egyedi azonosítók mellett a polgároknak legyen egyetlen nagyon biztonságos eID-je is. Ilyen eID kidolgozására és bevezetésére, mint arra fentebb rámutattunk csak az államok képesek. Természetesen ezen a területen is szükség van az Európai Unió országainak együttműködésére, tapasztalataik, eredményeik folyamatos kicserélésére.

Állami eID kiadása Európában még kezdeti stádiumban van. Észtország volt az első, amelyik a teljes lakosságot ellátta ilyen azonosítóval. Az első védett szolgáltatások tipikusan a kormányzat területén maradnak és nemzeti jellegűek. Tekintettel arra, hogy sokszor az államot megelőzve, a vállalkozói szektor is jelentősen növeli az Interneten keresztüli on-line szolgáltatásait, valamint az Európai szolgáltatási piacnak komoly határokon átnyúló terjeszkedési lehetősége van, várható a privát szektor részéről is, hogy igénybe veszi az interoperábilisan használható, nemzetközi eID-t.

Információs társadalmunk gazdasági potenciálja csak akkor használható ki teljesen, ha az eID-t szektor semlegesen és minden körben használjuk. Meg kell jegyeznünk ugyanakkor, hogy az eID használati körének kiterjesztésével arányosan növekedik a veszélyforrások száma is. Jelenleg a kormányok az eID-t állami alkalmazások kiszolgálására kívánják használni, következésképpen nem nagyon foglalkoznak azzal a járulékos veszélynövekedéssel, amelyet a szélesebb körű használat jelentene. Az eID teljes körű elterjedését tehát csak egy hosszabb evolúciós folyamat eredményezheti. Az eID-vel kapcsolatos veszélyek elhárításának leghatékonyabb stratégiáját ezért ezen az evolúciós modellen lehet vizsgálni, az elemzést a jelenlegi helyzettel kell kezdeni és kiterjeszteni az elemzést a folyamatosan javuló veszély menedzsmentre. Az egyik kulcsfontosságú veszély a polgárok privát szféráját jelenti. Különösen fontos itt az alábbi két terület:

  1. (i)személyre vonatkozó, egymástól független adatok összekapcsolása,

  2. (ii) szükségtelen személyes adatok ellenőrizetlen közlése, terjesztése.

A mai állami eID-k többsége nem tudja ezeket a problémákat kezelni, így veszélyes lenne azoknak a széles körű elterjesztése. Például nagyon sok eID a polgárt a személyi igazolványában található egyedi, nemzeti jelsorozattal azonosítja. Határozott intézkedések nélkül könnyen előállhat az a helyzet, hogy nagyon sok, egymástól független adatbázis alkalmazza ezt az azonosítót az adatokhoz való hozzáférés kulcsaként és így lehetőséget teremt független adatok összekapcsolására. Tekintettel arra, hogy az adatbázisok kulcsát később nehéz megváltoztatni, ezért az ilyen helyzetet már kezdeti stádiumban el kell kerülni.

Az osztrák polgárkártya jó példa arra, hogy hogyan kerülhető el az eID-k alkalmazása során az összekapcsolhatóság. Ez a kártya dinamikus, szektor illetve alkalmazás specifikus személyi azonosítókat alkalmaz, amelyeket egyetlen, az eID-ben található gyökér-azonosítóból vezetnek le. Tekintettel arra, hogy ez a megoldás nem alkalmazható közvetlenül az X.509 eID-vel, ezért ezt a megoldást nem lesz könnyű kiterjeszteni más országra. Belgiumban, hazánkhoz hasonlóan, törvény tiltja, hogy a személyi számot adatbázisok kulcsaként tárolják.

A legtöbb ma használatos eID nagyon kevés ellenőrzési lehetőséget ad a személyes adatok ellenőrizetlen közlésére, terjesztésére. A személyes adatokat tipikusan egy hitelesítés tartalmazza és egy vagy több személyes adatot tartalmazó fájl található smart kártyákon. Személyes adatok ezen autentikus forrásának eredményes és biztonságos alkalmazásaihoz ma még hiányoznak a szabványos hozzáférési és jóváhagyási mechanizmusok. A hitelesítésben található adatok jelentik minimális kiolvasható információk körét. Amennyiben a hitelesítésen túl további adatokra van szükségünk, akkor a mai eID-k nagyon kevés ellenőrzési lehetőséget tartalmaznak az adatok kiolvasására. Az adatfájlokat csak egységes egészként lehet továbbítani, származtatott adatok közlésére, mint például egy korcsoporthoz való tartozás a születési dátum helyett, egyáltalán nem lehetséges.

7.6.2. Security Assertion Markup Language (SAML)

Az elsődleges szövetségi ID szabványért versengő jelöltek közül pillanatnyilag a SAML (Security Assertion Markup Language) tűnik a legesélyesebbnek. A SAML az OASIS Security Services Technical Committee nemzetközi konzorcium terméke. 2001-ben kezdték meg az XML alapú eszköz kidolgozását. 2002-ben készült el az első verzió V1.0. Később a Liberty Alliance, amely vállalkozások, non-profit és állami szervezetek konzorciuma javaslatot tett a SAML szabvány kibővítésére, amelyet Liberty Identity Federation Frameworknek (ID-FF) neveztek el. A Liberty ID-FF is szabványos, területek közötti, web-alapú és egyetlen azonosítást igénylő rendszer. Ezen felül a Liberty bevezette a bizalmi kör fogalmát, amely szerint minden résztvevő megbízható abban a tekintetben, hogy pontosan dokumentálja a felhasználó azonosítás eljárásait, a hitelesítő eljárások típusait és azokat a szabályokat, amelyek a hitelesített igazolványokkal kapcsolatosak. A bizalmi kör tagjai ellenőrizhetik egymást, hogy betartják-e az előírásokat. A tapasztalatokat figyelembe véve az OASIS is kibővítette a SAML nyelvet és 2005-ben megjelentette annak V2.0 verzióját, amely máig érvényes.

Az Európa Tanács szakmai szervezete, az IDABC (Interoperable Delivery of European eGovernment Services) jelenleg értékeli a szövetségi azonosítást menedzselő rendszereket, többek között a korábban már említett Liberty Alliance ID FF, WS-*, és TLS-Federation termékeket.

A következőkben a szövetségi azonosítás menedzsmenttel kapcsolatos szabványokat, mutatjuk be, a SAML-t, mint az egyik legalapvetőbb szabványt részleteiben is. A SAML egy XML-alapú szabvány mely autentikációs (hitelesítési) és autorizációs (engedélyezés) adatok cseréjét teszi lehetővé biztonságos web domain-ok, tehát az identitásszolgáltató IdP (tanúsítvány kiadója) és egy tartalomszolgáltató SP (tanúsítvány „fogyasztója”) között. Az elsődleges és legfontosabb probléma, amit a SAML kezelni próbál a Web-böngésző Single Sign-On (SSO) problémája.

Single sign-on (SSO) webes, egyszeri bejelentkezési módszer, amely olyan speciális formája a szoftveres azonosításnak, ami lehetővé teszi a felhasználó számára, hogy egy adott rendszerbe való belépéskor csak egyszer azonosítsa magát és ezután a rendszer minden erőforrásához és szolgáltatásához további autentikáció nélkül hozzáfér.

A Single sign-on megoldások bőségesek az intranet szintjén (cookie-k használata például) de ezen lehetőségek kibővítése az intraneten túlra problémás volt és a nem teljesen együttműködő saját technológiák elburjánzásához vezetett. A SAML vált a döntő szabvánnyá, alapjául szolgálva sok Single Sign-On megoldásnak a vállalati azonosítás menedzsment problémakörben.

A SAML feltételezi, hogy a hivatkozott felhasználó (principal) bejegyzett legalább egy azonosítás szolgáltatóhoz. Ez az azonosítás szolgáltató vélhetően a hivatkozott felhasználó helyi hitelesítési szolgáltatásait látja el. Azonban a SAML nem írja le ezeknek a helyi szolgáltatásoknak az implementációit; a SAML nem törődik azzal, hogy a helyi azonosítási szolgáltatások miként vannak implementálva.

Így tehát a tartalomszolgáltató az azonosítás szolgáltatójára támaszkodik a hivatkozott felhasználó azonosítása érdekében. A hivatkozott felhasználó kérésénél az azonosítás szolgáltató SAML assertion-t küld az tartalomszolgáltatóhoz. Az assertion alapján, az tartalomszolgáltató egy hozzáférés vezérlési döntést hoz.

A SAML jó néhány létező szabványra épül, amelyek közül a fontosabbakat felsoroljuk:

  • Extensible Markup Language (XML). A legtöbb SAML elem az XML egy szabványosított dialektusában íródott, amely a SAML nevének alapját is adta (Security Assertion Markup Language).

  • XML Séma. SAML assertion-ök és protokollok (részben) XML sémában lettek specifikálva.

  • XML Szignatúra. Mind a SAML 1.1 és a SAML 2.0 digitális aláírást használ (az XML Szignatúra szabványon alapulva) az autentikációra és az üzenetek integritásának megőrzésére.

  • XML Kódolás. XML kódolás használatával, a SAML 2.0 elemeket szolgáltat a kódolt névazonosítók, kódolt attribútumok, és kódolt assertion-ök használatára (a SAML 1.1-nek nincsenek kódolási lehetőségei).

  • Hipertext Transzfer Protocol (HTTP). A SAML erősen támaszkodik a HTTP-re, mint kommunikációs protokollra.

  • SOAP. SAML részletezi a SOAP használatát, különösen a SOAP 1.1-t.

7.6.3. Föderációs Single Sign-On

A szövetségi SSO (F-SSO) az eljárás, ami által egy felhasználó hitelesíti magát egy szövetségi üzleti partnernél (identitásszolgáltató, IdP) és az IdP kibocsát egy hozzá tartozó identitást (és attribútumait) az egyik/az összes szükséges (és megbízható üzleti partner) tartalomszolgáltatónak, a felhasználó online szövetségi tapasztalatainak részeként. A globális bejelentkezést a szövetségi single sign-on protokoll biztosítja. Ezek a protokollok szabványos, együttműködésre képes eszközöket biztosítanak a szövetségi üzleti partnereknek ahhoz, hogy megegyezzenek a felhasználók bejelentkezési azonosítóinak megadásáról. A következőkben a szövetségi egyszeri bejelentkezést tanulmányozzuk.

7.6. ábra: Biztonságos felhasználói interakció – F-SSO

A 7.6. ábrán a felhasználói interakció egy egyszerűsített ábrázolása látható, ahol a felhasználó kommunikál az A jelű vállalattal, aki IdP-ként viselkedik, a két másik vállalat (B és C) SP-k. A kommunikáció Web böngésző alapú és F-SSO-t használnak az egyszeri bejelentkezésre. Az egyszerűsített bejelentkezés bármelyik SSO protokollal megoldható, SAML, Liberty ID-FF vagy WS-Federation.

A F-SSO szempontjából a leglényegesebb funkciók: pull és push SSO protokollok, account összekapcsolás, WAYF, sessionkezelés, kijelentkezés, bejelentkezési adatok eltakarítása, globális good-bye és account szétkapcsolás. Ezeket az alábbiakban részletesen is bemutatjuk.

7.6.3.1. Push és Pull SSO

Az SSO-nak két módja van, push és pull. A pull SSO a SAML 1.x és 2.0-ban, a Liberty-ben és a WS-Federation-ben elérhető, a push a SAML 1.x-ben és a WS-Federation-ben.

A push SSO azt jelenti, hogy a SSO adatcserét egy az IdP-hez érkező kérés indítja, amely küld (PUSH) egy biztonsági tokent a SP-nek.

A pull SSO esetén a SSO adatcserét az SP-hez érkező kérés indítja, amely kér (PULL) egy biztonsági tokent az IdP-től.

7.6.3.2. Account összekapcsolás

Az eddigiekben csak az egyszeri bejelentkezésről volt szó - nem beszéltünk arról az SP oldalon felmerülő problémáról, hogy esetleg plusz adatokat is kell tárolnia a felhasználóról (ami csak az adott alkalmazásra vonatkozik). Tovább bonyolítja a helyzetet, hogy a felhasználó személyiségi jogait is meg kell védeni a rendszerben, illetve probléma esetén az IdP oldalon visszakövethető kell legyen, hogy egy adott pillanatban melyik felhasználó melyik szolgáltatást vette igénybe.

Az első felmerülő lehetőség, hogy az IdP oldalon tároljuk az összes információt. Ez nyilvánvalóan több okból sem tehető meg. Egyrészt felesleges terhelést és adminisztrációt jelent, ráadásul az IdP szempontjából lényegtelen információkról van szó. Másrészt, ilyenkor biztosítani kellene, hogy a többi SP ne jusson hozzá ezekhez az információkhoz. Sok esetben nem kerülhető ki tehát, hogy az SP is tároljon felhasználói adatokat, a felhasználó rendelkezzen lokális „account”-tal. Például már egy egyszerű webes közösségi alkalmazás esetén sem kerülhető meg, hogy néhány attribútumot (legalább a becenév) megjelenítsen a felhasználókról. Valahogy össze kell tehát kapcsolni az IdP által adott felhasználói identitást az SP oldali adatokkal. Erre a következő megoldásokat találták ki:

Összekapcsolás az IdP által tárolt attribútumok alapján - ez a megoldás az egyszerűbb esetekben használható, de rengeteg problémát indukál. Nem kezeli az esetleges attribútum változásokat, esetleg az attribútum-kiadási elvek változásait, és túl szoros csatolást visz a rendszerbe.

Összekapcsolás fix azonosító alapján - az IdP minden felhasználóról nyilván tart egy fix azonosítót, amit a felhasználó nem változtathat, és ezt az azonosítót elküldi minden egyes SP-nek, aki éppen be akar kapcsolódni a felhasználó munkamenetébe. Tipikusan ez a fix azonosító lehet a felhasználó e-mail címe, vagy a tanúsítványán szereplő név. Sajnos ez a megoldás sem védi meg a felhasználó személyiségi jogait, hiszen két SP a felhasználó tudta és beleegyezése nélkül képes a saját lokálisan tárolt adataikat egyeztetni, ezzel egy nagyobb képet kialakítani a felhasználó tevékenységéről.

Összekapcsolás fix, de alkalmazásonként változó pszeudoname azonosító alapján. Ez a megoldás egy „álnevet” visz a rendszerbe, ami konkrét megvalósításban egy véletlenül kisorsolt azonosítót jelent. Ráadásul minden SP más álnevet lát, de a többszöri látogatás során mindig ugyanazt. Ez a megoldás nem teszi lehetővé a személyes adatok előző pontban végiggondolt kiszivárgását. Az IdP felelőssége, hogy alkalmazásonként különböző véletlen álneveket adjon ugyanannak a felhasználónak, és gondoskodjon arról, hogy ezek az azonosítók perzisztensek maradjanak. Ez többlet adminisztrációval jár, ami miatt néhány IdP szoftver nem támogatja ezt a megoldást.

Összekapcsolás változó pszeudoname azonosító alapján. Ebben a megoldásban az IdP munkamenetenként más és más véletlen azonosítót rendel a felhasználóhoz, ami függ az SP-től is. Sajnos így elveszik az account összekapcsolás lehetősége, de probléma esetén a visszakövethetőség megmarad. Általában beállítható, hogy valamennyi ideig megőrződjenek az álneveket tároló naplófájlok, amiből rekonstruálható a felhasználó útja a rendszerben.

Ezeket az összekapcsolásokat többféleképp is megtehetjük. Attribútum alapú összekapcsolásnál az SP az attribútumok alapján kikeresheti a megfelelő lokális felhasználói profilt és elvégezheti automatikusan az összekapcsolásukat. Egyébként a felhasználónak explicit módon be kell jelentkeznie mindkét rendszerbe, és ezzel az egyidejű bejelentkezéssel kötheti össze a kétféle azonosítóját. Utóbbi megoldást általában a perzisztens álnevek esetén szokás használni. Ez a felhasználó által kezdeményezett összekapcsolás más szempontból is előnyös: magára a végfelhasználóra bízza a döntést, így az adatkezelést is teljesen tisztává teszi. A legtöbb ilyen módon összekötött rendszer lehetővé teszi az összekapcsolt, „federált” azonosítók szétkapcsolását is. Automatikus összekapcsolás esetén az SP akár dinamikusan is létrehozhatja a lokális accountot, az IdP által adott attribútumok figyelembe vételével.

A fentieken kívül lehetőség van természetesen arra is, hogy a perzisztens azonosítók alkalmazásával automatikusan, előre összekössünk néhány konkrét SP accountot a hozzájuk tartozó identitással. Ezt „bulk federation”-nek hívják, és az üzleti rendszereknél gyakran alkalmazott megoldás.

Vegyük RBTelkom-ot és RBBanking-et ahol Kiss Józsefnek külön (hitelesíthető) accountja van mindkét vállalatnál. Amikor a két vállalat megegyezik a federációba csatlakozásról, akkor nekik valamilyen módon lehetővé kell tenni, hogy az RBTelkom felhasználói SSO-val beléphessenek RBBanking-hoz. Ennek a megoldása RBBanking feladata. Ez két lépésben történik, jelen esetben az RBTelkom weboldaláról indulva. Az RBTelkom megváltoztatja a hivatkozást a portálján, így az egyszerű átirányítás helyett, a bank linkjére kattintás egy SSO kérést indít RBBanking-hoz. A pénzintézet megkapja a kérést, de nem tudja megfeleltetni egy helyi identitásnak. Ez azt eredményezi, hogy RBBanking-nak el kell kérnie a bejelentkezési adatait Kiss úrtól. Sikeres hitelesítés esetén, RBBanking-nál hozzárendelődik a RBTelkom által kibocsátott CUID-hez (az SSO kérésből) a saját helyi felhasználó reprezentáció (József direkt bejelentkezéséből). RBBanking most már képes account összekapcsolást létesíteni, így Kiss úr SSO-val bejelentkezhet RBTelkom-tól.

Ha a felhasználó a roll-over15 időszakban akarja közvetlenül elérni RBBanking-ot, akkor őt a szokásos módon hitelesítik. Ezután, RBBanking SSO-t fog kérni RBTelkom-tól (a már hitelesített felhasználónak). A megfelelő SSO válasz tartalmazni fogja a közös felhasználói azonosítót (CUID), így RBBanking mind a RBTelkom által kibocsátott CUID-vel (az SSO kérésből) mind a saját helyi felhasználó reprezentációval (József direkt bejelentkezéséből) rendelkezni fog. RBBanking most már képes account összekapcsolást létesíteni, így Kiss úr SSO-val bejelentkezhet RBTelkom-tól.

RBBanking kikapcsolhatja a felhasználó helyi jelszavának kérését, így a közvetlen hitelesítés RBBanking-nál már nem lehetséges, addig ameddig a felhasználó accountja össze van kapcsolva RBTelkom-mal. Legközelebb, amikor a felhasználó megpróbál közvetlenül hozzáférni RBBanking-hez, a bank SSO-t fog kérni RBTelkom-tól.

Általában az account összekapcsolás részeként, létrehoznak valamilyen hosszú távú/állandó információt, mint például egy http cookie, amely ennek a felhasználónak az identitásszolgáltatójaként azonosítja RBTelkom-ot. A roll-over időszak alatt ezt arra is használják, hogy megkülönböztessék a már összekapcsolt és „még nem összekapcsolt” felhasználókat. Amint a roll-over periódus befejeződött minden felhasználót aki nem rendelkezik ezzel az állandó információval, meg kell kérdezni, hogy eldöntsék, hogy RBTelkom e a valódi identitásszolgáltatójuk.

7.6.3.3. Where Are You From? (WAYF)

Szolgáltatóknak több identitásszolgáltatóval is lehetnek bizalmi kapcsolatai. Ez azt jelenti, hogy a felhasználó kezdeményezhet SSO-t az egyik IdP-től. A tartalomszolgáltató számára azt az eljárást, amellyel meghatározza, hogy melyik IdP-től kell kérnie a SSO-t, Where are you from? (WAYF) szolgáltatásnak nevezzük. Ez egy olyan eljárás, amivel egy felhasználó megadhatja a preferált IdP-jét. Ezt az információt a SP kezeli, így egyszerűen, felhasználói beavatkozás nélkül meghatározhatja, hogy a jövőben melyik IdP-től kell kérnie a SSO-t.

RBBanking ügyében, a WAYF információt a roll-over időszakban hozzák létre. Ebben a periódusban, RBBanking mind tartalomszolgáltatóként (a már szövetségi felhasználók számára), mind identitásszolgáltatóként (a nem federációs felhasználóknak) viselkedik. Tehát RBBanking és RBTelkom is identitásszolgáltatóként viselkedik, az egyetlen tartalomszolgál-tatónak RBBanking-nak.

Ha RBBanking egyetlen SP-je volna több IdP-nek, akkor támaszkodnia kellene valamilyen állandó információra a felhasználóval kapcsolatban (mint például http cookie), azzal kapcsolatban, hogy egy SSO kérést melyik identitásszolgáltatónak kell elküldeni. Ha a cookie hiányzik, akkor RBBanking-nak kezdeményeznie kell, valamilyen felhasználó általi WAYF feldolgozást. RBBanking felkéri Józsefet, hogy válasszon ki egy identitásszolgáltatót az ismert/megbízható IdP-k listájáról.[15]

Némely esetben a tartalomszolgáltató nem hajlandó, felfedni a megbízható IdP-k listáját. Ekkor RBBanking utasítást adna Kiss úrnak, hogy miként érheti el közvetlenül az identitásszolgáltatóját (RBTelkom) és hogyan kezdeményezhet SSO kérést egy IdP alapú mechanizmuson keresztül.

7.6.3.4. Session menedzsment és hozzáférési jogosultságok

Amint a felhasználó bejelentkezett egy tartalomszolgáltatóhoz, a SP felelős azért, hogy kezelje a felhasználó helyi munkamenetét. Ebbe beletartoznak a felhasználó tevékenységeivel kapcsolatos jogosultsági döntések, a munkamenet-kezelés maga, továbbá a kijelentkezés és a biztonsági időkorlát lejárta (session time-out).

Ez azt jelenti, hogy az SP valamilyen szinten képes kezelni a felhasználó attribútumait és bejelentkezési adatait. Ezeket az attribútumokat arra használják, hogy egy felhasználó helyi hozzáférési jogait meghatározzák. Hozzáférési jogokat az IdP adhat ki, a felhasználóról szóló kibocsátott (asserted) attribútumok formájában, ilyen például a csoporttagság.

7.6.3.5. Kijelentkezés

Néhány szövetségi forgatókönyvben, a globális vagy egyetlen kijelentkezés szintén szükséges, ami lehetővé teszi a felhasználónak, hogy az IdP által kijelentkezési kérést küldjön minden munkamenethez. Globális kijelentkezést kérhet a felhasználó IdP-től és SP-től is, a globális kijelentkezés folyamatát azonban mindig az identitásszolgáltató irányítja. Az IdP felelős azért, hogy kezelje azon SP-k listáját, akikhez a felhasználó az adott munkamenetben SSO-val bejelentkezett. Az IdP ekkor egy kijelentkezés-kérést küld a felhasználó nevében mindezeknek az SP-knek.

Ha József kijelentkezik például RBTelkom portáljáról, akkor az RBTelkom már nem veszi figyelembe azokat a tranzakciókat, amibe József belekezd. Ebben az esetben RBTelkom elindít egy kijelentkezési kérést minden üzleti partnernek, amihez SSO kérést bocsátanak ki József aktuális munkamenetén belül.

A globális kijelentkezés nem utal arra a tényre, hogy helyileg is kijelentkezés történik. Előfordulhat, hogy egy felhasználó ki kíván jelentkezni egy tartalomszolgáltatónál lévő munkamenetből, de az IdP-nél lévő munkamenetet nem akarja megszakítani. Másik alternatíva egy SP-nél levő helyi kijelentkezésre, hogy rövidebb munkamenet össz/inaktivitási időtúllépés keretet kell beállítani, mint az alapértelmezett közvetlenül hitelesített munkamenetben. Egy rövidebb tétlenségi időtúllépés, az SSO felhasználónak elfogadhatóbb lehet, mivel így nem kényszerítik explicit újra hitelesítésre. Helyette a SP egyszerűen újra kér egy SSO-t a felhasználó identitásszolgáltatójától.

7.6.3.6. Bejelentkezési adatok eltakarítása

A kijelentkezés, legyen az globális vagy helyi, gyakran magába foglalja a session megszakítását az SP-nél. Ez a munkamenet független lehet a kiszolgáló oldali alkalmazásokkal rendelkező munkamenetektől. A kiszolgáló oldali alkalmazás munkameneteit arra használhatják, hogy fenntartsanak egy státuszt a több lépésből álló tranzakciók kérés/válaszai között. Kijelentkezéskor biztosítani kell, hogy mind az identitásszolgáltatónál, mind a tartalomszolgáltatónál mindenféle sessiont és az ahhoz tartozó attribútumokat megsemmisítsék.

Nézzük meg mi történik, amikor József kijelentkezik a RBTelkom portálról és ezzel egyúttal a RBBanking weboldaláról. Ha József elindított egy tranzakciót (eszközök átvitelére például) aztán elfelejtkezett róla, akkor ezt a tranzakciót el kell takarítani (ez lényegében, egy szemétgyűjtő). Ha ez nem történik meg, akkor RBBanking-nek olyan árva munkamenetei maradnak, amik erőforrásokat köthetnek le a kiszolgáló oldali alkalmazásainál.

7.6.3.7. Globális good-bye

A globális good-bye kezeli a felhasználó hozzáférési jogainak és felhatalmazásainak visszavételét egy szövetségi forgatókönyvön belül. Akkor használják, amikor egy IdP és SP közti kapcsolat megszűnik és minden felhasználói attribútum - beleértve a tranzakció, profil és szolgáltató specifikus attribútumokat - ami fontos a megszűnő kapcsolat szempontjából, szintén megszűnik. Vegyük figyelembe, hogy a szövetségi kapcsolatok többféle módon fejeződhetnek be: a felhasználó dönthet úgy, hogy megszakítja a kötését az IdP és a SP között vagy az identitásszolgáltató és a tartalomszolgáltató nem kívánja folytatni az együttműködést, így megszakítva az IdP felhasználóinak kötéseit.

Például, ha a kedvenc alkalmazottunk, Első úr új állás után néz (és a KisCég-nél dolgozik ezután) akkor hozzáférési jogait és jogosultságait valamint a NagyCég által szponzorált utazási kedvezményeit el kell távolítani a NagyCég és RBTravel közti globális good-bye részeként. Megjegyzendő, hogy ez nem jelenti azt, hogy eltávolítanák Első úr accountját - beleértve a szolgáltató specifikus attribútumokat – RBTravel-nél. Ez csak annyit tesz, hogy minden NagyCég-gel kapcsolatos attribútumot (beleértve a tranzakció és profil attribútumokat) törölnek Első úr RBTravel accountjából.

Általában a globális good-bye az account szétkapcsolással együtt megy végbe.

7.6.3.8. Account szétkapcsolás

Az account szétkapcsolás az az eljárás, amely a közös egyedi azonosítót megsemmisíti, megszüntetve annak a lehetőségét, hogy az IdP és SP egyedileg utaljon egy adott felhasználóra. A szétkapcsolás egyik eredménye, hogy a felhasználó már nem használhatja az egyszeri bejelentkezést IdP-től az SP felé. Megjegyzendő, hogy az account szétkapcsolás független attól, hogy az SP-nél miként hozták létre az accountot/regisztrációs bejegyzést. Tehát a szétkapcsolás lehetséges akkor is, ha az accountot explicit létrehozta a felhasználó vagy az IdP, SP provisioning eredményeként jött létre. A szétkapcsolás után a felhasználó vagy a SP választhat egy másik IdP-t az account összekapcsolás céljából, vagy a tartalomszolgáltató úgy dönthet, hogy folytatja a user közvetlen hitelesítését.

Kiss József dönthet úgy, hogy megszünteti RBTelkom-os számláját. Ez történhet költözés miatt vagy, mert szolgáltatót vált stb.. Esetünkben József már nem lesz képes SSO-val elérni RBBanking-ot RBTelkom-tól, mert már RBTelkom-hoz sem fog tudni belépni. Ebben az esetben József információit RBTelkom-nál és RBBanking-nél is szét kell kapcsolni („de-federálni”). A folyamat eredményeként József közös egyedi azonosítóját megsemmisítik és az egyszeri bejelentkezési képességét RBTelkom-nál elveszti, továbbá visszahelyezik olyan felhasználónak, akit közvetlenül hitelesít RBBanking.



[15] 15 - Egy adott pozíció, szolgáltatás lejáratkori lezárása és egyidejű megújítása további időszakra.