[HREF-tech] Perzisztens azonositas

[Kristof BAJNOK]

On Tuesday 09 March 2010 09.48.40 Botka Istvan wrote:
> Az OTKA-s csatlakozas kapcsan (ismet) felmerult a perzisztens
> azonositokezels kerdese (legalabbis bennem).
> 
> Mi erre jelenleg a bevett es hosszu tavon hasznalhatonak latszo modszer?

Hosszabb távon mindenképpen fontosnak tartom, hogy targetált, nem olvasható 
azonosítókat használjunk minden olyan esetben, ahol ez lehetséges. Sajnos 
jelenleg az alkalmazások többsége nincs felkészítve ezek fogadására, a 
Drupal modul továbbfejlesztésén már jóideje dolgozunk.

> Egyaltalan a velemenyetek erdekelne a temaval kapcsolatban.
> Milyen megvalositasok leteznek?

Shibboleth-szinten kétféle mód létezik: a computedId és a storedId.
- a computedId valamilyen, a felhasználóról rendelkezésre álló adatból, 
salt-ból és az SP entityID-jéből számít minden azonosítót valamilyen 
kriptográfiai hash-sel. Emiatt nem garantált (bár igen valószínű), hogy az 
azonosítók mindig egyediek lesznek.
- a storedId feltételez egy háttér-adatbázist, amelynek segítségével az ID 
tárolható és az egyediség is biztosítható. Cserébe további komplexitást 
jelent az, hogy - ha jól tudom - jelenleg csak SQL adatbázist lehet erre a 
célra használni, és ez klaszterezett működésnél nehézségeket okozhat.

Természetesen mindkettőhöz szükség van valami olyan felhasználói adatra, ami 
nem újraosztható.

Fontos, hogy ezt az azonosítót SAML2 NameID-ben _ajánlott_ kiadni, ahol a 
NameIDFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

Lehetséges az attribútutmot eduPersonTargetedID néven is kiadni, bár ez - az 
eptid széles körben elterjedt hibás értelmezése miatt - sok félreértésre 
adhat okot. (A SimpleSAMLphp például alapértelmezett módon _hibásan_ adja ki 
az eduPersonTargetedId-t.)

Lásd:
https://wiki.aai.niif.hu/index.php/HREFAttributeSpec#.C3.81lland.C3.B3_felhaszn.C3.A1l.C3.B3i_azonos.C3.ADt.C3.B3k
https://spaces.internet2.edu/display/SHIB2/NativeSPTargetedID

> Mi az ami a mi kis foderacionkban ajanlott/elvart mod.

A Resource Registry-ből olyan resolver.xml jön, ami default computedId-t 
tartalmaz, emellett (kikommentezve) storedId konfiguráció is szerepel benne. 
[Most látom csak, hogy ez a változtatás még nem lett élesítve; néhány napon 
belül sort kerítünk rá.]

A föderációban minden IdP számára _kötelező_ lesz támogatni a persistent 
NameIDFormat-ot, ezért erre kezdjetek felkészülni.

> Erdekelne ennek meg az adminisztralasa is, vagyis, hogy szukseg eseten a
> perzisztens azonositobol hogy lehet megtudni valami beszedesebb modon,
> hogy az adott idopontban kit takart, stb...

A föderált azonosítóval kapcsolatban nagyon fontos, hogy nagyon nehéz 
megváltoztatni, ezért ha új alkalmazásokat kapcsolunk be - ami esetleg sok 
felhasználó számára lesz elérhető - akkor mindenképpen érdemes targeted 
azonosítóval megcsinálni, mert később képtelenül nehéz lesz váltani.

Kristóf