[HREF-tech] RR tapasztalatok - SP szűrési szabályok

2010. Ápr. 21., Sze, 16:59:33 CEST

Szia Tamás!

On 2010.04.20., at 17:18, Csillag Tamas wrote:

> Sziasztok!
> 
> Egy kis segítségre van szükségem, illetve tapasztalataimat osztanám
> meg: Ma próbálkoztam életem első RR-ben felvett és az RR-es elképzelés
> szerint beállított SP-t életre kelteni.

Remek-remek! :)

> Tapasztalatok:
> 
> Kivettem azt az általános szabályt, ami a többi föderációs SP fele egy
> minimális attribútum halmazt kiad. Így nem működött a wiki.aai.niif.hu
> -n a belépés. (Mert ha valakinél csak ajánlott az eppn kiadása, annak
> nem adom ki.) Kézzel felvettem a RR-ben, hogy a wiki.aai -nak
> mindenképp adja ki. Most működik.
> . Esetleg át lehetne írni, hogy ne ajánlott, hanem kötelező legyen?

Igen, ezt át is írtuk.

> SP létrehozásakor a nameid választásakor elbizonytalanodtam. Végül kis
> hezitálás után a "Persistent NameID" lehetőséget választottam (később
> persze rájöttem, hogy nálunk az IDP nem tud ilyet). Az IDP (slo build)
> nullpointerexception-t dobott.
> . Az újabb idp-k amin ezt a hibát javítottátok hogyan viselkezdik
> ilyen esetben?

Szerintem ez a hibajelzés jogos, mivel valószínű, hogy nincs beállítva, hogy az IdP kiadjon persistent nameid-t. Ez kétféle módon állítható elő: vagy számított módon (computedID), vagy adatbázisból előhívva (storedID). Hiába lehetséges mindkét módon előállítani ugyanazt az értéket egy felhasználóhoz, az azonosító megfelelő módon történő kiadása, és alkalmazás oldalon történő kezelése okán egészen bonyolulttá válik az ügy, így megpróbálom praktikus oldaláról megfogni a jelenlegi helyzetet.

Ajánlások IdP oldalra:
- ha nincs lehetőség megfelelő mysql háttérre, akkor használj computedID-t, ezt megfelelően kódolva az eduPersonTargetedID attribútum értékekén lehet kiadni. (de ez persistent nameid-ként pl már nem adható ki)
- ha van lehetőség megfelelő mysql háttérre, akkor ajánlott a storedID használata, hiszen ezt ki lehet adni persistent nameID-ként is, de az előző pontban írtak szerint is az eptid attribútum értékeként.

Jó hír, hogy mindkét megoldás benne van az RR által generált attribute-resolver.xml-ben. A computedID-s megoldás defaultként, a storedID-s pedig kommentjelek között, így ezek megfelelő változtatásával egész hamar beüzemelhető. 

A storedID-s megoldás kiegészítő teendőiről wiki cikk is akad: https://wiki.aai.niif.hu/index.php/Shib2PersistentId
A computedID nem igényel további teendőket.

> . Nem lehetne esetleg default-nak a 'Transient NameID' -t bejelölni?
> Lehet, hogy cél lehet, hogy a persistent nameid elérhető legyen
> (tényleg ez manapság egy föderációs idp-n mennyire elérhető?), de
> lehet, hogy érdemes lenne jelezni az SP-t regisztrálónak, hogyha
> valaki a persistent nameid-t kéri, akkor az idp-k egy részével fog
> csak tudni kommunikálni.

Alaposan átgondoltuk, mert valóban nem triviális az ügy, és arra jutottunk, hogy az alábbi kérdés megválaszolásával lehet talán a legegyszerűbben eldönteni, hogy merre tovább.

*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...

Kérdésedre konkrétan válaszolva: előre megfontolt szándékból maradt jelöletlen a választógombsor, hogy mindenki elolvassa, s ez alapján válasszon.:) Segítségképp az utolsóhoz odatettük az "ajánlott" megjegyzést, ez a fenti opciók közül a kettesnek felel meg.

> Az SP-nek előkészített attribute-policy.xml szűrést alkalmaz a
> eppn-re. Nálunk most úgy van konfigurálva, hogy az email címet adja ki
> eppn-ként (az emailszerver is ezt használja, így ez így jó, user nem
> módosíthatja). Viszont azt sejtem, hogy nem jó a formátum amiben
> kiadja, így a ScopingRules kiszűri (jelzi a logban, ha a szűrést
> megszüntetem az alkalmazás megkapja).
> . Kérlek segítsetek, hogy az IDP-n, hogyan kell ezt konfigurálni, hogy
> jól működjön? (továbbra is úgy szeretném, hogy az email címet
> használja)

Több megoldás is van, a legegyszerűbb, hogy megírod, melyek a @ utáni részek, ezek bekerülnek a metadatába, utána már menni fog. Ha nagyon sok ilyen érték van, akkor pedig meg kell keresnünk a központi metadata aláíró eszköz fejlesztőjét, és lefizetni, hogy engedélyezze a speciális karaktereket a metadata scope mezőjében, mert akkor elég lenne csak *.ppke.hu -t írni a felsorolás helyett :)

Üdv,
Tamás

> 
> Előre is köszönök mindent!
> 
> Üdv.
> -- 
> CSILLAG Tamas (cstamas) - http://digitus.itk.ppke.hu/~cstamas
> 
> We must not put mistakes into programs because of sloppiness, we have to do it
> systematically and with care.                        -- Edsger Dijkstra
> 
> 
> _______________________________________________
> HREF-tech mailing list
> HREF-tech at listserv.niif.hu
> https://listserv.niif.hu/mailman/listinfo/href-tech

--
FRANK Tamas
tamas.frank at niif.hu

NIIF AAI
Hungary