Obsah

Use cases pro konzumaci atributů

Bez 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í:

Příklad SP: Emerald, Karger

Atribut(y) pro autorizační rozhodnutí bez identity

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.

Affiliation

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

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

LoA

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.

Entitlement

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:

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

Dedikovaný atribut

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

Příklad SP: MEFANET

Atributy nesoucí identitu

Pouze targetedId

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.

principalName

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.

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

Kombinace

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)