Módosítások

HREF attribútum specifikáció

569 bájt hozzáadva, 2010. május 27., 10:13
NameID formátumok
====NameID formátumok - melyiket válasszam?====
A kérdés eldöntése SP üzemeltetőként kritikusföderáció elvárja, ha hogy az IdP-t üzemeltetünk, akkor k támogassák mind a tranziens nameid NameID formátumot alapértelmezetten támogatja az IdP, mind a perzisztens nameid formátum támogatásacélzott, átlátszatlan azonosítót (melyek lehetnek tároltak vagy az ezzel egyenértékű, átlátszatlan azonosító eduPersonTargetedID attribútum értékeként történő kiadása pedig elvárt a föderációbanszámítottak). Ha SPA tárolt azonosítót célszerű SAML2 perszistens NameID-t üzemeltetünkként kiadni, akkor célszerű eldönteni már a számított azonosító azonban csak az üzemeltetés kezdeténeduPersonTargetedID attribútumban adható ki, hogy melyik nameid formátum mellett tesszük le mivel nem rendelkezik a voksunkat (ez elsősorban az SP által védett alkalmazás képességeitől függ), mert menet közben átállni körülményes, sok energiát igényelperszisztens NameID szemantikájával. A problémára reméljük könnyebb lesz a megfelelő választ megtalálni az alábbi kérdés átgondolásával: '''Szükséges-e az SP számára, hogy egy-egy felhasználójához tartozzon egy-egy állandó azonosító?'''
1. Ha A Shibboleth IdP implementáció esetén a számított azonosítókról a tárolt azonosítókra való áttérés nemváltoztatja meg a kiadott azonosítókat, akkor egyértelmű a választás: transient nameidezért az SP-t kell használnik számára ez az áttérés transzparens.
Ha SP-t üzemeltetünk, akkor célszerű már az üzemeltetés kezdetén eldönteni, hogy melyik formátum mellett tesszük le a voksunkat (ez elsősorban az SP által védett alkalmazás képességeitől függ), mert menet közben átállni körülményes, sok energiát igényel. A problémára reméljük könnyebb lesz a megfelelő választ megtalálni az alábbi kérdés átgondolásával: '''Szükséges-e az SP számára, hogy egy-egy felhasználójához tartozzon egy-egy állandó azonosító?''' 1. Ha nem, akkor egyértelmű a választás: tranziens formátumot kell használni. 2. Ha igen, és nem szükséges, hogy az állandó azonosító a felhasználóra jellemző legyen, ill. az SP mögötti alkalmazás felkészült ilyen azonosító fogadására ( az alkalmazás szempontjából mindegy, hogy milyen úton, tehát eduPersonTargetedID attribútumként, vagy persistent nameidperzisztens NameID-ként érkezik az érték az SP-hez ), akkor az SP-nek "Nem kell meghatároznia, hogy milyen nameid formatot NameID formátumot támogat", hiszen ezesetben: a) Ha az IdP nem támogatja a storedID-t, tehát nem tud kiadni persistent nameid-ttárolt azonosítókat, akkor a transient nameid tranziens NameID mellé a computedID által generált értéket fogja kiadni az eduPersonTargetedID attribútumbanki fogja adni a számított (és célzott) azonosítót.: b) Ha az IdP támogatja a storedID-ttárolt azonosítókat, akkor persistent nameidazt perzisztens NameID-ként fogja kiadni storedID által előbányászott (illetve, ha az SP kéri az eduPersonTargetedID attribútumot, az IdP képes ugyanezt a tárolt értéketilyen formában is kiadni).
: Az alkalmazáshoz mindkét esetben ugyanaz az érték jut el, mint felhasználói azonosító.
3. Ugyanaz, mint a 2., kivéve, hogy magasabb szintű felhasználókezelést (például SAML NameID menedzsmentet) is szeretne az SP használni, akkor kizárólag persistent nameidperzisztens NameID-t kell kérnie. Ez A HREF föderáció jelenleg nem rendelkezik a megoldás eléggé a jövő zenéje még... 4. Ha igenmagasabb szintű SAML protokollokról, ezért ezek használata kizárólag az adott SP és szükséges, hogy az állandó azonosító a felhasználóra jellemző legyen, őt egyértelműen azonosítósa, akkor a választás transient nameid, amely mellé meg kell követelni az eduPersonPrincipalName kiadásátIdP közötti megállapodáson alapulhat.
Az 1-24. elvárt Ha szükséges, hogy IdP oldalról mindenhol támogatott az állandó azonosító a felhasználóra jellemző legyen, tehát legalább őt egyértelműen azonosítsa, akkor a computedID-s megoldást be kellene mindenhol üzemelni. A 3-4. esetében minden további nélkül előfordulhatválasztás tranziens NameID, hogy amely mellé meg kell követelni az IdP és SP közötti kommunikáció elhasal, mert valaki nem támogat valamit..eduPersonPrincipalName kiadását.
A HREF föderációban az IdP-k részéről elvárt, hogy a fenti 1-2. megoldásokat támogassák. A 3-4. esetében minden további nélkül előfordulhat, hogy az IdP és SP közötti kommunikáció hibát jelez, mert valamelyik fél nem támogatja a másik fél által megkövetelt / biztosított azonosító formátumot...
{{INFO| Egy SP a [[Resource Registry]]-ben jelezheti, hogy milyen NameID formátumokat támogat. Ha kizárólag perzisztens NameID formátumot támogat, akkor vagy kap az IdP-től ilyet, vagy hiba lép fel a válasz feldolgozása során.}}
565
szerkesztés

Navigációs menü