Ugrás a fő tartalomra

Attribute_Specification

Purpose of this document

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 definitions of the attributes are maintained in their defining schemas. Within this specification, we use the following schemas:

This Attribute Specification provides an interpretation of the defined attributes for their use within the federation. 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

Terms

  • An attribute is implemented, if the information is available according to the semantics of the specification. Releasing an implemented attribute is simply a policy decision of the IdP.
  • An attribute is released, when the data is transferred from the IdP to an SP. Not all available information is sent out normally, only the attributes that are relevant for the 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

eduPersonTargetedID
eduPersonScopedAffiliation
schacHomeOrganizationType
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 most services, it is necessary to store application-specific data, such as user edits for a wiki page. This data is stored in a database, which is local to the SP, while the key between the user and the database entry is the persistent user identifier.

Persistent identifiers can be:

  • 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 do 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 version of the 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
Elnevezés URI: urn:mace:dir:attribute-def:eduPersonTargetedID OID: 1.3.6.1.4.1.5923.1.1.1.10
Rövid leírás Opaque, targeted, non-reassignable identifier
Implementáció kötelező
Részletes leírás 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 ('!').
Lehetséges értékek nincs korlátozás
Értékek száma single
Szintaktika Must be a SAML2 persistent NameID; the unique identifier part must not be longer than 256 ASCII characters.
Adatgazda intézmény
Példa 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 Persistent, non-targeted, non-reassignable personal identifier
Implementáció kötelező
Részletes leírás Format: <local_id>@<scope> where:
  • <local_id>: arbitrary persistent key which unambiguously maps to a person within an institution.
  • <scope>: local security domain. It must have a format as a DNS domain, and ends with a resolvable domain name, which is possessed by the identity provider institution. (Note: the scope as a whole may not be resolved from DNS.)Note: eduPersonPrincipalName is sensitive personal data, it is often equal to the mail address of the person. It is recommended to use it only within the institution's domain. For federation use, opaque, targeted identifiers are more privacy preserving.eduPersonPrincipalName must not be reassignedAs some applications do not support special characters in identifiers, eduPersonPrincipalName MUST only contain the following characters: alpanumeric characters, dot ('.'), hyphen ('-') and underscore ('_').
    		•
    Lehetséges értékek nincs korlátozás
    Értékek száma single
    Szintaktika Directory String
    Adatgazda intézmény
    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 Display name of the person
    Implementáció ajánlott
    Részletes leírás Full name of the person in a form the user (or his or her institution) probably wants to be shown.For international use, please note that Hungarian names are usually in the form of Surname Givenname, and names often contain accented or other non-ascii characters. But also note that this document does not specify the exact name order.
    Lehetséges értékek nincs korlátozás
    Értékek száma single
    Szintaktika Directory String
    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 Mail address of the person
    Implementáció ajánlott
    Részletes leírás Notification email address of the person. The institution asserts that
  • either the address is provided by the institution to the person
  • or the address was provided by the person and the availability and the possession of the mailbox was verified (i.e. by sending a verification email before recording).Transferring unverified values in this attribute is not allowed.
    		•
    Lehetséges értékek Valid email address
    Értékek száma multi
    Szintaktika See also: [RFC 2822](http://www.faqs.org/rfcs/rfc2822.html)
    Adatgazda intézmény
    Példa gipsz.jakab@example.org

    eduPersonScopedAffiliation

    eduPersonScopedAffiliation
    OID 1.3.6.1.4.1.5923.1.1.1.9
    Description Describes the relationship between the person and the institution
    Semantics <affiliation>@<scope>
  • <affiliation>: the following values are permitted
    • student: the person is a student at the institution
    • faculty: the person is a member of the teaching or researching staff
    • staff: the person is a member of the non-teaching staff (ie. IT personnel, etc)
    • employee: the person is employed in the institution (not recommended for use between institutions)
    • member: users who get basic set of privileges. In general, users having student, faculty or staff affiliations, should also be given this value.
    • affiliate: the user is recognised by the institution, but no basic privileges should be given.
    • alum: alumni
    • library-walk-in: affiliated to the library only
  • <scope>: local security domain. It must have a format as a DNS domain, and ends with a resolvable domain name, which is possessed by the identity provider institution.(Note: the scope as a whole may not be resolved from DNS.)\n\nSee also: http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonAffiliation
    		•
    Values One of the following: {student,faculty,staff,employee,member,affiliate,alum,library-walk-in}, followed by the scope
    # of values multi
    Availability -
    Syntax Directory String
    Examples
  • Learners: student@example.org;member@example.org
  • Teachers: faculty@example.org;member@example.org
    		•
    Notes -
    Use in federation -

    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 URI (either URN or URL) that indicates a set of rights to specific resources.
    Implementáció ajánlott
    Részletes leírás List of resources what the user is entitled to use at the SP. The trust between the two parties must be established out of band.An IdP should give only the values which are relevant for the SP
    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
    OID 1.3.6.1.4.1.25178.1.2.10
    Description Type of the Home Organisation
    Semantics
  • university: universities and colleges
  • nren: National research and educational network
  • library: Libraries
  • vho: Virtual home organisation
  • school: Primary and secondary education
  • business: Industrial or commercial companies
  • other: Other
  • test: The principal is a test account
    		•
    Values urn:schac:homeOrganizationType:hu:{university,nren,library,vho,school,business,other,test}
    # of values multi
    Availability -
    Syntax Directory String
    Examples -
    Notes -
    Use in federation -
    Nincs megjegyzés
    Oldal eleje