Use cases pro konzumaci atributů

Aplikace vyžaduje pouze autentizaci a nevyužije žádné atributy. To znamená, že o uživatelích nic neví a ani nerozpozná, když se ten samý uživatel znovu přihlásí. Bez dalších omezení tento případ nedává moc smysl. Možné případy použití:

• Aplikace potřebuje pouze ověřit, že uživatel přichází z jednoho nebo více konkrétních IdP.

Příklad SP: Emerald, Karger

Někdy aplikace potřebuje pouze ověřit, že uživatel patří do určité kategorie, skupiny apod. bez nutnosti znát jeho identitu. Typicky to může být poskytovatel zdrojů, který otevírá svou databázi pouze pro studenty. V tomto případě aplikace vyžaduje sadu atributu a na základě jejich hodnoty se rozhodne, zda uživatele pustí. Samotného uživatele pak nepotřebuje nijak identifikovat.

Různé případy aplikací vyžadující tento atribut:

• Potřebují jednoduše zjistit z jaké organizace pochází uživatel. Pokud nejsou nastavené další atributy jako principalName nebo organization, pak zbývá pouze systémový atribut obsahující entitId daného IdP, ale jeho použití může být komplikované.
• Potřebují odlišit členy organizace (s „právním vztahem“, „members“) od těch, kteří se (s různých důvodů) můžou přihlásit („affiliates“).
• Potřebují odlišit specifické role v rámci organizace - „student“, „faculty“, „staff“, …

Příklad SP: EBSCOhost, Proquest, IEEE Xplore (používá eduPersonScopedAffiliation a eduPersonEntitlement)

V současné době všechny domovské organizace v eduID.cz poskytují základní stupeň ověření (LoA 2) a také připojené SP pravděpodobně očekávají (minimálně) tuto hodnotu. Takže aplikace tento atribut nemusely zatím zpracovávat. Použití nižšího stupně LoA v rámci eduID.cz pravděpodobně nebude povoleno, ale v případě zavedení vyšších stupňů by mohly některé aplikace vyžadovat vyšší ověření. Například pro některé aplikace by mohli být zajímaví uživatelé s ověřenou adresou nebo telefonním číslem.

Tento atribut přenáší odpovědnost za autorizační rozhodnutí ze SP na IdP nebo uvádí afiliace k součástem organizace. Místo aby aplikace zpracovala sadu atributů a rozhodla se, zda uživatele pustí, nechává rozhodnutí na IdP, který toto rozhodnutí vyjadřuje nastavením konkrétní hodnoty atributu entitlement. Tento přístup je nutný zejména v těchto případech:

• IdP z různých důvodů nemůže uvolnit veškerá data potřebná pro autorizační rozhodnutí, např. jde o důvěrná data nebo neexistují vhodné atributy pro jejich přenos.
• Omezení je potřeba udělat na straně IdP – například pokud aplikace poskytne omezený počet licencí, je na IdP, aby určil, kteří uživatelé dostanou přístup.

Příklad SP: Ovid, JSTOR, Elsevier, eReading.cz, Levná knihovna, JSTOR

Obdobná funkce jako u Entitlement. Příklad MefaPerson - http://www.mefanet.cz/index.php?pg=mefaperson

Příklad SP: MEFANET

Aplikace nevyžaduje uživatelské atributy, ale potřebuje uživatele „sledovat“ - když se znovu přihlásí rozpoznat, že jde o stejného uživatele. Tohle je potřeba v případech, kdy aplikace udržuje u sebe účet uživatele a pro autentizaci používá federaci. V takových případech obvykle uživatel sám vyplňuje svoje údaje jako jméno, email apod.

Vzhledem k tomu, že tento atribut může obsahovat osobní údaje, většinou není vhodný pro identifikaci uživatele ve smyslu „sledování“ a místo toho by se měl použít atribut targetedId všude, kde je to možné. Jsou ale případy, kdy použití „targeted“ identifikátoru není možné, protože je potřeba korelovat identity z různých aplikací. Typicky, pokud někdo chce použít atributovou autoritu navázanou na Perun, musí mít k dispozici stejný identifikátor, jaký používá Perun. Hodnota atributu může nabýt hodnoty atributu Email. V takovém případě doporučujeme (vzhledem k nakládání s osobními údaji) postupovat dle doporučení pro atribut Email.

Výhoda emailu jako identifikátor je, že je vždy k dispozici a zároveň zaručuje unikátnost. Aplikace jej běžně používají také jako uživatelské jméno. Problém je v tom, že jde o osobní údaj a také není „targeted“, takže pokud to není vyloženě nutné, je vhodnější použít jiné identifikátory.

Pokud jste se však rozhodli využít email jako identifikátor, pak raději použijte tzv. „služební“ email, tj. email, který slouží pro komunikaci daného uživatele s veřejností. V takovém případě se sice nadále jedná o osobní údaj, nicméně bude použit „za účelem pro který vznikl“, což není v rozporu s výkladem úřadu pro ochranu osobních údajů.

V některých případech aplikace potřebuje jakýkoliv unikátní permanentní identifikátor a jako takový může využít některý z atributů – targetedId, principalName nebo email.

Příklad SP: ebrary, Foodle (vyžadují Targeted ID nebo EPPN)