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:
Podrobné informace o konvencích v pojmenovávání atributů najdete na Shibboleth Wiki.
Federativní uspořádání AAI (Authentication and Authorization Infrastructure) si vyžádalo vznik společné sady atributů sloužících k autentizaci a autorizaci uživatele. Sdružení Internet2 proto vyvinulo pro potřebu vzdělávacích institucí objektovou třídu eduPerson. Tato třída představuje rozšíření tříd person, organizationalPerson a inetOrgPerson.
Cílem této sekce webu je stručně popsat význam jednotlivých atributů a jejich hodnot tak, jak by měly být používány v českém akademickém prostředí. Jedná se o dokument vycházející z aktuálních požadavků. V budoucnu se bude s největší pravděpodobností dále vyvíjet na základě nových potřeb a diskuze v rámci komunity eduID.cz.
Schéma eduPerson je implementováno jako objektová třída v adresářové struktuře LDAP. To však neznamená, že všechny atributy musí být nutně uloženy v LDAP serveru. Obzvláště u atributů eduPersonScopedAffiliation a eduPersonPrincipalName se vzhledem k jejich povaze nabízí možnost jejich generování při odpovědi poskytovatele identit (IdP) na autorizační dotaz.
Každý poskytovatel identit musí být schopen povinné atributy poskytovat. Jedná se o následující:
Každý poskytovatel identit by měl důrazně zvážit implementaci doporučených atributů. Jedná se o následující:
Program Erasmus+, který má zjednodušit výjezdy studentů na zahraniční univerzity (“Erasmus without Paper”), vyžaduje nad rámec výše uvedených atributů i jeden specifický atribut — schacPersonalUniqueCode.
Seznam atributů vyžadovaných pro Erasmus+ naleznete na wiki sdružení GÉANT.
Atributy potřebné pro službu TCS jsou uvedeny na samostatné stránce.
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.
Pro autorizaci je vhodné používat zejména atribut eduPersonScopedAffiliation, který vystihuje
vztah uživatele k organizaci, např. member@example.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í eduPersonPrincipalName nebo eduPersonUniqueId.