cs:tech:attributes

Toto je starší verze dokumentu!


Atributy

Názvy atributů využívaných u IdP a SP se liší od názvů použitých v SAML komunikaci. Znamená to, že na každé straně je potřeba definovat vhodné mapovaní. Toto rozdělení zvyšuje interoperabilitu různých součástí federace, které můžou mít rozdílné názvy pro stejné atributy.

Existuje několik způsobů kodování atributu v SAML komunikaci. Pokaždé jde o URI:

  • urn:oid - pokud jde o atribut z LDAP třídy, nejvhodnější je zápis pomocí OID, např. atribut mail se da zapsat jako urn:oid:0.9.2342.19200300.100.1.3
  • urn:mace - v ostatních případech je možné použít identifikátor z namespace urn:mace a to buď ze standardizovaného podstromu urn:mace:dir:attribute-def, tak i z vlastního podstromu, který ale musí být explicitně přidělen organizaci
  • URL - nejvhodnější způsob pojmenování vlastních atributů je použití URL, kde hostname je z domény patřící dané organizaci, např. https://cesnet.cz/attribute-def/customAttr

Podrobné informace o konvencích v pojmenovávání atributů najdete na Shibboleth Wiki.

Povinné atributy

Každý poskytovatel identit musí být schopen povinné atributy poskytovat. Jedná se o následující:

    • Definice: celé jméno včetně diakritiky a bez akademických titulů v pořadí křestní jméno (jména) a příjmení
    • Příklad: Kryštof Šáteček
    • Definice: jednoznačný identifikátor osoby v rámci federace
    • Příklad: satecek@example.org
    • Definice: vztah(y) osoby k organizaci
    • Příklad: member@example.org, employee@example.org, staff@example.org
    • Definice: persistentní náhodně vygenerovaný řetězec nenesoucí žádnou informaci o osobě
    • Příklad: https://idp.example.org/idp/shibboleth!https://sp.example.org/shibboleth!DMSjKwRge9YmZlc3leBnl0npqBs=
    • Definice: jednoznačný, dlouhotrvající, neměnný a nikdy nerecyklovatelný identifikátor osoby v rámci federace
    • Příklad: 89645@example.org
    • Poznámka: souvisí s atributem „unstructuredName“ a generuje se jako hodnota_unstructuredName@example.org
    • Definice: celé křestní jméno (případně všechna křestní jména) včetně diakritiky
    • Příklad: Kryštof
    • Definice: ověřená adresa elektronické pošty uživatele
    • Příklad: krystof.satecek@example.org
    • Definice: celé příjmení (případně všechna příjmení) včetně diakritiky
    • Příklad: Šáteček
    • Definice: unikátní identifikátor uživatele, který se nikdy nezmění a nikdy nepoužije pro jiného uživatele
    • Příklad: 89645
    • Poznámka: souvisí s eduPersonUniqueId, který ho využívá

Regulované (doporučené) atributy

Všichni poskytovatele identit, kteří používají regulované atributy, je používají pouze k níže uvedenému účelu.

  • o
    • Definice: označení organizace
    • Příklad: CESNET, z. s. p. o.
    • Definice: označení organizační složky v rámci organizace
    • Příklad: Oddělení síťové identity

Výše uvedené atributy slouží pro prezentační účely a nejsou vhodné pro autorizaci.

    • Definice: řízení přístupu k vyjmenovaným službám
    • Příklad: urn:mace:terena.org:tcs:escience-user
    • Definice: DN popisující organizační jednotku, k níž má osoba formální vztah
    • Příklad: ou=k135,o=fel,dc=cvut,dc=cz

TCS atributy

    • Definice: ověřené e-mailové adresy konkrétního uživatele
    • Příklad: krystof.satecek@example.org
    • Definice: celé jméno v pořadí křestní jméno (jména) a příjmení bez titulů a diakritiky
    • Příklad: Krystof Satecek
    • Definice: řízení přístupu k vyjmenovaným službám
    • Příklad: urn:mace:terena.org:tcs:escience-user
    • Definice: telefonní číslo uživatele
    • Příklad: +420123456789

Lokální atributy

Lokální atributy vznikají pro účely různých projektů. Obdobně jako atributy regulované se nesmí používat v rámci celé federace k jinému účelu, než k jakému je popsáno. V současné době se jedná o následující.

http://www.mefanet.cz/mefaperson/ - atribut nabývá hodnot lf.muni.cz, lf1.cuni.cz, lf2.cuni.cz, lf3.cuni.cz, lfhk.cuni.cz, lfp.cuni.cz atd. pro zaměstnance a studenty lékařských fakult. Podrobnosti a aktuální informace jsou na http://www.mefanet.cz/mefaperson/.

U výše neuvedených atributů se doporučuje přednostně využívat atributy a jejich definice použité v objektové třídě eduPerson.

Doporučení

Pro autorizaci je vhodné používat zejména atribut eduPersonScopedAffiliation, který vystihuje vztah uživatele k organizaci, např. memberexample.org. Naopak je nevhodné používat k autorizaci identifikaci IdP.

Při autorizaci podle příslušnosti uživatele k určitým částem organizací, např. při povolení přístupu ke službě A jen zaměstnancům oddělení B z organizace C a studentům předmětu D na univerzitě E, je vhodné zavést na všech zúčastněných IdP novou hodnotu atributu eduPersonEntitlement označující uživatele s právem přístupu ke službě A, tj. o autorizaci rozhodovat na IdP. Opačný postup, kdy IdP poskytují informace o vztahu uživatelů k oddělením a zápisu předmětů a o autorizaci rozhoduje sama služba A, nutí spráce služby rozumět vnitřním vztahům ve všech zúčastněných organizacích, což nemusí být vhodné.

Pro zvýšení ochrany osobních údajů uživatelů je vhodné předávat poskytovatelům služeb pouze nezbytný počet atributů a preferovat použití atributu eduPersonTargetedID.

Identifikátor urn:oasis:names:tc:SAML:2.0:nameid-format:persistent doporučujeme, protože uživateli zajištuje na jedné straně soukromí (není znám jeho login a tedy identifikace) a současně je pro konkrétní SP vždy stejně identifikován a SP tak může poskytovat službu uchovávání dat, ať už skutečných dat uživatele anebo jen nějaké jeho nastavení. Nezbytná implementace není, u řady služeb bude ale vyžadováno uvolňování EPPN.

Poslední úprava:: 2020/01/06 18:06