Attribute Specification

Goal of the Attribute Specification

In a federation, information about the user is represented in SAML attributes transferred from the Identity Provider to the Service Provider. It is important for both parties to interpret the data in the same way.

Exact definition of the attributes are maintained in the defining schemas. Within this specification, we us the following schema:

• person, organizationalPerson (X.521)
• inetOrgPerson (RFC2798)
• eduPerson (http://middleware.internet2.edu/eduperson/)
• SCHAC (http://www.terena.org/activities/tf-emc2/schacreleases.html)
• niifPerson, niifEduPerson (NIIFSchema)

This Attribute Specification provides an interpretation of the above documents for federational use. It might be somewhat more specific than the original definition, in order to let the SPs get more specific information about the user.

Beyond the specification, parties may bilaterally agree on any other attributes.

Use of attributes

Glossary

• Implementing an attribute: an IdP implements an attribute, if the information is available according to the semantics of the specification. Releasing an implemented attribute is simply a policy decision.
• Attribute release: transferring the information within SAML attributes from the IdP to an SP.

Levels of implementation

• Mandatory: every IdP must implement the attribute.
• Recommended: it is recommended for every IdP to implement the attribute, however, it is understood that it might be impossible or very complex for certain IdPs
• Optional: an IdP may freely implement the attribute, however, the implementation must follow this specification.

Attribute Requirements of the SP

SPs can indicate attribute requirements among the information provided to Resource Registry. This information also shows up in the federation metadata. From the point of view of the SP, an attribute can be:

• Required: the information is a requirement for the proper operation of the SP application

i.e. eduPersonPrincipalName is often required for applications, which are not prepared for handling opaque identifiers.

• Desired: the information can add extra functionality to the application or can provide better user experience

i.e. when displayName is transferred, the user is not prompted to supply his or her common name.

Attributes

Summary

Mandatory attributes

eduPersonPrincipalName

eduPersonTargetedID

eduPersonScopedAffiliation

schacHomeOrganizationType

Recommended attributes

displayName

mail

eduPersonEntitlement

Optional attributes

Attributes describing user properties	Attributes describing institutional relationship	Attributes for educational use
sn	ou	niifEduPersonAttendedCourse
givenName	eduPersonOrgUnitDN	niifEduPersonArchiveCourse
preferredLanguage	eduPersonPrimaryOrgUnitDN	niifEduPersonHeldCourse
schacDateOfBirth		niifEduPersonMajor
schacYearOfBirth		niifEduPersonFaculty
schacPersonalTitle		niifEduPersonFacultyDN
niifPersonMothersName		niifEduPersonStudentCategory
niifPersonResidentalAddress
homePostalAddress
telephoneNumber
mobile
eduPersonNickName
cn
jpegPhoto
labeledUri

Persistent user identifiers

For some services, it is necessary to store application-specific data, such as user edits for a wiki page. This data is stored in some database local to the SP, while the key between the user and the database entry is a persistent user identifier.

Persistent identifiers can be:

• static: the identifier is created at the time of user creation at the IdP
• computed: the identifier is generated run-time from one or more attributes of the user (usually by some cryptographic hashing algorithm).
• stored: the identifier is stored in the user's digital identity at the IdP, thus it is persistent even when other user information is changed. Uniqueness of the identifier must be preserved.

Identifiers can hold the following properties:

• persistence: IdPs must ensure that the identifier does not change during the life-cycle of the user at the institution.
• non-reassignable: IdPs must ensure that an identifier of a user will not be reassigned to another user.
• opacity: opaque identifiers are not refer to any personal data
• targeted: targeted identifiers are different for each SP, thus the SPs are unable to build common user profile without the cooperation of the IdP. Such identifiers are preferred from privacy reasons.

Persistent identifiers can be transferred in SAML attributes or in NameID of a SAML Assertion. Certain SP implementations (such as Shibboleth 2.x) can hide the details of the transfer, and can provide a persistent identifier in REMOTE_USER header.

List of attributes

In this specification, only mandatory and recommended attributes are specified. The Hungarian Attribute Specification contains descriptions of the optional attributes as well. If you have any questions regarding the optional attributes, please contact the Federation Operator.

eduPersonTargetedID

eduPersonTargetedID
Name	URI: urn:mace:dir:attribute-def:eduPersonTargetedID OID: 1.3.6.1.4.1.5923.1.1.1.10
Description	Opaque, targeted, non-reassignable identifier
Implementation level	mandatory
Semantics	See: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID An SP must process the received value, it must not forward unparsed XML value to the application. As a minimum, the unique identifier and the IdP NameQualifier must be included in the parsed value, which is forwarded to the application. It is recommended to separate fields (such as qualifier values) with an exclamation mark ('!').
Allowed values	no stipulation
No. of values	single
Syntax	Must be a SAML2 persistent NameID; the unique identifier part must be no longer than 256 ASCII characters.
Asserted by	not defined
Example	An IdP sends the attribute on the wire such as: <saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://idp.example.org/idp/shibboleth" SPNameQualifier="https://sp.example.org/shibboleth"> 84e411ea-7daa-4a57-bbf6-b5cc52981b73 </saml2:NameID> The application at the SP receives the attribute as the following: https://idp.example.org/idp/shibboleth!https://sp.example.org/shibboleth!84e411ea-7daa-4a57-bbf6-b5cc52981b73

eduPersonPrincipalName

eduPersonPrincipalName
Elnevezés	URI: urn:mace:dir:attribute-def:eduPersonPrincipalName OID: 1.3.6.1.4.1.5923.1.1.1.6
Rövid leírás	Állandó, nem célzott, nem újra kiosztható egyedi azonosító
Implementáció	kötelező
Részletes leírás	Formátum: <egyedi_lokális_azonosító>@<scope> Ahol <egyedi_lokális_azonosító>: tetszőleges állandó azonosító, amely az intézményen belül egyértelműen azonosítja a felhasználót. Kézenfekvő megoldás a felhasználói azonosító (uid) használata, azonban bármilyen más azonosító használható <scope>: helyi biztonsági tartomány. A végződése kötelezően egy DNS domain, amely az IdP-t üzemeltető intézmény tulajdonában áll. Megjegyzés: az eduPersonPrincipalName érzékeny személyes adat, hiszen sok esetben megegyezik a felhasználó e-mail címével. Intézményen belüli használata javasolt, intézményen kívül célszerű nem átlátszó, célzott azonosítót használni. Az eduPersonPrincipalName a föderációban nem osztható ki újra.
Lehetséges értékek	nincs korlátozás
Értékek száma	single
Szintaktika	Directory String
Adatgazda	nem definiált
Példa	gipsz.jakab@example.org

displayName

displayName
Elnevezés	URI: urn:mace:dir:attribute-def:displayname OID: 2.16.840.1.113730.3.1.241
Rövid leírás	A felhasználó megjelenítendő neve
Implementáció	ajánlott
Részletes leírás	A felhasználó neve abban a formában, ahogy a felhasználó, vagy a felhasználó intézménye meg kívánja jeleníteni.
Lehetséges értékek	nincs korlátozás
Értékek száma	single
Szintaktika	Directory String
Adatgazda	nem definiált
Példa	Gipsz Jakab Aladár

mail

mail
Elnevezés	URI: urn:mace:dir:attribute-def:mail OID: 0.9.2342.19200300.100.1.3
Rövid leírás	A felhasználó email címe
Implementáció	ajánlott
Részletes leírás	A felhasználó értesítési e-mail címe. Az így átadott email címről az intézmény biztosítja, hogy azt az intézmény biztosítja a felhasználó részére (pl neptunkod@intemzeny.hu) vagy az intézmény a cím rögzítésekor ellenőrizte, hogy az a felhasználó tulajdonában van (pl egy megerősítő levél kiküldésével). Az attribútumban ellenőrizetlen, felhasználó által megadott email címet átadni tilos.
Lehetséges értékek	Létező e-mail cím
Értékek száma	multi
Szintaktika	Lásd: RFC 2822
Adatgazda	nem definiált
Példa	gipsz.jakab@example.org

eduPersonScopedAffiliation

eduPersonScopedAffiliation
Elnevezés	URI: urn:mace:dir:attribute-def:eduPersonScopedAffiliation OID: 1.3.6.1.4.1.5923.1.1.1.9
Rövid leírás	Felhasználó és intézmény közti viszony leírása
Implementáció	kötelező
Részletes leírás	<viszony>@<scope> <viszony>: a felhasználó és az intézmény közti viszony leírására az alábbi értékek választhatók student: intézmény hallgatója faculty: oktatási tevékenységet végez az intézményben staff: nem oktatási tevékenységet végző alkalmazott (pl. a rendszergazda és a kertész is) employee: alkalmazott (használata intézmények között nem javasolt) member: azok a felhasználók, amelyek azáltal, hogy azonosította őket az IdP, rendelkeznek intézményhez kötődő általános jogosultságokkal. Jellemzően ide sorolhatók a student, faculty, staff viszonnyal rendelkezők. affiliate: az intézmény azonosítja őket, de nem rendelkeznek általános jogosultságokkal alum: öregdiák library-walk-in: könyvtári tag Megj: lehetséges, hogy a föderációban használható értékek körét a későbbiekben szűkíteni fogjuk <scope>: helyi biztonsági tartomány. A végződése kötelezően egy DNS domain, amely az IdP-t üzemeltető intézmény tulajdonában áll. Lásd még: http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonAffiliation Egy lehetséges vizuális ábrázolás, azonban a halmazok pontos meghatározása az intézmény feladata.
Lehetséges értékek	A következő értékek egyike: {student,faculty,staff,employee,member,affiliate,alum,library-walk-in}, valamint a scope
Értékek száma	multi
Szintaktika	Directory String
Adatgazda	intézmény
Példa	Hallgatók: student@example.org;member@example.org Oktatók: faculty@example.org;employee@example.org;member@example.org Nem alkalmazott oktató-hallgatók: student@example.org;faculty@example.org;member@example.org

eduPersonEntitlement

eduPersonEntitlement
Elnevezés	URI: urn:mace:dir:attribute-def:eduPersonEntitlement OID: 1.3.6.1.4.1.5923.1.1.1.7
Rövid leírás	A felhasználó által jogosan használt erőforrás(ok)
Implementáció	ajánlott
Részletes leírás	Azon erőforrások listája, melyet a felhasználó használhat. Sok erőforrást minden felhasználó elérhet, néhányat csak korlátozott kör - ez utóbbi esetben válik fontossá ez az attribútum
Lehetséges értékek	nincs korlátozás
Értékek száma	multi
Szintaktika	Directory String
Adatgazda	intézmény
Példa	urn:geant:niif.hu:niif:entitlement:vhoadmin

schacHomeOrganizationType

schacHomeOrganizationType
Elnevezés	URI: urn:mace:dir:attribute-def:schacHomeOrganizationType OID: 1.3.6.1.4.1.25178.1.2.10
Rövid leírás	Az intézmény jellege
Implementáció	kötelező
Részletes leírás	university: Az Oktatási Minisztérium által elismert felsőoktatási intézmények (egyetemek és főiskolák) nren: Nemzeti kutatási és felsőoktatási kutatói hálózat szolgáltatója library: Könyvtárak vho: Virtuális azonosító szervezet egyének föderációs azonosítása céljára school: Általános és középiskolák business: Ipari vagy kereskedelmi intézmények other: Egyéb test: Teszt felhasználóról van szó
Lehetséges értékek	urn:schac:homeOrganizationType:hu:{university,nren,library,vho,school,business,other,test}
Értékek száma	single
Szintaktika	URN
Adatgazda	intézmény
Példa	-