Person and account identifiers in Feide#

This is an overview of the key identifiers in Feide used to identify a user or an account.

eduPersonPrincipalName
OpenID Connect subject identifier
eduPersonUniqueId
uid
norEduPersonNIN
email
UH ID

eduPersonPrincipalName#

Identifier description#

The eduPersonPrincipalName attribute is the full Feide name or Feide ID of a Feide user account. The terms “Feide name” and “Feide ID” are used interchangeably and are the same.

The eduPersonPrincipalName attribute looks like olanor@example.org, and consists of two parts:

The username (e.g. olanor).

The domain (e.g. example.org, en.kommune.no or feide.en.kommune.no). The domain is also sometimes referred to as a realm.

The organization must own the domain name used in their eduPersonPrincipalName attributes. The organization must have good routines in place for handling the eduPersonPrincipalName attribute. It is very important that the username is unique within the organization.

Recommended use#

It is suitable for identifying an active Feide user account. It connects the federated account to the internal account in various services for users (mapping of logged-in account, etc.).

Figure showing relationship between user identifiers in a service and user identifiers from Feide. Shows a user accessing a service. The user logs into the service through Feide. The figure shows the service mapping the user identifier it receives from Feide to its own internal identifier through a mapping table. The table contains Feide user identifiers, e.g. "ola@abc.no" and "kari@abc.no", and maps them to service identifiers "15A838" and "F583C".

Federated login

Step 1:

The user logs in to the service with Feide.

Step 2:

The service receives the Feide identifier of the user account in the eduPersonPrincipalName attribute.

Step 3:

The service has a local table that maps the Feide identifier of the Feide user account with its internal user accounts. The service uses this to look up the internal user account when the user logs in through Feide.

Pitfalls of usage / typical complications / wrong use#

A recurring issue we see is that eduPersonPrincipalName is confused with similar looking attributes, most often email address. The eduPersonPrincipalName attribute value looks like an email address, but it is not an email address.

Another example is Entra ID which uses the attribute userPrincipalName (often abbreviated to “UPN”). The Entra ID userPrincipalName attribute is quite similar to eduPersonPrincipalName in meaning and usage, but it is not necessarily the same. See our separate explanation for userPrincipalName. This problem mainly happens when you look at the attributes and make assumptions about their contents based on what it looks like they contain.

The eduPersonPrincipalName attribute cannot be used to identify a person. One person can have multiple Feide accounts, either in a single organization or across multiple organizations. Organizations can reuse eduPersonPrincipalName values over time. This is not something we recommend, but we know that this is something that is done in practice. This means that services cannot use this attribute to identify a single user account over long periods of time.

Example:

A user has logged in to a service using Feide. This service creates a local user account and links it to the Feide account using the eduPersonPrincipalName attribute.

The student leaves the organization, and the Feide user account is deleted. (This is not communicated to the service.)

A couple of years later, a new student joins the organization, and is assigned the same username and thus receives the same eduPersonPrincipalName.

The student logs into the same service and gets access to the data of the previous student.

Additional information#

The only attribute we can 100% guarantee that a Feide account has today.

A person can have several Feide accounts at the same organization. An example of this could be that a person has extended access with an admin account:

Figure showing a single person having two Feide accounts at an organization. The person is named "Ola Nordmann", and has two accounts "olanor@sikt.no" and "olanoradmin@sikt.no". — Person with two Feide account, one for admin access.#

Two persons are not allowed to share a Feide account:

Figure showing two persons sharing a single Feide account. The persons are named "Ola Nordmann" and "Gunnvor Nilsen", and they are both using the Feide account "brukeradmin@sikt.no". — Two persons sharing a single Feide account.#

OpenID Connect subject identifier#

Identifier description#

The OpenID Connect subject identifier identifies an account. It is commonly transmitted as the “sub” claim in ID tokens:

{
    "sub": "76a7a061-3c55-430d-8ee0-6f82ec42501f"
}

The OpenID Connect subject identifier does not provide any additional information about the user account.

Recommended use#

The OpenID Connect subject identifier is unique within Feide. This means that it can be used to identify a user in Feide.

Pitfalls of usage / typical complications / wrong use#

Feide links the users OpenID Connect subject identifier to their Feide account using the eduPersonPrincipalName attribute on the account. This can mean that a newly created account which reuses the eduPersonPrincipalName gets the same OpenID Connect subject identifier as the old account.

eduPersonUniqueId#

Identifier description#

A long-lived, non re-assignable identifier for a person at an organization. It remains the same even if the username of the person changes.

Example#

eduPersonUniqueId: 28c5353b8bb34984a8bd4169ba94c606@foo.edu

