547
szerkesztés
Módosítások
→Állandó felhasználói azonosítók
Az állandó azonosító kiadható attribútumként, illetve a SAML Assertion NameID mezőjében. Bizonyos SP implementációk (pl. a Shibboleth 2.x) képesek arra, hogy az alkalmazás részére elfedjék azt, hogy az azonosító pontosan milyen attribútumban vagy NameID-ben érkezett, pl. úgy, hogy az azonosítót a REMOTE_USER változóban adják ki az alkalmazás számára.
====NameID formátumok - melyiket válasszam?====
A kérdés eldöntése SP üzemeltetőként kritikus, ha IdP-t üzemeltetünk, akkor tranziens nameid formátumot alapértelmezetten támogatja az IdP, a perzisztens nameid formátum támogatása, 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óban. Ha SP-t üzemeltetünk, akkor célszerű eldönteni már az üzemeltetés kezdetén, hogy melyik nameid 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: transient nameid-t 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 attribútumként, vagy persistent nameid-ként érkezik az érték az SP-hez ), akkor az SP-nek "Nem kell meghatároznia, hogy milyen nameid formatot támogat", hiszen ezesetben
: a) Ha az IdP nem támogatja a storedID-t, tehát nem tud kiadni persistent nameid-t, akkor a transient nameid mellé a computedID által generált értéket fogja kiadni az eduPersonTargetedID attribútumban
: b) Ha az IdP támogatja a storedID-t, akkor persistent nameid-ként fogja kiadni storedID által előbányászott értéket.
: 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 is szeretne az SP használni, akkor kizárólag persistent nameid-t kell kérnie. Ez a megoldás eléggé a jövő zenéje még...
4. Ha igen, é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át.
Az 1-2. elvárt, hogy IdP oldalról mindenhol támogatott legyen, tehát legalább a computedID-s megoldást be kellene mindenhol üzemelni. A 3-4. esetében minden további nélkül előfordulhat, hogy az IdP és SP közötti kommunikáció elhasal, mert valaki nem támogat valamit...
{{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.}}