Recommended use#

eduPersonUniqueId uniquely identifies a user. If a user has several accounts in the same organization, the eduPersonUniqueId should have the same value across all accounts.

Pitfalls of usage / typical complications / wrong use#

eduPersonUniqueId should not be treated as an email address as it is most likely not valid for that purpose. Once assigned, it must not be re-assigned to another user.

Additional information#

eduPersonUniqueId was reserved for future use in Feide in the previous schema version. We now have a use case for this identifier, as some services require certain information about a user to ensure uniqueness and identity proofing. In the next schema version this attribute will be included.

Uid#

Identifier description#

The uid attribute is the local username in the organization. This identifier is unique within the organization, as only one person can have a given username.

Recommended use#

The uid is often used to identify a specific user account within an organization.

The uid attribute is sometimes composed of elements of the account holders’ names. For example, “Ola Nordmann” could get “olanor” as their uid. However, this is not a requirement, and different policies for assigning usernames are common. Some organizations may use the full name as the username, and some may eschew names entirely and use the student identifier, e.g. “s67275”.

Pitfalls of usage / typical complications / wrong use#

The uid attribute is not suitable for identifying user accounts in a service used by multiple organizations. This is because different user accounts in different organizations can have the same username. For example, when people have the same first and last name.

Additional information#

The uid attribute should be the same as the part before “@” in the eduPersonPrincipalName attribute. For example, if the user has the eduPersonPrincipalName “arnsto@example.org”, then uid attribute will be «arnsto».

The organization should have good methods in place to generate usernames to ensure uniqueness over time and prevent collisions. This can be done by using a simple algorithm.

When generating usernames, it is important to consider that the algorithm should work for 15-20 years without having to re-use old usernames.

norEduPersonNIN#

Identifier description#

The norEduPersonNIN attribute is a national identity number that uniquely identifies a person.

The number stored in this attribute is issued by the Norwegian authorities.

Recommended use#

The norEduPersonNIN attribute should be used when the service needs to identify a person and not a user account. The same person will have the same norEduPersonNIN attribute across multiple organizations.

The attribute is commonly used when the service needs to link the account with information received from other systems.

Pitfalls of usage / typical complications / wrong use#

The national identity number should not be used in cases where it is not necessary.

The number must not be displayed to other users, as the number can be misused for fraud.

Additional information#

The actual contents of the norEduPersonNIN attribute can be one of:

The official national identity number (fødselsnummer). This is an 11-digit number.
D number: Like the official national identity number, this is an 11-digit number. It is assigned to people who have not been granted a residence permit or for other reasons have not been issued an official national identity number yet.
S / SO number: An 11-digit number issued by Samordna Opptak. (Samordna Opptak is a public service for administering the admission of new students to Norwegian universities and colleges)
DUF number: A 12-digit number that is issued to asylum seekers or refugees before they are assigned a D number or official national identity number. This number is not very common.

If the person does not have any of these identifiers, the norEduPersonNIN attribute is unavailable.

email#

Identifier description#

The email address of a given user. It is commonly transmitted to the services through the mail attribute.

The email address received through Feide is required to belong to a single person. I.e. two different employees at the same organization cannot share an email address registered in Feide.

Recommended use#

Suitable as a contact point for a person.

Pitfalls of usage / typical complications / wrong use#

Unsuitable as an identifier. Email addresses are often changed but they are not subject to change management. For example, many organizations use the person’s name as their email address, so the email will change if the person alters their name.

The email address cannot be considered to uniquely identify a specific user account. Multiple user accounts (both within a single organization and across multiple organizations) can have the same email address, as long as the user accounts belong to the same person.

Additional information#

Cloud services often use the email address as an identifier, for lack of better alternatives.

UH-ID#

Identifier description#

UH-ID is a persistent personal identifier that is unique across higher education in Norway. It is an opaque universally unique identifier (UUID).

An example of an UH-ID can be:

{
    "UH-ID": "a17076b1-654a-4ef1-898e-7de8244acb67"
}

Recommended use#

UH-ID should be used to identify a person throughout higher education in Norway. For example, a person who has been a student at an university will have a UH-ID that can follow the person if they move to a different university, regardless of which roles or organizations the person is associated with in the future.

Pitfalls of usage / typical complications / wrong use#

UH-ID is still an identifier that is under discussion. There are arguments for and against why one should / should not use this identifier.

Additional information#

UH-ID was developed in the project Joint IAM as a proactive way to facilitate the technical aspects of lifelong learning. There is a desire in the education sector for lifelong learning to become a reality.

There are still legal challenges that must be resolved before this attribute can become a reality. UH-ID will then be able to be an identifier in this context.