# Feide documentation concatenation of all documentation pages. generated: 2026-07-16T13:28:05+00:00 # General * [Feide](feide_overview.html.md) * [Multifactor authentication - Deployment guide](mfa_guide.html.md) * [Browser support](browser-support.html.md) * [Contact information](contact_information.html.md) * [FAQ](faq/index.html.md) # Feide Feide is a centralized identity management solution for the educational sector of Norway and is short for «*common electronic identity management*» (in Norwegian: «*felles elektronisk identitetshåndtering*»). The solution is widely used by universities, university colleges, high schools and lower education. With Feide, students and employees in the educational sector get one digital identity that gives them access to web services in the educational field. Feide is technology and platform independent and offers all educational establishments common guidelines for identity management. A Feide name is valid throughout the Norwegian educational sector and can be used to login to all Feide services a person has access to. The Norwegian Ministry of Education and Research has chosen Feide as the sector’s identity management solution. Practically all students and employees now have a Feide identity. A Feide identity can be used for single sign on (SSO) to an increasing number of services connected to the central login service operated by Feide. ## Feide entities ### Users People that use web services in their daily work at schools and universities. ### Services These are services using SAML (web only) or OIDC/OAuth applications (known as clients) offered to the educational sector. Examples of such services are learning management systems, digital learning resources, digital tests, registration systems, services selling student licences and so on. The services are available for activation for chosen home organizations. Feide grants access to each service to specific home organizations. Further authorization (e.g. only employees should be given access) must be done by the service itself. ### Home organizations These are the educational institutions where students and employees have their daily work and their affiliation. For primary and secondary schools, the home organizations are local or county municipalities (in Norwegian: *kommuner* /*fylkeskommuner*). For higher education it is the university colleges and universities. Private school owners can also be Feide home organizations. All users in Feide are affiliated with home organizations. This means that persons can only get a Feide identity by being a student or employee at a home organization. ### Service Providers These are the organizations developing and offering services in the Feide ecosystem. For OIDC/OAuth applications personal users can also register their services. ### Third party data sources A service provider can register a data source, which can then be made available to other applications in the Feide ecosystem in a controlled manner. These data sources can also benefit from access control using Feide in a simple way. ## Feide architecture In the Feide federation there is a single Identity Provider (IdP) – the central login service. This means that all the home organizations share one common IdP. All Service Providers (SPs) only connects to this IdP. This makes it very easy for SPs to reach many users by only connecting with a single IdP. Illustration 4 shows this. ![Feide architecture. The Feide keyhole symbolizes the IdP.](general/images/feide-arch.png) *Illustration 4: Feide architecture. The Feide keyhole symbolizes the IdP.* Note that this is from a technical point of view. SPs decide which organizations should be able to activate the service through Feide. If the service requires payment, formal agreements or contracts, the service provider has to communicate directly with home organizations. ## What Feide provides As mentioned in the previous section, Feide runs a central login service offering single sign on (SSO), and thus provides the participants privacy protection and security. ### Central login service The central login service acts as an intermediary in the authentication process between users, services, and home organizations. There is no central user store in Feide. All information about users is stored at and managed by the home organizations. ![The login sequence](general/images/login_sequence.png) When a user logs in to a service with his Feide identity, the following steps take place: 1. The user accesses the service login page with a browser. 2. The service redirects the user to Feide’s login service. 3. The user enters the Feide username and password, which Feide sends to the user’s home organization. 4. Username and password are verified by the home organization, and, if they are verified by the home organization, the user’s personal data can be sent to the service via Feide. Each service receives only the personal data that the service and Feide have agreed on in advance. To read about the actual message flow, see the [Feide technical guide](../reference/saml/saml2_technical_guide.html.md). One of the major benefits of Feide is that it facilitates single sign on (SSO): A user may authenticate once for an entire work session. After logging in once, the user can access a number of services from different service providers without having to login to each one of them. Another advantage is that the user never gives his or her username and password to the services. Instead there is one single login page for the user. ### Authentication with OpenID Connect / OAuth 2.0 ![Figure showing the Feide OIDC/OAuth architecture](general/images/techarch.png) Feide offers OpenID Connect and OAuth 2.0 interfaces towards applications. End users may choose to authenticate using Feide, ID-porten, guest accounts, international accounts (eduGAIN) and more. - [Obtaining tokens with Feide for application developers](../service_providers/openid_connect/feide_obtaining_tokens.html.md) ### Groups In Feide, a user’s relationship to schools, workplaces, classes, subjects and more are expressed as group memberships. Services can extract group information with an OIDC/OAuth protected API. Group information is populated from Feide, FSAT (Common Student Administrative Services in Norway) and ad hoc groups. - [Data model and API for groups in Feide](../reference/apis/groups_api/index.html.md) ### Data sharing Feide simplifies authorization and access control for third party data providers. Requesting access and starting to use third party data sources on the Feide platform is straightforward for application developers. - [Data sharing](../data_sharing/index.html.md) ### Privacy protection As stated earlier – all personal data are stored and managed by home organizations and there is no central user store in Feide. In the process of becoming a Feide home organization, educational institutions have to ensure that their users’ personal data is correct and review their routines and guidelines for managing personal data according to [Feide standards](https://www.feide.no/sites/feide.no/files/documents/Feide%20systemarkitektur.pdf). Feide is restrictive about distributing personal data to the services. Only personal data that is necessary for the operation of the service is released to a service. A Feide service is required to make a formal agreement with Feide specifying what personal data the service should receive. When a user logs in, only the personal data agreed on will be sent to the service. Services integrated with Feide must be restrictive in how they treat personal data. Personal data should not be distributed further. If any personal data is saved locally, measures should be taken to make sure the data is kept correct and up-to-date. ### Security One important security aspect of Feide is the distributed nature of the Feide solution. A service only receives information about the person who is logged in, and only the information that the service needs. To provide a secure service, measures have been taken on many levels. The central Feide system is implemented on a robust platform and is subject to a strict operating and monitoring regime. # Multifactor authentication - Deployment guide **Document History** | Version | Date | Author | Comment | |-----------|----------|----------------|------------------------------------------------------------------------------| | 1.5 | Oct 2018 | Olav Morken | Replace API for TOTP secrets with new API. | | 1.4 | Feb 2017 | Jaime Pérez | Fix a couple of typos in Appendix 1, norEduPersonServiceAuthnLevel examples. | | 1.3 | Oct 2015 | Jaime Pérez | Update for final settings in production. | | 1.2 | Jul 2015 | Hildegunn Vada | Removed URLs for Feide Authenticator API until further. | | 1.1 | Jan 2015 | Jaime Pérez | Update with new attributes and formats from norEduPerson | | 1 | Dec 2014 | Jaime Pérez | First version of this document. | ## Introduction Feide, the Identity Federation of the Norwegian Agency for Shared Services in Education and Research (Sikt), is introducing the possibility to use a second factor of authentication as a requisite to complete the login process and minimise the possibility of identity theft, especially for those services that require higher guarantees on the security of the whole system. This document describes the technical details and requisites involved in the deployment of a multifactor authentication solution in Feide, as well as the rationale behind them. Institutions willing to deploy this solution should follow this document as a technical guide for an interoperable and secure implementation. This guide, however, does not pretend to be exhaustive or to provide specific instructions for every possible setup, or to describe the administrative procedures that every institution should have in place for a successful and secure deployment. ## Requirements notation The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [**RFC 2119**](https://datatracker.ietf.org/doc/html/rfc2119.html). The use of SHOULD, SHOULD NOT, and RECOMMENDED reflects broad consensus on deployment practices intended to foster both interoperability and guarantees of security and confidentiality needed to satisfy the requirements of many organizations that engage in the use of federated identity. Deviating may limit a deployment’s ability to technically interoperate without additional negotiation, and should be undertaken with caution. ## Motivation The main purpose of a multifactor authentication solution is to verify the identity of the user by other means apart from the traditional username and password authentication. Second factors are usually something that the user physically has, commonly combined with something the user knows (like a token with a PIN code that generates one-time passwords). In order to use most of the multifactor solutions available in the market, some information about the other factors needs to be stored. Since Feide does not store information about the end users in any way, the institutions need to store themselves the relevant information for their own users and the other factors they want to support. Feide has so far implemented support for two different multifactor authentication mechanisms: SMS-based and time-based one-time passwords. Here we discuss their basic characteristics as well as their main challenges. ### SMS-based one-time password Authentication based on text messages is probably one of the simplest and most widespread multifactor mechanisms. When a user has identified with a username and password, a random code is sent to the mobile phone number associated with that account, and the user needs to enter it to continue. That way we can verify that the user is in possession of a specific device he or she is supposed to own. In the case of Feide, many institutions are already registering and storing the mobile phone numbers of their users. However, experience shows that those numbers are not strictly validated, and they may often contain errors, typos or simply be invalid, either due to automated provisioning or the users manually entering them. Besides, it is also desirable that the institutions are able to signal whether a phone number should be used or not for multifactor authentication. This means the phone numbers currently registered at every institution cannot be used right away, so they must be provisioned again, verifying their authenticity and format. ### Time-based one-time password Feide has implemented support for a *time-based one-time password* (TOTP) authentication method that is compatible with [**RFC 6238**](https://datatracker.ietf.org/doc/html/rfc6238.html). It is more specific though, as it uses a subset of the mechanisms described in the standard and restricts how others are used. This authentication method (referred to as *Authenticator* from now on) can be used with hardware tokens, but also with any device capable of running software implementing this method, which is part of its success. Most typically, the user configures a smartphone with an *Authenticator* application by manually entering a shared secret on the application or by scanning a QR code. Later on, the device can be used to generate the six-digit codes used for authentication. Note that even though this mechanism was originally implemented by Google in its *Google Authenticator* application, there is also a wide range of clients that support this mechanism. The *time-based one-time password* authentication mechanism is based on a secret shared between a device owned by the end user (a mobile phone, a hardware token or some software running on a laptop) and the authenticating party. In this case the authenticating party is Feide, as multifactor authentication happens right after traditional username and password authentication, but Feide by design does not store any authentication data for the users. This means the secret shared between Feide and the user must be stored in the directory of the home institution of the user, the same way as passwords. This shared secret is necessary to setup and use an *Authenticator* application to authenticate a user. In a way, it is equivalent to a password. This means we have to handle it with the same security considerations as we would handle a password. Particularly, if the shared secret is stored in plain in the user’s entry in the directory, anybody able to read the entries of other users would be able to setup an *Authenticator* instance identifying any particular user, completely defeating the purpose of multifactor authentication. In order to avoid the *Authenticator* secrets being widely readable for anybody with access to the directory, they must be protected by some mechanism so that only the authenticating party (Feide in this case) can use them. This is achieved by using public key cryptography to encrypt the secrets, so that anybody can encrypt, but only Feide can decrypt them. This is different to usual password protection mechanisms, as passwords are commonly *hashed* with a *one-way* function instead of encrypted. This method cannot be used with the *Authenticator* secrets since Feide needs the original value to generate the one-time password, and the only place it can get that value from is the user directory. For the technical specification see [SAML2.0 Technical Requisites](../reference/saml/saml2_technical_requisites.html.md). ## Testing ### Multifactor authentication login To test if your Feide user supports two-factor authentication, log into [https://two-factor-test.feide.no](https://two-factor-test.feide.no/). If successful, you should see your eduPersonPrincipalName and your eduPersonAssurance. Successful login ![Success stating Two-factor authentication is working](general/images/multifactor-test-success.png) Failed login ![Failure stating This user does not support two-factor authentication](general/images/multifactor-test-failed.png) If not successful, check if your Feide user has the following configuration: 1. Check if the user has a `norEduPersonAuthnMethod`-attribute. 2. Check the format of `norEduPersonAuthnMethod` – It should have two or three fields. 3. Check the method (first field) of `norEduPersonAuthnMethod` – it should be either `urn:mace:feide.no:auth:method:ga` or `urn:mace:feide.no:auth:method:sms`. 4. If the method is `urn:mace:feide.no:auth:method:ga`, check if the other field has the form of `ey[...]n0.Uy[...]UA.tq[...]Kg.ww[...]N5.LZ[...]9Q` i.e. it should contain five elements with base64url-coded data, where each element are separated with `.`. 5. If the method is `urn:mace:feide.no:auth:method:sms`, check that the second field has the form `+4712345678` i.e. it should start with a country code and not contain any space or other special characters. For examples see the [MFA Examples](../reference/mfa/examples.html.md#ref-mfa-examples). # Browser support This page documents the supported web browser versions in Feide. For browser support, we separate our systems into two categories: * Core login system * Other Feide web sites The core login system must support more platforms and devices than our other systems. ## Core login system These are the sites that end users access as part of logging into Feide services. These are the pages at `idp.feide.no` and `auth.dataporten.no`. The following browsers are supported and tested by us: * Edge 111 and newer on Windows 11 * Safari 15 and newer on Mac OS X * The most recent version of Safari on iOS * The most recent version of Chrome on Windows, Mac OS X and Android * The most recent version of Firefox on Windows ## Other Feide web sites These are other Feide web sites, for example the [Customer Portal](https://kunde.feide.no/) and the [documentation](../index.html.md). The following browsers are supported: * The most recent version of Edge on Windows 11 * The most recent version of Safari on Mac OS X * The most recent version of Chrome on Windows, Mac OS X * The most recent version of Firefox on Windows ## Passkey support Passkeys are a relatively new technology that allow users to log in without passwords, using cryptographic keys stored on their devices. Several features must be supported by the browser and operating system for passkeys to work as intended in Feide. The following browsers and operating systems support passkeys in Feide: * Safari on iOS 18.4 and newer, Safari on macOS 15 and newer * Chrome version 128 and newer * Edge version 128 and newer * Firefox version 122 and newer # Contact information The email address for Feide issues, both technical and administrative, is > `kontakt@sikt.no` To receive information about maintenance and updates to the Feide IDP, you can subscribe to the mailing list > `feide-updates@lists.sikt.no` Go to [https://lister.sikt.no/postorius/lists/feide-updates.lister.sikt.no/](https://lister.sikt.no/postorius/lists/feide-updates.lister.sikt.no/), choose “Subscribe” and follow the instructions. # FAQ * [I am making my service available to Norwegian schools through eduGAIN – why do I only see Feide as a organization?](edugain_feide_org.html.md) * [Why is my organization not in the organization drop down list?](org_missing.html.md) * [Can SAML metadata be dynamically updated?](dynamic_saml_metadata.html.md) * [I am trying to add SAML Metadata for a service in the customer portal, but getting errors about invalid data. What is wrong?](error_adding_saml_metadata.html.md) * [What do we need to do if we change the domain name of our service?](change_service_domain.html.md) * [What must be done when changing the certificate of our service?](change_service_certificate.html.md) * [What must be done when changing the certificate of our LDAP server?](change_ldap_certificate.html.md) * [What is openidp.feide.no used for?](about_openidp.html.md) * [How do we allow access to Feide from restricted client networks?](domain_access.html.md) * [Can Feide modify or tailor the attributes of a user?](modify_attributes.html.md) * [What are the Feide password requirements?](password_requirements.html.md) * [How can I test that two-factor authentication works for my account?](test_twofactor.html.md) * [Where can I look LDAP error codes up for Windows based systems?](ldap_error_codes.html.md) * [What do I as a Service Provider have to do when two organizations merge?](sp_org_merge.html.md) * [What must be done when a municipality changes its municipality number (kommunenummer)?](change_municipality_number.html.md) * [What must be done to change the realm (domain) of an organization?](change_org_realm.html.md) * [Feide and Shibboleth](feide_shibboleth.html.md) * [What are the implications of the Chrome 80 SameSite cookie change?](samesite_cookie.html.md) * [What does the error “redirect loop detected” / “omdirigeringsløkke oppdaget” mean?](redirect_loop.html.md) * [Do you provide an API to fetch userdata in bulk?](bulk_userdata_api.html.md) * [Problem with access to services activated for individual schools?](individual_school_access.html.md) * [How to check which organization numbers are registered in the host organizations user directory](individual_school_access.html.md#how-to-check-which-organization-numbers-are-registered-in-the-host-organizations-user-directory) # I am making my service available to Norwegian schools through eduGAIN – why do I only see Feide as a organization? Since Feide is a centralized login service, the only organization that your service will see in eduGAIN is Feide itself All Norwegian institutions will be available through Feide, and end users will be able to choose their home institution in Feide itself. See the [eduGAIN](../../service_providers/edugain/edugain_service.html.md) guide for more details about providing a service to Feide through eduGAIN. # Why is my organization not in the organization drop down list? Feide is an opt-in federation, meaning the organizations that have joined Feide need to explicitly approve the use of a service before end users can access it. If you would like to use a service, but don’t see your institution in the drop down, contact the helpdesk in your institution and ask them to activate the service, providing them with relevant information to identity it (e.g. the URL you used to access it). # Can SAML metadata be dynamically updated? SAML metadata is static and must be updated manually in the [Feide customer portal](https://kunde.feide.no/). # I am trying to add SAML Metadata for a service in the customer portal, but getting errors about invalid data. What is wrong? If the error says ‘This element is not expected’ it is most likely because there is an XML element in the wrong place. Order is significant in the SAML metadata XML. Ref: See section 2.3.1 in [https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf](https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf) # What do we need to do if we change the domain name of our service? This requires adding SAML metadata for the new domain. # What must be done when changing the certificate of our service? There may be two certificates in use at services connected to Feide: 1. The certificate used to secure communications to the web page (the https-certificate). > The Feide login system never communicates directly with your service. > Instead all communication goes through the end user’s web browser. > This means that there is no need to make any adjustments at Feide’s end when the https-certificate changes. 2. The certificate used in the SAML 2.0 service provider software. > SAML 2.0 allows service providers to sign and encrypt messages. > Feide does not require signed messages from service providers, and does not encrypt messages to the services. > The certificate configured in the SAML 2.0 software at the service is therefore not used by Feide, and can be updated any time the service requires it. # What must be done when changing the certificate of our LDAP server? As long as you switch to a new certificate issued by a public certificate authority, the certificate should already be installed at the Feide login service. See the [certificate requirements](../../reference/tls-requirements-ldap.html.md#ldap-certificate-requirements) for more details. # What is openidp.feide.no used for? It is used only for Feide guest users. Don’t use it if not explicitly told to by the Feide support team. # How do we allow access to Feide from restricted client networks? To be able to log into Feide services, end users need to be able to access the following domains from their browser: * idp.feide.no * auth.dataporten.no * api.dataporten.no * groups-api.dataporten.no # Can Feide modify or tailor the attributes of a user? Feide does not modify attributes it sends to services. # What are the Feide password requirements? Feide has no restrictions on character sets or length of passwords. # How can I test that two-factor authentication works for my account? You can test it [here](https://two-factor-test.feide.no/). # Where can I look LDAP error codes up for Windows based systems? Have a look at the [Microsoft documentation](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes). # What do I as a Service Provider have to do when two organizations merge? When two organizations merge their Feide user directories, you as a service provider will have to update any references to the users and organization at your end. This may be the Feide-ID of the user ([eduPersonPrincipalName](../../reference/schema/attributes/edupersonprincipalname.html.md#saml-attribute-edupersonprincipalname)), organization numbers for schools and school owners, the realm/domain of the organization, etc. The typical process is that the organizations merging contacts you regarding the merger. The new organization must provide you with a list of old and new user identifiers, and any other information that may change as part of the merger. You and the new organization must then agree on a time to make the change. At that time, you must update the data in your system. At the same time, the organization changes the configuration at their end, so that new user data is sent to the service. # What must be done when a municipality changes its municipality number (kommunenummer)? The municipality does not need to do anything. Feide only uses the municipality number during for invoicing, and we will update the municipality numbers at that time. # What must be done to change the realm (domain) of an organization? Short answer: It is possible, but very painful. The domain that is configured for the organization in Feide is used to identify the organization in multiple places. These include systems at Feide as well as at service provider. For this reason, it is impossible to run with both the old and the new domain during a transition period. The procedure to change domains is: 1. Set up new user directories in parallel with the old ones for users who are changing domains. 2. Send us connection details for the new directories, in order that we can test them. 3. Coordinate the changeover to the new domain with the providers of all services you use. All service providers who use the Feide ID to identify users in their systems have to update these identifiers. The time to change over must be coordinated with Feide as well as with all affected service providers. 4. At the scheduled time, the service providers update the user IDs and Feide changes the configuration. 5. After the changeover, the old user directories may be removed. # Feide and Shibboleth Feide and Shibboleth federations are based on the same concepts, but Shibboleth federations are somewhat different from Feide. In Shibboleth, it is common to have a mesh of IdPs and SPs, where each service that wants to integrate with a new institution must talk to the different organizations that operate IdPs. Feide operates one central IdP. A service integrates once with this central IdP, and Feide adjusts access according to the service provider’s and home organization’s requests. If your service already is integrated with a Shibboleth federation, you can easily integrate with Feide (or the other way around) if the following is in place: - Feide uses the SAML 2.0 protocol. You need to ensure that your service supports SAML 2.0, older versions are not compatible with Feide. - Feide requires the use of HTTPS. - Feide encourages single logout support. # What are the implications of the Chrome 80 SameSite cookie change? Starting on [February 17th 2020](https://blog.chromium.org/2020/02/samesite-cookie-changes-in-february.html) Google will start adjusting how Chrome 80 sends cookies between different sites. This might break services connected to Feide, and means service providers MUST take action to ensure their services will still be able to login using Feide in the future. The problem may affect logins, depending on how the service works, either for all, or some of the users. The problem will affect logouts when these are initiated from the Feide side, and may affect logouts initiated by the service. ## Details: SameSite Cookie behaviour change and Feide In Chrome 80 the default behaviour with regards to the [cookie attribute SameSite](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis#section-5.3.7) changes. Cookies without a `SameSite` attribute will be treated as `SameSite=Lax`. Prior to this change cookies could be used cross-site by default and the `SameSite` cookie attribute was opt-in. This change has implications for services connected to Feide. ### For services using SAML When Feide responds to an authentication request it uses the HTTP `POST` method, which means any application cookies previously set will not be sent as part of the response. Chrome has a temporary measure in place, where it still allows for sending these cookies if they are less than 2 minutes old, but please note that depending on how the service uses cookies, this might not be a sufficient stop gap. For logouts initiated by the service, depending on the configuration, `POST` might be used by Feide to send the logout response, which will also lack any application cookies. Normally, logout will not occur within 2 minutes, and so, the temporary measure will not apply either. For logouts not initiated by the service itself, the logout request is sent to the service in an iframe, and regardless of whether this is a `GET` or a `POST` request, no application cookies will be sent. ### For services using OpenID Connect If the authentication uses the response mode [form_post](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html#FormPostResponseMode), the response from Feide will trigger a `POST` request to the callback URL, which means that any application cookies previously set will not be sent in this case. The 2 minute window mentioned above will apply though, allowing sending of the cookies anyway if they are less than 2 minutes old. As noted above, this might not be a sufficient stop gap, depending on how the service uses cookies. ## Changes that need to be made on the Service Provider side All SAML applications, and any OpenID Connect applications that use the `form_post` response mode may be affected. If the application depends on cookies to reconcile the response with its internal state and the cookies are not marked as `SameSite=None` it is affected. To address the issue service providers are advised to: * Review the list of [unsupported browsers](https://www.chromium.org/updates/same-site/incompatible-clients). * Adjust applications or update libraries as needed to ensure that `SameSite=None` is used for cookies. Please refer to [SameSite cookie recipes](https://web.dev/samesite-cookie-recipes/) for guidance on how to implement this fix for your use cases. ## Changes being made on the Feide side *Please note that these changes only relate to the login service itself, and will* **not mitigate service specific issues** *as mentioned earlier.* * The cookies that Feide uses for its authentication services will be changed to specifically set the `SameSite` attribute to `None`. * There will be additional fallback cookies set (with a `_nss` suffix) to handle the case of legacy browsers that do not support the `SameSite=None` setting. # What does the error “redirect loop detected” / “omdirigeringsløkke oppdaget” mean? The Feide login system shows this error if a user has been sent back and forth between the service they are logging into and the Feide login system many times in a short period of time. After several round back and forth in a few seconds, Feide will display the “redirect loop detected” error message. To troubleshoot this error, you need to investigate why the service is sending the user back to Feide for authentication just after receiving a authentication response from Feide. The authentication response received from Feide will not change in any meaningful way once the user is logged in, so there is no reason to send the user back. Some suggestions: * Check if there is some problems with cookies or domain names on the service which causes the service to fail to create a session for the user when it receives the authentication response. It may be useful to look at the HTTP requests using the developer tools in your web browser. Check if there are any signs that the service sets cookies in one HTTP response that it does not receive in a later HTTP request. * Check the service logs to see if the service is rejecting the authentication response. This may have several causes, e.g.: * The user is not allowed access to the system. * The user is missing an attribute the service requires. Basically, what is going on is: 1. The user accesses the service. 2. The service sends the user to the Feide login system for authentication. 3. The user logs in using their username and password. 4. Feide sends an authentication response to the service. 5. The service sends the user to Feide for authentication. 6. Feide sends an authentication response to the service. (The user is already authenticated here, so they are not asked for their username and password.) 7. The service sends the user to Feide for authentication. 8. Feide sends an authentication response to the service. 9. The service sends the user to Feide for authentication. 10. Feide sends an authentication response to the service. 11. […] # Do you provide an API to fetch userdata in bulk? Not at the moment, though we recognize that there are legitimate use cases for this that can not be solved in the context of a user/login. If you have such a use case, feel free to contact us to let us know. # Problem with access to services activated for individual schools? The customer portal fetches information from Brønnøysundregisteret. The organization numbers in the user directory for the host organization must match. If they don’t, users will not get access to services that are activated for individual schools. **For service providers:** If you are a service provider and get feedback from users from a specific school that they can’t access your service: - Check if the service is activated for that school - Check that the user has an organization unit registered If the school has access to the service, then the problem may be: - The user may be registered at another school - The school may be registered with an organization number that doesn’t match the one in the National Register. - The user is not registered to a specific organization unit To solve this problem the host organization needs to either change the information for the organization unit/school or the user in their user directory. If this is not done, users don’t get the correct access to your and other services when they log in with Feide. **For host organization:** If you are a host organization and get feedback from users who can’t access a service that is activated for that individual school: - The user may be registered at another school - The school may be registered with a wrong organization number. - The user is not registered to a specific organization unit This must be updated in the host organization user directory, so their users get the correct access to services when they log in with Feide. *Checking user information:* Users can check which school they are registered at by logging in to [innsyn.feide.no](https://innsyn.feide.no) and checking their information. They can see which school they are registered with under the tab “Group affiliation”, filtering by group type “organization”. The IT department can check the information registered on the user in the school owner’s user directory ![Screenshot of the Group Affiliation tab at innsyn.feide.no](general/faq/images/school17.png) If the user is registered at the wrong school, this must be changed in the school owner’s user directory. The school owner needs to change the [eduPersonOrgUnitDN](https://docs.feide.no/reference/schema/info_go/go_attributter_ch02.html#edupersonorgunitdn). If the school is also the user’s primary school, the [eduPersonPrimaryOrgUnitDN](https://docs.feide.no/reference/schema/info_go/go_attributter_ch02.html#edupersonprimaryorgunitdn) must also be changed. If users doesn’t belong to any school, they don’t get access to services activated for individual schools, only services activated for the whole organization. *Checking if the organization number registered for the school is wrong* If the correct school is registered on the user, you need to check if the organization number in the school owner’s user directory matches the one in Brønnøysundregisteret. # How to check which organization numbers are registered in the host organizations user directory To check which organization numbers are registered in the user directory, run the [LDAP validator](https://docs.feide.no/reference/ldap_validator/index.html). You can also find schools with wrong organization numbers by looking at the Statistics tab in the customer portal. The list of schools is fetched from the Brønnøysundregisteret, so if a school is shown with an organization number instead of the school’s name in the statistic list, the organization number in the user directory doesn’t match. ![Screenshot of the Statistics tab in the customer portal](general/faq/images/school18.png) If the organization number is wrong, the correct number must be entered into the school owner’s user directory so it matches. Before changing the number, we recommend contacting service providers that have services fetching the organization number to update this in their systems if needed. You can see which services are fetching the organization number on “View user attributes in services” under the “Utility” tab in the Feide customer portal. # Home Organizations Home organizations include universities, colleges, municipalities and county councils, private schools and Sikt members. * [My groups](groups.html.md) * [Editing login methods](editing_login_methods.html.md) * [Feide login with Entra ID](feide_login_with_entra_id.html.md) * [Feide login with Google](feide_login_with_google.html.md) * [Feide login with ID-porten](feide_login_with_idporten.html.md) * [Feide login with Passkeys](feide_login_with_passkeys.html.md) * [How to activate a service in Feide](how_to_activate_services_in_feide.html.md) # My groups Audience for this information is administrators and IT staff at home organizations. In the [Feide Innsyn](https://innsyn.feide.no/groups) the end user can - get an overview of which groups he/she belongs to - and create or join ad hoc groups #### NOTE Management of ad hoc groups were previously available through [Min side](https://minside.dataporten.no). However, that site is discontinued in favour of [Feide Innsyn](https://innsyn.feide.no). ## Group overview When logging into [Feide Innsyn](https://innsyn.feide.no) and visiting [Group affiliation](https://innsyn.feide.no/groups) the end user will see a list of all the groups he/she belongs to that Feide is aware of. These groups can be filtered by group type and member roles, and origin from several sources: - The organization’s LDAP directory (the one connected to Feide). - A university’s FS database. - A lower or intermediate school’s teaching groups - Other databases/directories at the organization with a customized integration to Feide. - Ad hoc groups created by the end user. - Ad hoc groups which the end user is a member of, created by others. ## Ad hoc groups Creating your own groups is a convenient feature of Feide. Education is all about collaboration, interaction and communication - in different groups: big, small, official, non-official, permanent, temporary etc. All groups cannot and will not be registered in the official directories at the organization. Through [Feide Innsyn](https://innsyn.feide.no) end users are enabled to create ad hoc groups wherever needed. The ad hoc groups can be shared across all applications connected to Feide through OIDC/OAuth, as long as the end user has consented to this. ### Create a new group Ad hoc groups are created and managed by logging into [Feide Innsyn](https://innsyn.feide.no), and navigating to [Group affiliation](https://innsyn.feide.no/groups). 1. Find the button “Create ad hoc group”. 2. Give the group a name and description, and submit. # Editing login methods The host organization can manage which login methods the organization’s users will be able to choose in Feide’s login window. This allows the organization to select and set up external login methods such as Microsoft work or school account. The advantage of this is that the organization does not have to manage several authentication solutions with different user accounts. The logins available in Feide’s login window for the organization are controlled by the Feide administrator in Feide’s customer portal. This is done by editing the login methods on the organization tab. ![Screenshot showing login methods on the organization tab](home_organizations/images/Editinglogin1.png) Remember only to turn on login methods configured for all the users at the organization. Otherwise, the users will have problems logging in. So carefully read what is required for the current external login providers before enabling the login method. It may take up to 10 minutes before the login options are available in the organization Feide’s login window. ## Feide directory authentication Disabling Feide directory authentication removes Feide’s username and password fields from Feide’s login window. This means that users cannot log in with their regular account in the Feide directory but must always example login with their Microsoft work or school account, so they don’t need to log in again on services like Office 365 that have Microsoft’s login solution. This may be helpful to disabling Feide directory authentication if the organization has delegated all user authentication to external systems. ![Screenshot showing checkbox for enabling Feide directory authentication](home_organizations/images/feidedirectory.png) Feide’s functionality for strong authentication using SMS and authenticator client is still available if activated and configured. Be sure to select and test at least one external login provider beforehand for both employees and students. ## Passkey authentication Enabling passkey authentication allows users in the organization to register and log in using passkeys. This login method allows the user to log in without needing to remember usernames or passwords. This can increase security and improve user experience if users currently use username and password. Carefully read how this works and what the limitations are before you enable this login method for your organization. See the [Feide login with Passkeys](feide_login_with_passkeys.html.md) documentation for more information about passkey authentication in Feide. ![Screenshot showing checkbox for enabling Passkey authentication](home_organizations/images/passkeys.png) *Note:* If you are using Entra ID as an external login provider, please note that passkey authentication is a separate mechanism that does not involve Entra ID. This means that users with a passkey will be able to log in using their passkey instead of their Microsoft work or school account. ## External login provider The organization can control which login methods the organization’s end users will be able to choose on Feide’s login window. This makes it possible to authenticate with external login providers such as Entra ID, where the user logs in with their Microsoft work or school account or logs in with ID-porten where the user can log in with, for example, Bank ID or MinID. By delegating authentication to an external login provider, the user still has a complete Feide login with all information related to the user’s Feide account. Note that this requires the user to have a Feide account at the organization. If there are users who do not have or do not qualify for a Feide account, they cannot log in with an external login provider. The service can enable an alternative login method in Feide for those users. If the service configures this is available before the user selects affiliation on Feide’s login window, this is because they don’t belong to an organization. Carefully read what is required for the external login provider before enabling it in Feide. Only enable login providers that the organization’s users can use; otherwise, users will have problems logging in to services. Following external login provider, you can enable for your organization: - [Microsoft work or school account / Entra ID](feide_login_with_entra_id.html.md) - [Google Workspace account](feide_login_with_google.html.md) - [ID-porten](feide_login_with_idporten.html.md) Feide doesn’t have access to the errors in external login provider authentication. So, if a user has a problem with login in with an external login provider, only the IT department at the organization can help interpret the errors. This is because Feide only has access to login history before and after authentication with the external login provider is used. The problem may be something that Feide can predict example, by rules or set up in the external login provider. Example accused by the user using a network abroad or deactivating an account after a certain number of times a password has been entered incorrectly. # Feide login with Entra ID Entra ID is Microsoft’s login solution, and this is used for authentication on services like Office 365, Teams, and Outlook. To access these services, users must sign in with a Microsoft work or school account. With Feide login with Microsoft work or school account, it is easier for the users to log in to those services. The user can use the same account regardless of whether they need to log in to service in Feide or the Microsoft single sign-on ecosystem. It may be helpful to disable Feide directory authentication if the organization wants all users to sign in with a Microsoft work or school account when login in with Feide. Read more about this [here](editing_login_methods.html.md#feide-directory-authentication). Below are the steps to configure Feide login with Entra ID. ## 1. Same username in Feide and Entra ID To be able to authenticate a user in Feide using Entra ID, Feide must connect the user logging in using Entra ID to a Feide user of the organizations Feide directory. To connect the user, the following Entra ID claims are used: * `preferred_username`: The primary username that represents the user. This is normally the Entra ID User Principal Name, but depending on the Entra ID configuration it can also be other attributes. * `email`: The email address of the user. See the [Entra ID reference documentation](https://learn.microsoft.com/en-us/entra/identity-platform/id-tokens) for more details about these claims. Feide will match these claims with the `eduPersonPrincipalName` and `mail` attributes in the Feide directory. Either the `preferred_username` claim must match the `eduPersonPrincipalName` attribute, or the `email` claim must match the `mail` attribute. If the user does not have an email address in Entra ID, Feide will additionally try to look for the `preferred_username` claim in the `mail` attribute. If Entra ID does not include a domain name in `preferred_username`, Feide will add the domain of the organization when looking for the `eduPersonPrincipalName` attribute. ## 2. Add new value in the attribute for a strong authentication method (only for organizations using Strong authentication) Organizations can use Entra ID to implement multifactor and strong authentication at level 3 in Feide. This requires the organization to have enabled logging into Feide using Entra ID and requires the organization to have provisioned multifactor authentication in Entra ID adhering to the requirements for level 3 authentication. Once that is configured, you can allow a user to use Entra ID for level 3 authentication by adding the norEduPersonAuthnMethod attribute to the user in your LDAP user directory: ```default norEduPersonAuthnMethod: urn:mace:feide.no:auth:method:azuread - ``` This flag indicates that the user has had their identity verified and that the multifactor authentication method has been provisioned to the user securely. The requirements and guidelines for level 3 authentication with Entra ID are the same as for the other level 3 authentication methods in Feide. All level 3 authentications must satisfy identity proofing and authentication requirements in [Rammeverk for autentisering og uavviselighet i elektronisk kommunikasjon med og i offentlig sektor](https://www.regjeringen.no/no/dokumenter/rammeverk-for-autentisering-og-uavviseli/id505958/). Feide will set level 3 on the login if both the LDAP attribute for the account is provided, authentication methods are selected, and the MFA is used for authentication on a Microsoft account for work and education (Entra ID). For further details see our [MFA techincal specs Entra ID](../reference/mfa/technical_reqs.html.md#mfa-technical-ref-entra-id) ## 3. Adding the Feide Enterprise application The following is one of several ways to grant admin consent for the enterprise application. For more details, please see the [Entra ID documentation page](https://learn.microsoft.com//en-us/entra/identity/enterprise-apps/grant-admin-consent). ### Adding the Feide Enterprise applications In order to add the Feide Enterprise application, insert your tenant-id into the following URL and open it in a browser. Only `{tenant-id}` in the URL needs to be changed. URL: `https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id=48d2c7ce-eea9-40d0-99af-3c6a8657d3c3` You should then be taken to the following page to accept the terms of use: ![Screenshot of Microsoft login page page titled "Permissions requested". Shows the Feide application and that it requests permission to sign in and read user profile. There are two buttons, labeled "Cancel" and "Accept".](home_organizations/images/entra-id-permissions-requested.png) Having accepted the terms of use, you may be shown an error page from Feide. ![Screenshot of error page from Feide. The page contains a message that can be safely ignored.](home_organizations/images/error_adding_application.png) You can safely ignore this error page, but do verify that the application has been successfully added. ### Verifying that the application is added After completing step one, including accepting the terms of use, the application should be visible from the “all applications” page. ![Screenshot of Microsoft Entra ID "Enterprise applications" page. Shows the "All applications" sub page. The Feide enterprise application is shown in the application list.](home_organizations/images/entra-id-enterprise-applications.png) ### Approve access on behalf of the organization In the permissions page the administrator should be able to approve access on behalf of the organization. Verify that the admin consent is given by checking the column on the right: “Granted through.” Click the blue “Grant admin consent-” box if it is missing. ![Screenshot of the management page for the Feide application. Shows the "Permissions" sub page. The page contains a button labeled "Grant admin consent for ExampleOrg", and a list of permissions for the Feide application.](home_organizations/images/entra-id-permissions.png) After completing these three steps, a Feide-administrator should be able to administrate the remaining setup from the Feide Customer Portal. ## 4. Enable Entra ID in the customer portal Once the Feide Enterprise application is added, the Feide login with Entra ID can be activated in the customer portal. This is done by editing the login methods on the organization tab. ![Screenshot of the organization configuration page in the Feide customer portal. The screenshot shows the "Login methods" section. The section contains a button labeled "edit".](home_organizations/images/innloggingsmetoder.png) Check off for Azure AD / Microsoft account use and enter the tenant ID for the organization Entra ID. ![Screenshot of the login method configuration page in the Feide customer portal. The screenshot shows the "Azure AD" section. The checkbox for "Azure AD / Microsoft account" is checked. There is a tenant ID field with a placeholder value.](home_organizations/images/azuretenant.png) To save the change, click on Save at the bottom of the page. It may take up to 10 minutes before the login with a Microsoft account is available as an option in the organization Feide’s login window. # Feide login with Google Google login is used for authentication on services like Google Workspace for Education, Google Classroom, and Google Drive. To access these services, users must sign in with a Google account. Logging in to Feide using Google makes it easier for the users to access their services. The user can use the same account regardless of whether they need to log in to service in Feide or the Google single sign-on ecosystem. And, if the user is using a device, like a Chromebook, that is already signed in with a Google account, they can easily access Feide services without having to sign in again. #### NOTE There are some limitations to be aware of when using Google login with Feide. First, the normal Feide logout flow will not work with Google. When a user logs out of Feide, they will still be logged in to their Google account. * If a user is using a Chromebook, Feide will show an information message about how the user can log out of their device to complete the logout process. * If a user is using a different device, Feide will redirect the user to the Google logout page to log out of their Google account, and the logout process will end there. This means that Feide cannot log the user out of *other Feide services* that support SLO (Single Logout) when the user logs out of Feide. The user will need to log out of those services separately. Second, if a service requests a reauthentication of the user, Feide will show the login page, and a message explaining that Google does not support reauthentication, so the user will need to log in using a different method if applicable. Failing that, the user will need to log out of their Feide account and return to the service to log in again. And finally, there is no way for Feide to determine whether the user used a second factor when logging in to their Google account. For users requiring strong authentication in Feide, this means that they will need other methods available on the Feide side, and use one of these when required. Below are the steps to configure Feide login using Google. ## 1. Match Google email to Feide user To be able to authenticate a user in Feide using Google, Feide must match the user logging in using Google to a Feide user in the organizations Feide directory. To match the user, the `email` claim from Google containing the email address of the user is used. Feide will try to match the value of this email claim with the `eduPersonPrincipalName` and `mail` attributes in the Feide directory. Either the value must match the `eduPersonPrincipalName` attribute, or the value must match the `mail` attribute. In order to match the `eduPersonPrincipalName` attribute, the value from Google must have the same domain part as the organization’s Feide domain. For example, if the organization has the Feide domain `example.org`, the email address from Google must have the domain part `@example.org` for Feide to try to match the `eduPersonPrincipalName` attribute. If the email address from Google does not have the same domain part as the organization’s Feide domain, it can still match the `mail` attribute if there is a user in the Feide directory with a matching email address in the `mail` attribute. If multiple users match the email address from Google, Feide will not be able to determine which user is logging in and the login will fail. To avoid this, make sure that there is only one user in the Feide directory with a matching email address in either the `eduPersonPrincipalName` or `mail` attribute. ## 2. Enable Google login in the customer portal Feide login with Google can be activated in the customer portal. This is done by editing the login methods on the organization tab. ![Screenshot of the organization configuration page in the Feide customer portal. The screenshot shows the "Login methods" section. The section contains a button labeled "edit".](home_organizations/images/innloggingsmetoder.png) Toggle the Google checkbox to enable Google login for the organization. You will also need to provide the Google domain name used by your organization. If you have users in multiple Google domains that need to sign in to Feide, please fill in the *primary* Google domain, used by the majority of the users. Then contact Feide support to get the additional Google domains added to your Feide configuration. To save the change, click on Save at the bottom of the page. It may take up to 10 minutes before the login with a Google account is available as an option in the organization Feide’s login window. # Feide login with ID-porten ID-porten is a common national login solution in Norwegian for online public digital services. It consists of several different known login methods, including MinID and BankID on mobile. The advantage of using ID-porten is that the user is automatically authenticated in Feide at level 3 and does not have to log in again with a two-factor method managed by the host organization. To use Feide login with ID-porten, the users need to have their national identity number (norEduPersonNIN) in the host organization’s directory. This is a mandatory attribute for all users with an official Norwegian NIN, so almost all users should already have this registered. Activation of Feide login with the ID-porten is done in Feide’s customer portal. This is done by editing the login methods on the organization tab. ![Screenshot showing login methods on the organization tab](home_organizations/images/idportinnlogging.png) Then check off “ID-porten.” ![Screenshot showing checkbox for enabling ID-porten authentication](home_organizations/images/idporten.png) To save the change, click on Save at the bottom of the page. It may take up to 10 minutes before the login with ID-porten is available as an option in the organization Feide’s login window. ## ID-porten as strong authentication Authentication with ID-porten requires the organization to activate strong authentication in the customer portal. If the organization wishes to begin using strong authentication, they can read more about how this can be ordered [strong authentication document](https://www.feide.no/sterk-autentisering). ## Price for the use of ID-porten Sikt will invoice host organizations that use the ID-porten based on their share of the total number of ID-porten logins through Feide. The cost per login varies from year to year and is not set before Feide gets invoiced by Norwegian Digitalisation Agency/ID-porten because of their [payment model](https://samarbeid.digdir.no/id-porten/kostnadsmodell-id-porten/66). Sikt will re-invoice at the same price, and historically, the price has been around 0,35 Norwegian kroner including VAT per authentication. See the [terms of use with ID-porten login](https://samarbeid.digdir.no/digital-postkasse/bruksvilkar/69). Statistics of the number of logins are not yet available in the Customer Portal. If there is a need for statistics over login, contact Sikt at [kontakt@sikt.no](mailto:kontakt@sikt.no). # Feide login with Passkeys Passkeys is a login method that uses the WebAuthn standard to provide passwordless authentication. It allows users to log in using biometric data (like fingerprint or facial recognition) or a device PIN, depending on their device configuration. Passkeys can be stored on various devices, including smartphones, tablets, hardware keys and computers. To use passkeys as a Feide login method, the organization must enable it in Feide’s customer portal. This is done by editing the login methods on the organization tab. ![Screenshot showing login methods on the organization tab](home_organizations/images/passkeyloginmethod.png) Then check off “Passkeys.” ![Screenshot showing checkbox for enabling Passkeys authentication](home_organizations/images/passkeys.png) To save the change, click on Save at the bottom of the page. It may take up to 10 minutes before the login with Passkeys is available as an option in the organization Feide’s login window. ## Passkeys as strong authentication Authentication with Passkeys can be considered as strong authentication if the user used strong authentication when registering the Passkey. This also means that passkeys can be used as a second factor, when using another type of login or when step-up authentication is required. ## Technical details to consider before using passkeys as a login method - Passkeys require that the user’s device supports WebAuthn. Most modern devices and browsers support this standard, but some older devices may not. - Consider where you’ll need to access your account when creating passkeys. You can create device-bound passkeys that only work on a single device, or use a provider with passkey syncing (such as Apple, Google, or password managers) to create passkeys that work across all your devices. - If a user loses access to their device and has not set up alternative authentication methods, they may be locked out of their account. It is advisable to have backup authentication methods in place and not only rely on a single device/passkey. - Passkeys rely on public-key cryptography. Your device stores the private key, and Feide stores each passkey’s public key along with a credential identifier that links it to your account. - Depending on the device, browser, and operating system, the user experience for registering and using passkeys may vary and is out of Feide’s control. ## Administration of passkeys by users Users can register and manage their passkeys through their browser on [innsyn.feide.no](https://innsyn.feide.no/passkeys). They can add new passkeys, remove old ones, change the name of the passkey, see when it was created and last used. To register a passkey click on “Create passkey” and follow the instructions provided by the browser. The user may be prompted to use biometric data or a device PIN to complete the registration. ![Screenshot showing passkey registration interface](home_organizations/images/registerpasskey.png) After registering, the user will be able to use the passkey to log in to Feide by clicking on the “Login with passkey” option in Feide’s login window and following the prompts from their browser. ## Passkey Administration API For organizations that need programmatic access to manage passkeys on behalf of their users, Feide provides a REST API. This allows automated systems to list and delete passkeys for users within the organization. Creating passkeys can only be done by the users themselves through [innsyn.feide.no](https://innsyn.feide.no/passkeys). ### Getting Access To use the Passkey Administration API: 1. Register a service in the Feide Customer Portal 2. Apply for access to the “Feide administrasjons-API” datasource for your service 3. Once approved, your service will be mapped to your organization(s) — identified by the organization ID from the Customer Portal 4. You’ll be able to use your OAuth credentials (client_id and client_secret) to obtain tokens ### Authentication The API uses JWT authentication with OAuth 2.0 scopes. To authenticate: 1. Obtain an access token from Feide using your OAuth credentials 2. Exchange the access token for a JWT token with the required passkey scopes 3. Include the JWT in the Authorization header of your API requests The JWT token contains an `act` claim with your service’s `customer_portal_id`, which the API uses to determine which organizations your service is authorized to manage. For detailed instructions on OAuth authentication with Feide, see [client credentials flow](../service_providers/openid_connect/client_credentials_flow.html.md) and [JWT Token Exchange](../data_sharing/data_consumer/jwt_token_exchange.html.md). Example token exchange: ```bash # Get access token curl -X POST https://auth.dataporten.no/oauth/token \ -u ":" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d grant_type=client_credentials # Exchange for JWT with passkey scopes curl -X POST https://auth.dataporten.no/oauth/token \ -u ":" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \ -d "subject_token=" \ -d "subject_token_type=urn:ietf:params:oauth:token-type:access_token" \ -d "requested_token_type=urn:ietf:params:oauth:token-type:jwt" \ -d "audience=https://n.feide.no/datasources/d74b449f-857f-491d-96fe-32bfe044614b" \ ``` ### Authorization Each service is authorized to manage passkeys for one or more organizations. The API enforces this by: - Extracting the service ID from the JWT’s `act` claim (`customer_portal_id`) - Looking up which organizations the service is allowed to manage - Verifying the JWT scope matches the requested operation (`passkey.read` for listing, `passkey.delete` for deletion) - Returning 403 Forbidden if the service attempts to access passkeys outside its authorized organizations This ensures services can only manage passkeys for organizations they are explicitly authorized for. ### API Endpoints All endpoints are available under `https://api.feide.no/2/passkey/` For information on the available endpoints and their usage, see [passkey management API reference](../reference/apis/feide-api/passkey-management.html.md). # How to activate a service in Feide To give users access to a service, it needs to get activated by one of the Feide administrators of the organization. ![Screenshot of services in use at organization](home_organizations/images/schoolactivation1.png) Administration of services with Feide login is done in the customer portal under the tab “Services” in the menu. It shows an overview of which services are activated for your organization. To activate a new service, press “Activate a new service.” ![Screenshot of service search form](home_organizations/images/schoolactivation2.png) Search for the service you want to activate. You can search for both the name of the service and the service provider’s name. Click on the name of the service you want to activate. If you don’t have access to activate the service, you need to request access from the service provider. Press the “Activate this service” button. Then you get the choice between “activate for organization” or “activate for schools”. #### NOTE Activating services for individual schools is only applicable for organizations from the lower education sector. Before activating the service, an agreement on the processing of personal data (data processing agreement) between the host organization (data owner) and service provider (data processor) is required, and the host organization needs to do a risk assessment of information security in the service. Both parties must directly agree upon this, and Feide is not an involved part. Read more about the responsibilities of host organizations [here!](https://www.feide.no/vertsorganisasjoners-plikter) When pressing one of the activation buttons, you need to confirm that you are aware that the school owner needs to have an agreement for handling personal information (data processing agreement). Read more [here!](https://www.feide.no/vertsorganisasjoners-plikter) ![Screenshot of service activation dialog](home_organizations/images/school001.png) If you want to activate the service for all schools at the organization, click the “activate for organization” button. Please be advised that if you want to activate for the entire organization **after** access have been given to specific schools, you would have to deactivate the service for these schools before activating for the entire organization. If you activate the service for the organization, the service will be activated for the whole organization, including possible future units/schools and for users that are not registered under any units/schools, typically users that work in central IT at the organization. #### WARNING Make sure that the organization numbers are correct before activating services for individual schools. Read more on how this is done [in our FAQ](../general/faq/individual_school_access.html.md). If only some schools need the service, you can activate the service for individual schools with the same school owner by clicking on “activate for schools”. If only some schools have got access to activate the service, the option to activate for the organization is disabled. Contact the service provider to enable activation for the whole organization and not individual schools. ![Screenshot of service activation dialog](home_organizations/images/school001.png) When activating the service for individual schools, you mark the schools that want access to the service. Note that this does not include users that are not registered under any unit/school. Users who are not registered under any unit/school are typically users who work in central IT. ![Screenshot of form for service activation by individual school](home_organizations/images/school6.png) To activate the service, click on the “Finish”-button at the bottom of the page. Should you experience any problems with access for users even though the service is activated, [see our troubleshooting guide](../general/faq/individual_school_access.html.md). ## How to remove access or deactivate the service ![Screenshot of service admministration tab](home_organizations/images/school7.png) If a school needs to activate or deactivate the service later, this is done in the service’s administration tab by clicking on the “Edit activation for individual schools” button. If you want to deactivate the service for all users at the organization, this is done at the bottom of the page by clicking “Deactivate service”. # Service Providers As a service provider, users can log in to your service with Feide. * [Getting started](getting_started/index.html.md) * [Manage services connected to Feide](manage/index.html.md) * [Test users](test_users.html.md) * [Multifactor Authentication](mfa/index.html.md) * [Provide and protect data](provide_and_protect_data/index.html.md) * [Using SAML 2.0](saml/index.html.md) * [OpenID Connect/OAuth technical details](openid_connect/index.html.md) * [Check user existence](checkuser/index.html.md) * [eduGAIN](edugain/index.html.md) * [Provisioning users and groups](provisioning/index.html.md) * [Finding the organization domain name of a school](finding_domain_name.html.md) # Getting started This document outlines the process for getting started with Feide for service providers. * [Getting access to the customer portal](customer_portal.html.md) * [Adding Feide login to a service](add_feide_login.html.md) * [Getting started with OpenID connect](openid_connect.html.md) # Getting access to the customer portal To registerer and manage your organizations integrations with Feide, your organization needs access to the [Feide customer portal](https://kunde.feide.no). If your organization is not yet a service provider, register as a service provider in Feide. The first step is to fill out the [application form](https://www.feide.no/soknad-tjenesteleverandor), then we will assess whether you meet the requirements to become a service provider in Feide. Anyone who delivers digital services to the education sector can become service providers in Feide for free. This applies to both public and private, non-commercial and commercial service providers and Norwegian and international service providers. Once you have filled out the application form and we have registered your organization, you will get access to the customer portal. If your organization is already a service provider or host organization in Feide, you should have access. If you do not have access, another Feide administrator can add you as a new Feide administrator for their organizations in the customer portal. This is done under “Organization” by clicking on “Users and roles”. For new users with a Norwegian national identity number, choose “Add new user” and fill out the form. Then click on the newly created user and choose “Activate ID-porten”. An e-mail containing a link to authenticate with ID-porten will be sent to the registered e-mail address to the user. For users without a Norwegian national identity number, the user needs to create an account on [openidp.feide.no](https://openidp.feide.no/simplesaml/module.php/selfregister/newUser.php) as a prerequisite. After you have the openidp username choose “Add new foreign user” and enter the openidp username with the domain @rnd.feide.no as Feide ID. If the openidp username was “feide-user” the Feide ID would be “[feide-user@rnd.feide.no](mailto:feide-user@rnd.feide.no)”. It may take 10 minutes for these changes to be updated. # Adding Feide login to a service The process for adding Feide login to a service varies greatly between different services. Some services have built-in support for federated login / single sign on that can be used with Feide. Other services may required you to add a custom authentication plugin. ## Protocols Under the tab configurations you add configuration so that the Feide-system is able to communicate with the service. Feide supports two different authentication protocols: * [SAML 2.0](https://en.wikipedia.org/wiki/SAML_2.0) * [OpenID Connect](https://openid.net/connect/) Some services only need a single configuration, while others may need separate configurations for each organization with access to the service. Factors that may affect your choice of protocol is: * The OpenID Connect protocol in Feide is available for users from organizations that are connected to the newest version of Feide. Over 97% of all organizations that are connected to Feide are on the newest version including all the municipalities and county municipalities, but there are still a few organizations that do not have access. For an overview of which organizations have “OIDC” enabled, see [q.feide.no](https://q.feide.no) * Existing support in applications / frameworks: Some applications and web frameworks have built-in support for one of the protocols. In that case, it is usually easiest to use the protocol already supported. * Support for logging into mobile applications: The OpenID Connect protocol is simpler to use when logging into mobile applications. Using this protocol, you can now choose not to require a new login after eight hours, but leave the user logged in for a longer period, in line with what end users often expect from mobile applications today. * Using the OpenID Connect protocol allows your mobile application to directly get an OAuth 2.0 access token, that can be used to access APIs. * Using OpenID Connect a service can retrieve information about teachers and students in a group, without each student having logged in beforehand. For primary school, secondary school and upper secondary school retrieve information about grade level (Grep), courses, basis groups, teaching groups and possibly other groups. For Universities and university colleges the group data is from FS (Common Student System), which provides information which class, class, study program, field of study and subject affiliation * Complexity of the protocol: The OpenID Connect protocol is in general simpler than the SAML 2.0 protocol. * Do you service need to identify and authenticate international users or people outside the education? When using OpenID Connect a service can enable other login providers in addition to Feide login like ID-porten, eduGain and eIDAS. Read more about login providers when using [OpenID connect](../manage/openid_connect/login_providers.html.md). ## Integration methods Depending on the software used to implement the service and the architecture of the service, there are several methods that can be used to integrate the service with Feide. * Some software or software frameworks may already have support (either directly in the software or through plugins) for SAML 2.0 or OpenID Connect. * In some cases, authentication can be handled by a web proxy that runs in front of the software. This proxy can perform the Feide-authentication and pass user data to the application through request headers. * You can add support for Feide directly into the software. If you go for this solution, we strongly encourage you to use existing libraries that implement the SAML 2.0 protocol or OpenID Connect protocol. This is because the protocols can be very complicated, especially the SAML 2.0 protocol. ## Adding Feide login to the service Once you have decided on a protocol and integration method, you can add Feide login to the service. The exact method for performing this depends on the software, frameworks and libraries used. Please refer to the documentation of the relevant software for details about how to configure a SAML 2.0 / OpenID Connect integration. In general it will be something like the following: 1. Add any required plugins/components/libraries to the service. 2. Configure the software to connect to the Feide login system. For SAML 2.0 services, this is typically done via SAML 2.0 metadata. For Feide we have to SAML 2.0 metadata available, for the [test system](https://idp-test.feide.no/simplesaml/saml2/idp/metadata.php?output=xhtml) and the [production system](https://idp.feide.no/simplesaml/saml2/idp/metadata.php?output=xhtml). For OpenID Connect, we do not have a separate test system. but you can test without publishing the service. The OpenID Connect configuration is available in [OpenID Connect Discovery format](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationResponse) from [our login system](https://auth.dataporten.no/.well-known/openid-configuration). If the software supports [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html), you can configure the software with the following `Issuer`, and it should automatically fetch the required configuration: https://auth.dataporten.no 3. Determine what attribute groups your software needs to work. The user information is transferred to the service as attributes groups in the login response. The software can typically make the attributes groups available to your service in various ways. Think about what information the service needs to know about the user and host organization. Avoid requesting access to more information than the service needs to work. Some services only need to log in to ensure that there is a person associated with the education sector, while others need more to personalize the service for the user. If you find out later that the service needs more information about the user, you can add more attribute groups. For an overview of available attributes, see the section about our [attribute groups](../../reference/schema/attributegroups/index.html.md). ## Registering the service in Feide Once you have decided on a protocol and integration method, you can register the service in the Feide customer portal. ![Screenshot of services provided by the organization](service_providers/getting_started/images/services_provided.png) *Screenshot of services provided by the organization* When registering a new service, the steps of information that need to registered is showed in the left side under “Prepare for publication”. You need to fill out the required filed that are marked with \* to publish the service. Other details that are not required are optional to register but can be useful for the administrator at the host organizations and end users. ![Screenshot of registering a new service](service_providers/getting_started/images/register_new_service.png) *Screenshot of registering a new service* ### Adding information about the service Under the “About the service” tab you add details about you service. Take special care to fill in understandable details about your service, including name, description, logo and more. This information will be displayed to end users during login and on our [overview of services with Feide login](https://feide.no/tjenester-med-feide-innlogging). ### Selecting user information Under the “User information” tab you select which information the service needs to receive about the end user and the host organization, there you can choose what information the service should try to collect about end users as they login with Feide. The availability of the information depends on whether it exists in the host organizations user directory. The information is defined in the attribute groups and for an overview of available attributes, see the section about our [attribute groups](../../reference/schema/attributegroups/index.html.md). Some of the attribute groups is by the general public and Feide considered as semi-sensitive information. Those attribute groups are only released to service that actual need it to make a better service and/or can’t user other information. Therefore, it can only be added to a service by Sikt. Send an email to [kontakt@sikt.no](mailto:kontakt@sikt.no) and explain why the service requires this attribute group, and why it is not enough with another available information through Feide. Beware that some attributes groups and attributes in attributes groups are only available with SAML configuration or for OIDC configuration. ### Adding configuration Under the “Configuration” tab you add configuration/configuration to the services so, the Feide-system can communicate with your service. Some services only need a single configuration, while others may need separate configurations for each organization with access to the service. Feide supports two different authentication protocols: SAML 2.0 and OpenID Connect/OAuth. * [Manage SAML 2.0 services](../manage/saml2/index.html.md) * [Managing OpenID Connect applications](../manage/openid_connect/managing_applications.html.md) If you are integrating with OpenID Connect/OAuth protocol you can enable other login providers in addition to Feide login like ID-porten, eduGain and eIDAS. This is done for service that need to identify and authenticate international users and/or people outside the education and not only users with Feide users. Enabling other login providers is done when adding or editing the OIDC-configuration. Read more about login providers when using [OpenID connect](../manage/openid_connect/login_providers.html.md). If you have configuration that need to be moved for another service registered under the same organization, you can move them your self-clicking “Move configurations” under the more menu (…) for the specific configuration. If the configuration needs to be moved across service provider contact us at [kontakt@sikt.no](mailto:kontakt@sikt.no), and we will move configuration to the right service provider for you. ## Testing the integration When the service is registered in Feide, you can test the integration before publishing it. For information about the test users, including how to access them, see our [documentation about test users](../test_users.html.md). ![Screenshot of enabling Feide test users](service_providers/getting_started/images/enabling_feide_test_users.png) See “[logging in using test users](../test_users.html.md#test-users-login)” for information about how to log in using test users. Be sure to **disable Feide test user** before you move your service to a production environment. ### How to enable Feide login If your users are students, researchers, teachers or other employees in Norwegian education, you probably want to enable Feide login. In the [Feide customer portal](https://kunde.feide.no/)., you can enable which organizations or individual school that get access to activate the service when editing the service. When a service is published, the organizations that should have access, must be granted access. After access have been granted, each individual organization must actively choose to activate the service.This is done in Feide’s customer portal by a Feide administrator at the host organization. There they can search for the service by; the name of the service, name of the service provider, and/or service description. After the service has been activated by the organization it will be an option in the Feide login for the user and the user can login to the service. Do your service need to identify and authenticate international users or people outside the education? When using OpenID Connect, a service can enable other login providers in addition to Feide login. This is done under “configuration” tab. More information about login provider available at [OIDC configuration](../manage/openid_connect/login_providers.html.md). NB! Feide is an opt-in this means that before an organization can use a service, you as service provider need to give access and the organization must activate login to the service before the service is available for the user at the organizations. ![Screenshot of publishing the service](service_providers/getting_started/images/publishing_service.png) *Screenshot of publishing the service* You can remove the service and we recommend that all service that are no longer in uses get removed for a better overview of available services. If you are still testing the service, we recommend that you unpublish the service or removes the services from public list and API. If you choose to unpublish the service is no longer available in the service search for the host organizations and cannot be activated. If you only removed the service for public list and API the service gets removed from list like [the list of available services in Feide](https://feide.no/tjenester-med-feide-innlogging) but is still available in-service search. ![Screenshot of publishing the service](service_providers/getting_started/images/status_of_the_service.png) *Screenshot of status of the service* # Getting started with OpenID connect The customer portal allows Feide administrators to register and manage applications. ## Authentication Authentication in Feide can be done using OpenID Connect or SAML. OpenID Connect (OIDC) is the standard for identity verification on top of OAuth 2.0 token based authorization, and is widely used on the web. With OIDC, the application gets verified information about the user’s identity as well as an access token which it can use to access a set of APIs. ## Setting up your application On the customer portal you will get details and credentials to set up your application as an OpenID Connect (OIDC) relying party. If your client already supports OIDC or OAuth 2.0, remaining work may just be some simple configuration. Otherwise, here is more information about how to use OIDC with Feide: - [OpenID Connect/OAuth technical details](../openid_connect/index.html.md) - [OpenID Connect details](../../reference/oauth_oidc/openid_connect_details.html.md) - [OpenID Connect userinfo endpoint](../../reference/apis/userinfo.html.md) In the customer portal you can configure which login providers under configuration tab or under host organization you will enable for the end users. Your configuration here will be reflected in the available login options for the end users during login. [See the login flow](../openid_connect/feide_obtaining_tokens.html.md#obtaining-access-token) ## Using the Groups API #### NOTE If you are unable to find the information you are looking for at OIDC `userinfo` or in the `id_token`, it will often turn out that it is available through the groups API. This API depends on OpenID Connect, but isn’t part of it. Hence, it is not covered by OIDC libraries, or by OIDC documentation and examples available on the net. A user’s relationship to schools, workplaces, classes, subjects and more are expressed as group memberships. When your application is given a valid access token with one or more of the attribute groups `groups-org`, `groups-edu` or `groups-other`, you will be able to access the groups API to get information about the current group affiliations of the current user. - [Data model and API for groups in Feide](../../reference/apis/groups_api/index.html.md) ## Using Third-Party Data Sources One of Feide’s key features is the ability to access data sources from third parties. The platform supports publishing, discovering, and managing access to these data sources. - [Data Sharing](../../data_sharing/index.html.md) # Manage services connected to Feide This document describes how you can use the [Feide customer portal](https://kunde.feide.no/) to mange your service integrations with Feide. * [Getting access to the customer portal](../getting_started/customer_portal.html.md) * [Manage SAML 2.0 services](saml2/index.html.md) * [Registering and managing OpenID Connect services](openid_connect/index.html.md) * [How to manage access to services through Feide](access_to_services/activation.html.md) # Manage SAML 2.0 services SAML 2.0 metadata is the configuration information that tells the Feide login system how to talk to your service. See our [reference documentation](../../../reference/saml/saml2_technical_guide.html.md#reference-saml2-metadata) for more information. All SAML 2.0 services must have one or more metadata entries registered. These are different instances of the service. In some cases, the service only needs a single metadata entry, which covers all users of the service. In other cases, the service design requires you to add a separate metadata entry for each organization using the service. The latter is typically the case where you have a separate domain for each organization. After [registered the service](../../getting_started/add_feide_login.html.md) you can add SAML-configuration for the service by clicking “Add OIDC-configuration” under the tab configurations. ![Screenshot of configuration tab when registering a new service](service_providers/manage/saml2/images/register_new_saml_config.png) *Screenshot of configuration tab when registering a new service* For service that have multiple configurations like needs separate configurations for each organization with access to the service you can enter different name for the configuration to separate multiple configurations in the field “Configuration name”. The name will be displayed when logging in to the configuration as follows: “You must log in via Feide to access - ”. ![Screenshot of adding configuration name](service_providers/manage/saml2/images/config_name.png) *Screenshot of adding configuration name* In the field “Login page for this configuration” you can add URL for the configuration login page. This is practical for services with multiple configurations and have separate login pages for each host organization. ![Screenshot of adding URL for login page](service_providers/manage/saml2/images/adding_url_for_login_page.png) *Screenshot of adding URL for login page* ## Adding metadata Under “XML Metadata” you add SAML 2.0 metadata for the configuration. SAML 2.0 metadata is configured in a XML format. This is typically provided by the SAML 2.0 software / library used in the service. In some cases the metadata is provided as two or three separate pieces of information (`entityID`, `AssertionConsumerService` and `SingleLogoutService`). In that case, you can use the “Generate metadata”-button to generate XML metadata from that information. ![Screenshot of adding metadata](service_providers/manage/saml2/images/adding_metadata.png) *Screenshot of adding metadata* There are two federations you can add metadata to in Feide. The Feide production environment and the Feide test environment. The Feide test environment is located at [https://idp-test.feide.no](https://idp-test.feide.no), and is available for testing services. You can also add production metadata for our production environment at [https://idp.feide.no](https://idp.feide.no), but it will not be active before the service is published. Check off “This configuration applies to the test environment ([https://idp-test.feide.no](https://idp-test.feide.no)), not the production environment. In this way, the integration can be tested before registering the service to Feide” if it applies for Feide test environment. ## Test users The “Test users” section allows you to enable login with Feide test users. For more information about the test users, including how to access them, see our [documentation about test users](../../test_users.html.md). ![Screenshot of enabling test user to login to SAML-configuration](service_providers/manage/saml2/images/enabling_test_users_to_saml_config.png) Once you have enabled a group of test users, you can log in by selecting either “Feide test users” (“Feide testbrukere”) or “Feide service providers” (“Feide tjenesteleverandører”) on the login page. See “[logging in using test users](../../test_users.html.md#test-users-login)” for more details. #### NOTE Remember to deactivate test users for your production service when you are not using them. The test users are publicly known, so others may be able to use the test users to access your service. ## Restricting access If you have multiple configurations for the service, where only one organization should be able to use this instance, you can configure this using the “Restrict login to selected organizations”-checkbox. This means that only host organizations that are added for the configuration appear as a login option in Feide for the configuration even if they have activated the service. If you choose to use the option to restrict login to selected organizations, you need to keep an eye on who has access for each configuration so it’s up to date. ![Screenshot of restrict login to the configuration](service_providers/manage/saml2/images/restrict_login_to_the_configuration.png) *Screenshot of restrict login to the configuration* # Registering and managing OpenID Connect services Here you will find documentation about how to get started for application developers. * [Managing OpenID Connect applications](managing_applications.html.md) * [Login providers](login_providers.html.md) * [Redirection after logout](redir_etter_logout.html.md) # Managing OpenID Connect applications After [registered the service](../../getting_started/add_feide_login.html.md) you can add OAuth details to configure the service by clicking “Add OIDC-configuration” under the tab configurations. ![Screenshot of configuration tab when registering a new service](service_providers/manage/openid_connect/images/config_tab.png) *Screenshot of configuration tab when registering a new service* Redirect URL after login is the URL where the client is redirected back to after authentication. This should be available in the documentation of the software you are about to install. The Redirect URI can be changed later. [Read more in our technical specification](../../getting_started/openid_connect.html.md) about Feide and OIDC/OAuth. Redirect URL after logout is the URL to control where the user is redirected after logging out. The application must also include the URI in the logout request. [Read more her](redir_etter_logout.html.md) ![Screenshot of adding redirect URI for OIDC-configuration](service_providers/manage/openid_connect/images/oidc_redirect_uri.png) *Screenshot of adding redirect URI for OIDC-configuration* For service that have multiple configurations like needs separate configurations for each organization with access to the service you can enter different name for the configuration to separate multiple configurations in the field “Configuration name”. The name will be displayed when logging in to the configuration as follows: “You must log in via Feide to access - ”. ![Screenshot of adding name for OIDC-configuration](service_providers/manage/openid_connect/images/oidc_config_name.png) *Screenshot of adding name for OIDC-configuration* In the field “Configuration login page” you can add URL for the configuration login page. This is practical for services with multiple configurations and have separate login pages for each host organization. ![Screenshot of adding login page for OIDC-configuration](service_providers/manage/openid_connect/images/oidc_adding_login_page.png) *Screenshot of adding login page for OIDC-configuration* ## Restricting access If you have multiple configurations for the service, where only one organization should be able to use this instance, you can configure this using the “Restrict login to selected organizations”-checkbox. This means that only host organizations that are added for the configuration appear as a login option in Feide for the configuration even if they have activated the service. If you choose to use the option to restrict login to selected organizations, you need to keep an eye on who has access for each configuration so it’s up to date. ![Screenshot of restrict login to the configuration](service_providers/manage/openid_connect/images/oidc_restrict_login_access.png) *Screenshot of restrict login to the configuration* ## Test users The “Test users” section allows you to enable login with Feide test users. For more information about the test users, including how to access them, see our [documentation about test users](../../test_users.html.md). ![Screenshot of enabling Feide test users for OIDC-configuration](service_providers/manage/openid_connect/images/oidc_enable_test_users.png) Once you have enabled a group of test users, you can log in by selecting either “Feide test users” (“Feide testbrukere”) or “Feide service providers” (“Feide tjenesteleverandører”) on the login page. See “[logging in using test users](../../test_users.html.md#test-users-login)” for more details. #### NOTE Remember to deactivate test users for your production service when you are not using them. The test users are publicly known, so others may be able to use the test users to access your service. ## Allow other login methods With OpenID Connect services using Feide can enable a variety of login providers. In addition to allowing login for users from Norwegian educational institution, you can also allow users to login using ID-porten, eduGAIN and more. See the [login providers overview](login_providers.html.md) for more details. ## Using third-party data sources Feide allows institutions and data owners to make available new datasets that will be very easy to use for application developers. If you are interested in setting up your own data source: [Data sharing](../../../data_sharing/index.html.md) The available data sources are shown in the “data sources” tab in [the customer portal](kunde.feide.no). ![Screenshot from customer portal showing available third-party data sources](data_sharing/images/datasharing1.png) Data sources that you have made available yourself will be visible in the “Provided by ** tab, while all others will will be available in the “All data sources” tab. Some data sources may be made available instantly without moderation, while others may require moderation. # Login providers Using Feide, you probably want to authenticate people using your service. Through Feide you can enable several login providers. You - as a service provider - decide which login providers your service should accept. Here you will find more information about the different login providers, how to enable them and when to enable them. In the [customer portal](https://kunde.feide.no/) you can enable the following login providers for your service: - [Feide](#login-provider-feide) - [ID-porten](#login-provider-idporten) - [International education login, eduGAIN](#login-provider-edugain) - [eIDAS](#login-provider-eidas) - [HelseID](#login-provider-helseid) - [TSD](#login-provider-tsd) - [Feide guest users](#login-provider-feideguest) - [Feide test users](#login-provider-feidetest) (for test purposes only) - [Feide service providers](#login-provider-spusers) (for test purposes only) ## Which login providers should you enable? You need to make sure all your users are able to log in to your service, but **you should probably not enable all login providers**. That will just make your users confused. ### Guidelines on enabling login providers - When your users are **students, researchers, teachers** or other employees in Norwegian education: Enable **Feide** login. - If you need to identify and authenticate users outside the education sector (i.e. **parents, alumni**): Request enabling of **ID-porten** login for your service. - If you need to identify and authenticate users from the Norwegian health sector, request enabling of **HelseID** login for your service. - If you need to identify and authenticate users from “Tjenester for Sensitive Data”, request enabling of **TSD** login for your service. - When your users are **international** students, researchers or teachers/employees: Enable **eduGAIN** login. - If your users are in the EU but not students, researchers or employees at an institution with eduGAIN, you should request enabling of **eIDAS** login for your service. - If some of your users come from **outside of the education sector**, and all you need is a way to recognize them and link them to a user account, you should enable **Feide guest user** login. - During **development and test phase**, you can enable **Feide test users**. Be sure to disable before moving on to production environment. ## How to enable Feide login If your users are students, researchers, teachers or other employees in Norwegian education, you probably want to enable Feide login. In the [Feide customer portal](https://kunde.feide.no/), you can enable which organizations or individual schools that get access to activate the service when editing the service. Read more here on [How to manage access to services through Feide](../access_to_services/activation.html.md). ## How to enable enabling other login providers To identify and authenticate those who don’t have Feide accounts, the service can use other login providers through Feide. You - as a service provider - decide which login providers your service should accept. By using other login methods, the service will only receive the information available from the specific login provider and will not necessarily receive all the attributes that are defined in the user information tab for the service in the Feide customer portal, as the information could not be retrieved from the host organization’s directory. What specific information is available you can check under each login method. You can enable other login providers in addition to Feide login when adding or editing OIDC-configuration for a service in the [Feide customer portal](https://kunde.feide.no/), Some of the login providers can only be enabled by Sikt upon request due to specific requirements for use. ![Screenshot of available login providers](service_providers/manage/openid_connect/allow_other_login_methods.png) If you enable all login providers, this is what your users will see the first time they log in: ![Screenshot of available login providers](service_providers/manage/openid_connect/available_login_providers.png) ## How to enable ID-porten login If your users are people outside of education, i.e. parents or alumni, and you still want a high security level on your logins, request enabling of ID-porten login for your service. When the user logs in to your service with ID-porten, your service will receive information from ID-porten, e.g. the user’s name and Norwegian national identification number. To enable ID-porten, the following criteria must be met: - The service must be registered by an organization (not a private person). - The organization must apply for ID-porten login by sending an email to [kontakt@sikt.no](mailto:kontakt@sikt.no). Be sure to put “ID-porten login through Feide” in the subject and with a description of why the service needs ID-porten. - Only enterprises in public sector and enterprises carrying out tasks on behalf of, and wholly or partly funded by, the public sector can use ID-porten. More information about ID-porten terms of use (Norwegian only). Sikt will invoice the service providers and host organizations that use the ID-porten based on their share of the total number of ID-porten logins through Feide. The invoice will be sent to the service provider when the user logs in with alternative login. If the host organization has enabled ID-porten as an external login method or multi-factor authentication, the host organization is invoiced. The cost per login varies from year to year and is not known before Feide gets invoiced by DigDir/ID-porten because of [their payment model](https://samarbeid.digdir.no/id-porten/kostnadsmodell-id-porten/66). See the [terms of use](https://www.uninett.no/id-porten-betingelser-og-priser) with ID-porten login. ID-porten as another login method should not be confused with ID-porten as external login and multi-factor authentication that a host organization can enable for their users. When a host organization has enabled ID-porten, you as a service provider will not see the difference between user login through ID-porten with Feide and direct logins with Feide. Your service will receive the same attributes in each case. Note that only user with a Feide account can use ID-porten with Feide as a login method. ## How to enable international login through eduGAIN If your users are international students, researchers, teachers or other employees, you should enable eduGAIN login. eduGAIN is an international trust exchange between Identity federations mostly in Europe, but also US, Brazil, Japan and more. It allows users abroad to login to Feide services with their local accounts, with trusted identity information through eduGAIN. The global scope of eduGAIN adds some complexity when it comes to technical compatibility, semantics of attribute release and more. Feide tries to offload these challenges from applications and adopt a flexible attribute policy that works with many providers. There are some limitations to using eduGAIN with OIDC. Not all information you can get about the user through eduGAIN with SAML-integration is available for OIDC services. The information that can be retrieved is name, e-mail and user identifier. We do not support affiliation information through eduGAIN for OIDC services. It is not straight forward for Feide to facilitate and it requires some work on our part, and since there are only a few Feide services that offer login through eduGAIN, this is not something that can be prioritized working on right now. Hopefully information about affiliation is something that will be available in the near future. You can enable eduGAIN when adding or editing OIDC-configuration for a service in the [Feide customer portal](https://kunde.feide.no/) under “Allow other login methods”. For services that are integrated through Feide with OIDC, the international universities need to first activate the service Dataporten provided by Sikt before activating your service. To enable eduGAIN login on Feide, you MUST follow these eduGAIN policies: - [GÉANT Data Protection Code of Conduct](https://www.geant.net/uri/dataprotection-code-of-conduct/v1) - [Research and Scholarship Entity Category](https://refeds.org/category/research-and-scholarship) ## How to enable international login through eIDAS If your users are in the EU but not students, researchers or employees at an institution with eduGAIN, you could request enabling of eIDAS login for your service. eIDAS is the European federation of citizen login and trust services and is connected to ID-porten. eIDAS gives individuals in the EU and the EEA access with one electronic id, and at the overall European level means that different countries approve each other’s solutions for authentication and user access. Norway participates in eIDAS, and this is administered via the ID-porten. As of February 2020, the following countries are connected in the production environment: Belgium, Croatia, Estonia, Italy, Luxembourg and Spain. When the user logs in to your service with eIDAS your service will get information available from the country’s electronic ID provider. Mandatory attributes with eIDAS are personal identifier, first name, last name and date of birth. More information about eIDAS and available attributes you find on Norwegian Digitalisation Agency technical documentation web site: [https://docs.digdir.no/oidc_func_eidas.html](https://docs.digdir.no/oidc_func_eidas.html). Follow the same procedure as when enabling ID-porten above. Use the subject “eIDAS login through Feide”. eIDAS can only be enable by Sikt and you need to request it to be enabled for you service. This is done by sending an email to [kontakt@sikt.no](mailto:kontakt@sikt.no). Be sure to send the name of your service and client ID or name of the configuration so it easier for us to activate it. ## How to enable login through HelseID #### WARNING This is a proof of concept implementation. It may be changed or discontinued at short notice. For users that don’t have a Feide account but have access to a valid HelseID account, you can request enabling of login through the “HelseID” solution. HelseID can only be enabled by Sikt and you need to request it to be enabled for you service. This is done by sending an email to [kontakt@sikt.no](mailto:kontakt@sikt.no). Be sure to send the name of your service and client ID or name of the configuration. HelseID is a login solution for healthcare personnel. HelseID provides an easy and secure way of login for personnel working within this sector. More information about HelseID can be found [here](https://www.nhn.no/tjenester/helseid/hva-er-helseid). When the user logs in to your service with HelseID, your service will today get information about the user’s Norwegian personal number that is available from HelseID. ## How to enable login through TSD #### WARNING This is a proof of concept implementation. It may be changed or discontinued at short notice. For users that have a TSD account, you can request enabling of login through the “TSD” solution. TSD can only be enabled by Sikt and you need to request it to be enabled for you service. This is done by sending an email to [kontakt@sikt.no](mailto:kontakt@sikt.no). Be sure to send the name of your service and client ID or name of the configuration. TSD is a login solution for “Tjenester for sensitive data”. More information about TSD can be found [here](https://www.uio.no/tjenester/it/forskning/sensitiv/mer-om/). When the user logs in to your service with TSD, your service will get information about the user’s TSD project and username that is available from TSD. ## How to enable login for Feide guest users For users who do not have a Feide account at a host organization, you can let them log in to your service by enabling the “Feide guest users” solution. This solution, also known as OpenIdP, is managed by Sikt. The service will only receive information about the name, username and email that the user self-registered when creating their Feide guest account. You can enable OpenIdP under “Allow other login methods” when adding or editing an OIDC-configuration for a service in the [Feide customer portal](https://kunde.feide.no/). ## How to enable Feide test users During the development and test phase, you can enable login for Feide test users. This is done by checking this box for test users when adding or editing OIDC-configuration for a service in the [Feide customer portal](https://kunde.feide.no/): ![Screenshot of enabling Feide test users](service_providers/manage/openid_connect/images/login_provider_testusers_enabled.png) Be sure to **disable Feide test users** before you move your service to a production environment. For more information about the test users, including how to access them, see our [documentation about test users](../../test_users.html.md). ## How to enable Feide service providers During the development and test phase, you can enable login for Feide service providers. These are personal user accounts for various service providers. Enable these users by checking the box for service provider users when adding or editing OIDC-configuration for a service in the [Feide customer portal](https://kunde.feide.no/): ![Screenshot of enabling Feide service providers](service_providers/manage/openid_connect/images/login_provider_spusers_enabled.png) Be sure to **disable Feide test users** before you move your service to a production environment. For more information about the test users, including how to access them, see our [documentation about test users](../../test_users.html.md). ## Phased out: Login through social media #### WARNING Logins with Twitter, Linkedin and Facebook were phased out from July 3rd, 2023. This is due to social media logins being very little used. We recommend services that have a need for social media login to integrate such login directly. # Redirection after logout It is possible to designate a page the user will be redirected to after logging out from a Feide service using OpenID Connect (OIDC). The page is given in the logout request from the service, and must be configured in the configuration on the service in the customer portal. The implementation conforms to the standard for [OpenID Connect RP-Initiated Logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout). The URL to redirect to has to be registered in [the customer portal](https://kunde.feide.no). Edit the service and select the configuration under the “configuration” tab or add a new configuration for a new configuration. Enter the URL in the “Redirect URI for logout field. You can also press [+ Add URI] and register multiple URLs. Finally, press “Save” at the bottom of the page. ![Screenshot of adding redirect URI for OIDC-configuration](service_providers/manage/openid_connect/images/oidc_add_redirect_uri.png) *Screenshot of adding redirect URI for OIDC-configuration* The logout endpoint can be found as the attribute `end_session_endpoint` at the discovery endpoint [https://auth.dataporten.no/.well-known/openid-configuration](https://auth.dataporten.no/.well-known/openid-configuration). On logout, the service should redirect the user’s browser to the logout endpoint. Feide will terminate the session for the service, and redirect the browser. The following parameters must be given: * **`post_logout_redirect_uri`:** URL to redirect the user to after logout. * **`id_token_hint`:** ID token that the service received on login. Used by Feide to identify the service, so that it can verify that the redirect URL matches one of those configured. If wanted, the service can add * **`state`:** if present, Feide will pass it on as a state parameter to the redirect URL. # How to manage access to services through Feide Does your service need to identify and authenticate international users or people outside the education sector? When using OpenID Connect, a service can enable other login providers in addition to Feide. This is done under the “configuration” tab. More information on different login providers is available at [OIDC configuration](../openid_connect/login_providers.html.md). If your users are students, researchers, teachers or other employees within Norwegian education sector, you probably want to enable Feide login. All public universities/colleges and primary schools, and several private primary schools use Feide today. You can find an overview of organizations that use Feide [here](https://q.feide.no/) . If the service is published, the organizations have access to activate the service. Each individual organization must actively choose to activate the service. Feide activation is opt-in, meaning you as a service provider can only give access to the organization. They in turn have the responsibility of activating the service before login becomes available to their users. Feide administrators at the host organizations can activate the service in Feide’s customer portal. There they can search for the service by: name, description, or name of its service provider. Only after the service has been activated by the organization can users login to the service by selecting their organization in the Feide login to the service. Choose which host organizations or individual schools will have access to activate the service in the customer portal under the “Host organization” tab when editing the service. You get an overview of which organizations have been given access to activate the service in the column “Given access” and which have activated the service in the “Activated” column. By clicking on a host organization, you see information about their support email, the date they have given access, and the date the service is activated. To see the names of the schools that have been given access or have activated the service, you need to click on “edit activation access.” You enable which organizations that get access to activate the service by clicking on “Edit activation access” in the right top corner of the page. ![Screenshot of enabling access to activate service](service_providers/manage/access_to_services/images/school01.png) When editing which organization that get access to the service you get an overview of all the organizations that you can give access to. The organizations that have been given access are marked with an icon on the left side of the organization name. The icon is a figure of an organization structure to illustrate if the whole organization has access to the service or if parts of the organization has access. If the whole figure is filled, the whole organization has access. If one of the boxes in the icon is filled, access has been given for individual schools. ![Screenshot of enabling access to activate service](service_providers/manage/access_to_services/images/school02.png) You can filter this view by type of organization on the right side. Type of organizations are: Primary and lower secondary schools, Upper secondary schools, Universities and university colleges or Other. “Other” are organizations like museums, research institutes, government bodies or student associations. If you want to give access to a specific organization or school, you can use the search field to find the organization. You can search for the name and organization number both for the organization that is the school owner and the organization units that are the schools. To give access to an organization click on the organization and select the access level. You can give access to the whole organization or individual units/schools. You enable which organizations or individual schools that get access to activate your service under the tab “Host organization”. - [How to give access to a service for the whole host organization](#srv-whole-org) - [How to give access to a service for individual schools](#srv-ind-schools) When you select an organization, it gets added to the access view on the right. ## How to give access to a service for the whole host organization The host organization is the school owner in primary and secondary education, i.e., the municipality or county municipality. If you give access to a municipality or county municipality, it will be given to all their schools including possible future units/schools. When editing access, you can select specific host organizations to give access to. Find the host organization and click on it. Then select “Entire host-organization including future units/schools”. When you select a host organization, it gets added to the access view on the right. Here you get an overview of which organizations you have selected to give access to. ![Screenshot of editing access to activate service](service_providers/manage/access_to_services/images/school0001.png) If you want to give access to all organizations, you can click on the “Toggle all organizations”-button. You limit this selection by selecting the type of organization on the right side of the page. By clicking on the button again you remove access to all the organizations including those that have activated the service. If you don’t want to save the changes, click on the “Cancel”-button at the bottom of the page so the host organization that has been activated or given access doesn’t lose that. Access will not be given until you save the changes. This is done by clicking “Save” at the bottom of the page. If you leave the page or click “Cancel”, the selected organizations will not get access to activate the service. ## How to give access to a service for individual schools #### NOTE If you get feedback from users from a specific school that they can’t access your service the wrong organization number may be registered or the user are missing the organization number. To solve this problem the host organization needs to either change the information for the organization unit/school or the user in their user directory. For further details [see our troubleshooting guide](../../../general/faq/individual_school_access.html.md). By giving access to “Individual units/schools,” you can select which schools in the municipality or county municipality to give access to. Note that this does not include users that are not registered under any units/schools. Users who are not registered under any units/schools typically work in central IT at the organization. When you select the schools, they get added to the access view at the right. In this view, you get an overview of which organizations you have selected to give access to. ![Screenshot of selected organizations granted access to activate service](service_providers/manage/access_to_services/images/school0002.png) Access will not be given until you save the changes. This is done by clicking “Save” at the bottom of the page. If you leave the page or click “Cancel”, the selected organizations will not get access to activate the service. ## How to remove access for organizations Services can remove access for organizations that have previously been given access, but not yet activated the service. This is done in the customer portal under the “Host organization” tab when editing the service, by clicking on “Edit activation access” in the right top corner of the page. ![Screenshot of removing access to a service](service_providers/manage/access_to_services/images/school015.png) Find the organization you want to remove access for. All the organizations that have been given access are at the bottom of the list, but you can use the search field to search after a specific organization or school. Click on the name of the organization to get the access options. If you want to remove access for the whole host organization, select “No access” ![Screenshot of removing access to a service with the override option](service_providers/manage/access_to_services/images/school016.png) If you only want to remove access to specific school(s) at the host organization, select “individual unit / schools” and remove the checkmark for the school(s) you want to remove access for. If the host organization has activated the service, you will get the following error message: “Disabled because organization is activated”. You can still remove the access for that organization by clicking on the override buttion as illustrated above. To update the changes, press “save”-button at the bottom at the page. When changes are saved, the organization must reactivate the service. So, make sure you really want to remove the access for the organization before you save the changes. If you don’t want to save the changes, press the “cancel”-button. # Test users When developing services with Feide login, you often need test users to test the login process. We have some standard test users that can be used for testing, but we can also create a couple of new test users if it’s necessary for testing the service. ## Getting access to test users Pick suitable test users for your needs from the [list of test users](../reference/testusers.html.md). To check what information is registered about a given user in more detail, log in as that user at [innsyn.feide.no](https://innsyn.feide.no/). ## Enabling test users in the service Test users are enabled for specific configurations in the customer portal. See the documentation for managing services for details: * [OpenID connect](manage/openid_connect/managing_applications.html.md#oidc-test-users) * [SAML 2.0](manage/saml2/index.html.md#saml-test-users) ## Logging in using test users Start login in the service and you should then be sent to the Feide login system. If your service is using OpenID Connect, you will arrive at a page where you can select the login method: ![Screenshot showing organization selection page with "Other login alternatives" section.](service_providers/manage/openid_connect/available_login_providers.png) Select “Feide test users” (“Feide testbrukere”) under “Other login alternatives” (“Andre påloggingsalternativer”) to log in using test users. If your service is using SAML 2.0, the page to select the organization is different. Here the test users are available in the organization drop down list: ![Screenshot showing expanded organization selection list.](service_providers/images/saml_login_select.png) Select “Feide test users” (“Feide testbrukere”) in this list to log in using test users. # Multifactor Authentication This document describes how services can ask Feide to initiate MFA and how to verify that MFA was used. * [Service-initiated MFA using SAML 2.0](saml.html.md) * [Service-initiated MFA using OpenID Connect](openid_connect.html.md) # Service-initiated MFA using SAML 2.0 When using SAML 2.0 the service will need to send a `saml:AuthnContextClassRef` element as part of the authentication request: ```xml https://sp.example.com/ urn:mace:feide.no:auth:level:fad08:3 ``` If the service uses SimpleSAMLphp this can be done using the `saml:AuthnContextClassRef` parameter at the start of authentication like so: ```php $auth->login([ 'saml:AuthnContextClassRef' => 'urn:mace:feide.no:auth:level:fad08:3', ]); ``` After authentication the service should check the `eduPersonAssurance` attribute in the response to verify the authentication level. Note that when using SAML 2.0 the response will contain an error if the user has no way of using MFA. # Service-initiated MFA using OpenID Connect When using OAuth/OpenID Connect the service will need to send the following parameter as part of the authentication request: > `acr_values=urn:mace:feide.no:auth:level:fad08:3` More information on the `acr_values` parameter can be found here: > [https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) After authentication, the `acr` field in the generated ID token should be used to verify the authentication level. # Provide and protect data * [Accessing data using JWT Token Exchange](../../data_sharing/data_consumer/jwt_token_exchange.html.md) * [Token exchange request from service](../../data_sharing/data_consumer/jwt_token_exchange.html.md#token-exchange-request-from-service) * [Successful response](../../data_sharing/data_consumer/jwt_token_exchange.html.md#successful-response) * [Token lifetimes](../../data_sharing/data_consumer/jwt_token_exchange.html.md#token-lifetimes) * [Legacy API Gatekeeper](legacy_api_gatekeeper.html.md) # Accessing data using JWT Token Exchange Data sources protected by Feide are normally configured in the [customer portal](https://kunde.feide.no/). The customer portal is used to configure policies for access to data sources and access levels. The data are accessed using [JSON Web Tokens](https://jwt.io/introduction/) (JWTs). The data consumer obtains an OpenID Connect (OIDC) access token. It exchanges it for another token tailored for the data source, carrying all information the source needs to determine what information the consumer may access. This token is a JWT. It is short lived and digitally signed, allowing the data source to verify that it was issued by Feide, intended for the source, and still valid. The exchange conforms to [**RFC 8693 - OAuth2.0 token exchange**](https://datatracker.ietf.org/doc/html/rfc8693.html). In order to access a data source, you need a Feide service registered in the customer portal. It may be a service that users log in to, or a headless service with no associated user. It needs an OpenID Connect configuration with rights to access the data source and the appropriate access levels within it. The data owner must approve access to the data, unless they have chosen to make the data source public. Access starts with an OIDC [access token](../../service_providers/openid_connect/feide_obtaining_tokens.html.md#obtaining-access-token). This could be the token the service receives when the user logs in, or a token which a headless service obtains with the [client credentials flow](../../service_providers/openid_connect/client_credentials_flow.html.md). Next, the service presents the access token to Feide and, if successful, receives back a JWT token for the data source. The request to Feide is a [token exchange request](#ref-token-exchange-request-from-service) to the token endpoint. For this request, grant type `urn:ietf:params:oauth:grant-type:token-exchange` is used. The response from the token endpoint is a [token exchange response](#ref-token-exchange-response), which, unless the request fails, includes a [JWT access token](../../reference/tokens.html.md#ref-jwt-access-token). With each request to a data source endpoint, the service includes the JWT as a bearer token in the `Authorization` header. The data source verifies the signature of the token and checks that it is still valid, issued by Feide and intended for the data source. Finally, it checks which access levels the token authorizes, and responds appropriately. ## Token exchange request from service #### NOTE This is for the case when a client wants a JWT to pass to a data source. See [Token exchange request from data source](../data_provider/accessing_feide_from_data_source.html.md#ref-token-exchange-request-from-datasource) for the case when a data source wants a regular access token to pass to Feide. A token exchange request includes `audience` and `scope` parameters. The `audience` must be the data source UUID registered in the customer portal, prefixed by `https://n.feide.no/datasources/`. Example: `https://n.feide.no/datasources/02d0f79b-7fbc-422b-bb31-a4d22121f040`. The valid values for scopes are the identifiers of the access levels which are registered in the customer portal for the data source. A token exchange request is made to the token endpoint using the HTTP “POST” method. Parameters are included in the HTTP request entity-body using the `application/x-www-form-urlencoded` format. The parameters are: audience : The UUID of the data source the JWT is intended for, prefixed by `https://n.feide.no/datasources/`. client_id : The ID of the application making the exchange request. client_secret : The client secret of the application. grant_type : The value `urn:ietf:params:oauth:grant-type:token-exchange` selects OAuth2 token exchange. scope : A space separated list of identifiers of desired access levels. It is up to the data source how to interpret them. subject_token : An access token obtained from Feide. It should give the application access to the access levels given as `scope` in the data source given as `audience`. subject_token_type : Must be `urn:ietf:params:oauth:token-type:access_token`. Here is an example: ```default POST https://auth.dataporten.no/oauth/token content-type: application/x-www-form-urlencoded audience=https://n.feide.no/datasources/02d0f79b-7fbc-422b-bb31-a4d22121f040 &client_id=208335d4-e8c1-4910-8928-05b2e5b14127 &client_secret=5df85658-d0c1-4348-890a-a204b24eca2e &grant_type=urn:ietf:params:oauth:grant-type:token-exchange &scope=read append &subject_token=96c5a3aa-1af8-45bd-a4f8-4b7fb07d393f &subject_token_type=urn:ietf:params:oauth:token-type:access_token ``` ## Successful response A successful response has status 200 and an `application/json` body with the following attributes: token_type : The type is `Bearer`. issued_token_type : The type is `urn:ietf:params:oauth:token-type:jwt`. access_token : The JWT that was issued. expires_in : Number of seconds until JWT expires. scope : The scopes that were granted. Here is an example: ```json { "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI...", "token_type": "Bearer", "issued_token_type": "urn:ietf:params:oauth:token-type:jwt", "expires_in": 299, "scope": "read append" } ``` For details on the JWT access token itself see the [reference documentation](../../reference/tokens.html.md#ref-jwt-access-token). ## Token lifetimes A JWT cannot be reliably revoked. Therefore, the lifetime is only 5 minutes. If the application needs access after the token has expired, it must obtain a new one. # Legacy API Gatekeeper #### WARNING Access to the legacy API gatekeeper could only be managed through Dataporten Dashboard, which is no longer available. If you need to make changes regarding APIs managed through the gatekeeper, please contact us at [kontakt@sikt.no](mailto:kontakt@sikt.no). # Using SAML 2.0 One of the methods that can be used to authenticate users in Feide is the SAML 2.0 protocol. [Security Assertion Markup Language (SAML) 2.0](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security) is a standard for federated logins and identity management. In Feide, the standard is used for authenticating users and during logout. The SAML 2.0 standard is large and covers many different use cases. To simplify interoperability, several profiles describing usage of the standard have been defined. Feide supports the following profile: * [Interoperable SAML 2.0 Web Browser SSO Deployment Profile](https://kantarainitiative.github.io/SAMLprofiles/saml2int.html) # OpenID Connect/OAuth technical details In these pages you will find detailed technical documentation about how to use our OpenID Connect and OAuth implementation. * [Security considerations](security.html.md) * [Obtaining tokens with Feide](feide_obtaining_tokens.html.md) * [Obtaining user information](obtaining_userinfo.html.md) * [Mobile applications](mobile_applications.html.md) * [Using Feide with Client Credentials Flow](client_credentials_flow.html.md) * [More OpenID Connect details](oidc_authentication.html.md) # Security considerations The community now has long experience with OIDC and OAuth 2.0 in practice, and recommendations have evolved. One important change concerns the implicit flow. It was always considered less secure than the others, but back when the standards were defined, it was the least bad solution for native apps and single page web applications. Best current practice is not to use implicit flow at all, but to use authorization code flow instead. Clients which are unable to keep secrets, i.e. native and single page apps, must combine it with [PKCE](https://oauth.net/2/pkce/). The only case where implicit mode is appropriate is if you have to support very old browsers which do not support cross origin resource sharing (CORS). Use TLS, and validate the certificates on all endpoints. To limit the consequences of security breaches, only request attribute groups that you actually need. The `longterm` scope lasts two years, and should not be used if the information protected is sensitive or valuable. If you find the default access token duration of 8 hours too long, you can set the OIDC `prompt` parameter to `login` and make the user log in again. Prefer OIDC over OAuth2 with the legacy Feide userinfo endpoint. Validate the ID token: - `iss` (issuer) must be `https://auth.dataporten.no` - `aud` (audience) must be your application - `exp` (expiry) must be sufficiently far in the future - `iat` (issued at) and `auth_time` must be in the past, but probably not too far in the past - The signature must validate If you have to use the legacy userinfo endpoint, make sure you validate `audience`. Protect against cross site request forgery (CSRF) attacks with PKCE or the `state` parameter to the authentication request. Use the native system browser for mobile applications. Avoid embedded web views. To protect from theft, store tokens in transient memory if possible. Do not share tokens with data sources or other third parties, as this would allow the data source to impersonate the client. Use [token exchange from data source](../../data_sharing/data_provider/accessing_feide_from_data_source.html.md) instead. Do not store client credentials in code or bundled resources. If an app has to authenticate to more than one OIDC/OAuth provider, e.g. a Feide app that consumes a cloud resource elsewhere, you should use different redirect urls for each provider. Otherwise, one provider may impersonate another. This section has only skimmed the surface. The best in-depth coverage is currently [**RFC 9700 - Best Current Practice for OAuth 2.0 Security**](https://datatracker.ietf.org/doc/html/rfc9700.html). There are also Best Current Practice documents specifically for native applications: [**RFC 8252**](https://datatracker.ietf.org/doc/html/rfc8252.html) and for [single page applications](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps). There is an IETF RFC [**RFC 6819 - OAuth2.0 Threat Model and Security Considerations**](https://datatracker.ietf.org/doc/html/rfc6819.html), and the OIDC standard has a chapter about [Security Considerations](https://openid.net/specs/openid-connect-core-1_0.html#Security). However, both are old and must be read in the light of the documents above. # Obtaining tokens with Feide Most of the APIs of the Feide platform require that you have obtained a token with OpenID Connect (OIDC). You need to register your application/client and implement or configure a flow. We recommend that you gain a basic understanding of OpenID Connect and OAuth before using the Feide platform. OAuth 2.0 is a general purpose framework for web authorization, and OIDC is an identity layer on top of it. - [Using OpenID Connect in Feide](../../reference/oauth_oidc/openid_connect_details.html.md) - [OAuth 2.0 tutorials and specification at oauth.net](https://oauth.net/2/) ## Registering your application In order to access the Feide APIs, you need to register your application and obtain credentials for it. This is done in the [Feide Customer Portal](https://kunde.feide.no/). When registering an application, you need to know the redirect URI endpoint for it. ![Screenshot of adding redirect URI after login for OIDC-configuration](service_providers/openid_connect/images/oidc_redirect_uri.png) *Screenshot of adding redirect URI after login for OIDC-configuration* **HTTP or HTTPS** For development you are allowed to use unsecured redirect_uri endpoints. This will result in warnings for the end user during login process. For an application in production you are required to only use HTTPS secured endpoints. When you have successfully registered an application, you need to know the OIDC/OAuth endpoints of Feide, in order to configure your application: Feide OIDC discovery endpoint: `https://auth.dataporten.no/.well-known/openid-configuration` The discovery endpoint will tell you that the other endpoints are: Feide OIDC/OAuth Authorization endpoint `https://auth.dataporten.no/oauth/authorization` Feide OIDC/OAuth Token endpoint `https://auth.dataporten.no/oauth/token` Feide OIDC Userinfo endpoint `https://auth.dataporten.no/openid/userinfo` **For mobile applications** you may want to use a custom URL scheme for your redirect URI, such as `yourapplication://`. ## Obtaining an Access Token To access the Feide APIs, you need an **Access Token**. The Access Token represents an authenticated and authorized session at your application for the end user. This way your application may obtain information on behalf of the end user. Consult the OpenID Connect and OAuth 2.0 Specifications for details about the protocols. - [OpenID Connect Core](https://openid.net/specs/openid-connect-core-1_0.html) - [The OAuth 2.0 Authorization Framework Specification (RFC6749)](https://datatracker.ietf.org/doc/html/rfc6749) Depending on the application mode, Feide supports three alternative authorization grant modes in OIDC/OAuth: - **Authorization Code Grant**, recommended for all application types. - **Implicit Grant**, formerly recommended for (client side only) web applications, mobile and desktop applications. - **Client Credentials Grant**, for special use when there is no end user represented. Implicit grant used to be recommended for mobile, native and single page applications, but best current practice is to use authorization code grant with [Proof Key for Code Exchange (PKCE)](https://oauth.net/2/pkce/). OIDC/OAuth 2.0 libraries are available for a wide variety of programming languages. ### Authorization Request Here is an example of how to obtain an Access Token using the authorization code flow. First, the client generates [an authorization request](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1), and redirects the user to this endpoint: ```http https://auth.dataporten.no/oauth/authorization? client_id=42934c73-6fae-4507-92a4-c67f87923aa9& response_type=code& redirect_uri=https://example.org/callback& scope=openid& state=whatever ``` ### User authentication and provider discorvery Feide handles the authentication of the user and informs the user about what permissions the client is requesting. Read more about [selecting user information](../getting_started/add_feide_login.html.md) and [login provider](../manage/openid_connect/login_providers.html.md) for you service. ![Screenshot of choose affiliation in Feide login page](service_providers/manage/openid_connect/available_login_providers.png) *Screenshot of choose affiliation in Feide login page* First, user has to select which login provider to use for login. Typically, this means selecting the educational home institution of the user. On all subsequent logins, the user will instead see the account chooser. #### Feide Login User enters his/her username and password to login. ![Screenshot of entering user credentials in Feide login page](service_providers/openid_connect/images/enter_credentials_in_feide_login.png) *Screenshot of entering user credentials in Feide login page* #### Authorization Grant User gets information about what permissions the client is requesting, and decides whether to accept this. ![Screenshot of accepting privacy policy in the Feide login page](service_providers/openid_connect/images/privacy_policy_in_feide_login.png) *Screenshot of accepting privacy policy in the Feide login page* ![Screenshot of accepting application right in the Feide login page](service_providers/openid_connect/images/accepting_application.png) *Screenshot of accepting application right in the Feide login page* ### Authorization Response In the authorization code flow, the [authorization response](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2) involves a redirect back to the redirect_uri endpoint at the client backend, where a `code` is one of the parameters. The `code` may then be replaced with an access token. ```http HTTP/1.1 302 Found Location: https://example.org/callback? code=0f8cf5fa-dc3f-4c9d-a60c-b6016c4134fa& state=f47282ec-0a8b-450a-b0da-dddb393fbeca ``` #### Implicit grant flow In contrast, with the implicit grant flow, the access token is returned directly at the redirect_uri, but within the hash fragment of the URL, leaving it accessible only to the frontend / client side. ### Fetching the Access Token The Feide OIDC/OAuth Token Endpoint requires the client to authenticate using the credentials obtained through the customer portal. The request is authenticated with HTTP Basic authentication using the client_id and the client secret. The client application performs an [Access Token Request](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.3) to the token endpoint: ```http POST /oauth/token HTTP/1.1 Host: auth.dataporten.no Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=0f8cf5fa-dc3f-4c9d-a60c-b6016c4134fa &client_id=57260bd1-fb74-485c-96a3-f0c7e96ed4db&redirect_uri=https%3A%2F%2Fexample.org%2Fcallback ``` Feide returns a valid Access Token associating the client with the authenticated end user and a set of permissions. The permissions are as requested in the customer portal and approved by the end user. ```http HTTP/1.1 200 OK Content-Type: application/json { "access_token":"083a7ef0-ea97-49ec-8804-379dc1e9b54c", "expires_in":28800, "scope": "openid userid profile groups" } ``` ### Using an Access Token To use the access token, it has to be included in the `Authorization` header of the HTTP request, like this: ```http GET /userinfo HTTP/1.1 Host: auth.dataporten.no Authorization: Bearer 083a7ef0-ea97-49ec-8804-379dc1e9b54c ``` The details are specified in the specifications: - [The OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC6750)](https://datatracker.ietf.org/doc/html/rfc6750) Now, as you have obtained a token for an authenticated user, you can move on to play with all the Feide APIs. The first thing you might be interested in is learning more about the authenticated user: - [Obtaining userinfo](obtaining_userinfo.html.md) # Obtaining user information Your application can receive user information as OpenID Connect claims in two ways: - In the [ID token](../../reference/tokens.html.md#ref-id-token) you receive during login. - From the OpenID Connect userinfo [userinfo](../../reference/apis/userinfo.html.md) endpoint It can receive user information as LDAP attributes from the [extended userinfo](../../reference/apis/attributes_feide/extended_userinfo.html.md#extended-userinfo) endpoint. It can receive information about user affiliations, e.g. schools, teaching groups and subjects, from the [groups API](../../reference/apis/groups_api/index.html.md) endpoints. # Mobile applications OIDC/OAuth is designed to work well with mobile applications. Typically the application will initiate login opening the system browser so that the user can enter credentials. Once the OIDC/OAuth flow has completed, Feide issues the ID token and access token and send them back to the mobile app. The app will use the access token to look up further information about who the user is, and maybe communicate with its backend using [Feide data sharing](../../data_sharing/index.html.md). Best current practice is to use authorization code flow with PKCE. Implicit flow is less secure, and no longer recommended. ## Authentication We strongly recommend that native apps use the system browser for the OIDC/OAuth flow. Embedded web views are less secure, and should not be used. The system browser can often be opened as an in-app browser tab, and this usually gives the best user experience. iOS has supported this since late 2015 (iOS 9), Chrome on Android since 2016 (Chrome 45). The native app must be reachable locally at a URL. The leading mobile operating systems now allow apps to claim `https` URIs in the domains they control, so that these URLs are opened in the app instead of in the browser. iOS and Android have supported this since late 2015 (iOS 9 and Android 6.0). Where available, this is the preferred mechanism. Register the redirect URI in the same way as for any other OIDC/OAuth client. To support older operating system versions, a custom URL Scheme for the native app must be used, such as `no.mycompany.mydataportenapp`. Best current practice mandates the reverse domain name pattern shown here. It reduces the risk of collisions, and if they occur, makes them easier to manage. In the customer portal, register a redirect URI such as `no.mycompany.mydataportenapp:/`. Then register a listener that is triggered when the app is opened with this scheme. This IETF document describes best current practice: [OAuth 2.0 for Native Apps](https://datatracker.ietf.org/doc/html/rfc8252) (RFC 8252). # Using Feide with Client Credentials Flow OIDC/OAuth defines many different flows, depending on the use case. One of these flows does not include an authenticated end-user. This is called the **Client Credentials flow**. This flow allows a client to immediately obtain an access token without involving any end users. This flow is typically used in system to system interactions. One use for the client credentials flow is in [data sharing](../../data_sharing/index.html.md). You can use the flow to obtain an access_token, and [exchange](../../data_sharing/data_consumer/jwt_token_exchange.html.md) it for a JWT which authorizes access to a third party API. ## Registering a client to use with client credentials flow Any client can be used with client credentials flow, and no special steps are needed during registration. ## Using Client Credentials flow Here are some references: - [OAuth 2.0 Specification section 4.4: Client Credentials Grant](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4) - [OAuth: Client Credentials](https://www.oauth.com/oauth2-servers/access-tokens/client-credentials/) To obtain an access token, the client must send a form POST request (`application/x-www-form-urlencoded`) to the Feide token endpoint with the body `grant_type=client_credentials`. The request should be authenticated with basic authentication with the client id and client secret. Feide will issue a token that is not associated with any end-user. Here is an example `curl` command to obtain an access token: ```shell export CLIENT_ID=4cc40647-0d56-4de2-9f8f-975ff1ca55a8 export CLIENT_SECRET=b54cbb37-1a75-41bc-8471-c44045d6b0e2 curl -X POST https://auth.dataporten.no/oauth/token -u $CLIENT_ID:$CLIENT_SECRET -d 'grant_type=client_credentials' ``` Here is an example of expected output: ```json "access_token": "9c256322-7c11-4220-93d6-fc5ffad3cb13", "token_type": "Bearer", "expires_in": 28799, "scope": "gk_kdto99 gk_tokenissuer" ``` ## Accessing protected APIs Notice the scopes for accessing third party APIs. They are all prefixed with `gk_`. Other scopes are mostly relevant only when a user is authenticated. For example, you may not use the userinfo endpoint with a token obtained through client credentials flow, even if the token has e.g. the `profile` and `email` scope. Accessing a protected third party API using such an access token is no different to using regular access tokens. ```http GET /foo/bar HTTP/1.1 Host: kdto99.dataporten-api.no Authorization: Bearer 9c256322-7c11-4220-93d6-fc5ffad3cb13 ``` ## Preparing a third party API for clients When preparing an API for use with a system client, make sure that you verify whether or not the request is a system request or an authenticated user request. Requests containing an `X-Dataporten-userid` header represent an authenticated user, and requests without this header are system requests obtained using client credentials flow. Depending on the use case, access both from systems and authentication users may or may not be acceptable. # More OpenID Connect details You can find more details about OpenID Connect at the link below: [OpenID Connect details](../../reference/oauth_oidc/openid_connect_details.html.md) Among other subjects, the page covers: - [Discovery and configuration](../../reference/oauth_oidc/openid_connect_details.html.md#ref-discovery) - [Client registration](../../reference/oauth_oidc/openid_connect_details.html.md#ref-registration) - [Scopes, claims and attribute groups](../../reference/oauth_oidc/openid_connect_details.html.md#scopes-claims-attribute-groups) - [Requiring a specific authentication level](../../reference/oauth_oidc/openid_connect_details.html.md#ref-auth-level) - [Login hints - bypassing the login discovery page](../../reference/oauth_oidc/openid_connect_details.html.md#ref-hints) # Check user existence Checking whether a user has an account at an organization is possible with the dedicated [check user existence endpoints](../../reference/apis/attributes_feide/check_user_existence.html.md). Users can be looked up by Feide ID (eppn) or by email address. These endpoints require the `system-check-user-existence` scope and the [client credentials flow](../openid_connect/client_credentials_flow.html.md). If your service also needs to retrieve user attributes, use the [user lookup API](../../reference/apis/attributes_feide/user_lookup.html.md) with the `system-all-users` scope instead. # eduGAIN The [eduGAIN interfederation](https://edugain.org/) connects federations in different countries and allows users from one federation to access services in different federations. Feide is connected to eduGAIN. This enables services connected to Feide to allow login for users from other federations, and it enables service providers connected to other federations to allow login for Feide users. * [Enable eduGAIN for a Feide service](feide_service/index.html.md) * [Enabling Feide-users to log into an eduGAIN service provider](edugain_service.html.md) * [Metadata Registration Practice Statement for Feide](feide_metadata_registration_practice.html.md) # Enable eduGAIN for a Feide service If you have a service connected to Feide, you can make that service available in eduGAIN. This allows users from other federations in different countries to log into your service. The process for enabling eduGAIN login for a Feide service depends on whether that service is using SAML 2.0 or OpenID Connect. * [Enabling eduGAIN login when using OpenID Connect](openid_connect.html.md) * [Enabling eduGAIN login when using SAML 2.0](saml2.html.md) # Enabling eduGAIN login when using OpenID Connect All OpenID Connect services in Feide appear as a single service provider in eduGAIN. To allow users to log into your service using eduGAIN, you need to enable eduGAIN as a login provider. See the documentation for the [eduGAIN login provider](../../manage/openid_connect/login_providers.html.md#login-provider-edugain) for details. # Enabling eduGAIN login when using SAML 2.0 The [eduGAIN interfederation](https://edugain.org/) service connects identity federations around the world, simplifying access to content, services and resources for the global research and education community. It is based in the SAML protocol and as a Service Provider in Feide using that protocol, you can also join eduGAIN to offer your services to other home institutions all around the world. ## Technical requirements In order for you to join eduGAIN as a Service Provider, Feide needs to publish your SAML metadata describing how to interoperate with you. This metadata will be published upstream to eduGAIN, and from there, all other member identity federations will publish your metadata downstream to their home institutions. We need therefore to receive your metadata, and you will need to pay special attention to the following: - The metadata you provide us with does not need to be exactly the same as you provided to Feide. It is entirely up to you, but it needs to reflect perfectly how other parties in eduGAIN can interact with your service using SAML. - This metadata must express your needs in terms of attributes by using the `md:RequestedAttribute` element defined in the SAML standard, one per each attribute you need. - The `NameFormat` for those attributes you need must be `urn:oasis:names:tc:SAML:2.0:attrname-format:uri`, and its `Name` should be expressed in such format. This is a difference compared to Feide, where we use basic names for attributes instead of OIDs. Of course, this means your Service Provider needs to be able to *translate* attribute names from one format to the other, or understand both at the same time. - Your metadata should be valid according to the [metadata validator](https://technical.edugain.org/validator2). Additionally, you will need to handle a few things on your own. The same way we will publish your metadata upstream to eduGAIN, we also consume metadata coming from it, parse and filter it for our services in Feide. Your Service Provider must fetch eduGAIN’s metadata periodically, at least once a day, from the following URL: ```default https://metadata.feide.no/edugain-metadata.xml ``` You will also need to handle *discovery* yourself. Discovery is what allows your users to find their way to their home institutions in order to authenticate themselves. This is an important step in terms of usability, and you need to prepare for potentially thousands of home institutions being available to your users, and find a way to display and allow your users to select them in an accessible way. There are different solutions to this problem, but we usually recommend grouping home institutions by country and allowing the user to search by name and realm (domain). Typically, you may want to distinguish between Feide and other federations you may be already part of, and eduGAIN. The way you can handle this may depend heavily on the SAML implementation you are using, so you need to refer to its documentation to figure out what is the best approach. Feide does not offer any way to do discovery for the moment. Once your metadata is ready, you are consuming eduGAIN’s metadata feed from the URL above, and your new discovery interface is in place, we can proceed to publish your metadata towards eduGAIN and others will be able to see it and use it to log into your service. ## Optional features Many home institutions will simple refuse to send any attributes to you, as they don’t know you. If you would like to improve your chances to get the attributes you need, you can declare adherence to eduGAIN’s [Data Protection Code of Conduct](https://wiki.refeds.org/display/CODE/Data+Protection+Code+of+Conduct+Home). This is a self-asserted document that states your compliance with certain good practices regarding attribute and personal data handling, and it might increase the chances that home organizations trust you and send the attributes you need. You can read more about [what it implies for you as a Service Provider](https://wiki.geant.org/display/eduGAIN/Recipe+for+a+Service+Provider). Additionally, if your service shares the common criteria described in the [REFEDS Research and Scholarship](https://refeds.org/research-and-scholarship) Entity Category, Feide may add that to your metadata (upon request), which may also help others to trust you and release a minimal amount of required personal information. You can also read more [relevant information for R&S Service Providers](https://wiki.refeds.org/display/ENT/Research+and+Scholarship+FAQ#ResearchandScholarshipFAQ-ForSPOwners) # Enabling Feide-users to log into an eduGAIN service provider Feide operates a centralized login service for the Norwegian research and education organizations. Feide is connected to eduGAIN, but due to the architecture in Feide there are some additional requirements for service providers. This page documents the process for enabling Feide-users to log into your eduGAIN service provider. ## Support for the Feide architecture Feide is connected to eduGAIN and uses the same protocol as other organizations connected to eduGAIN (SAML 2.0), but has a different architecture. Specifically, Feide operates a single SAML 2.0 identity provider that represents all organizations. (The Feide identity provider has the SAML 2.0 entity identifier `https://idp.feide.no`.) ### Organization selection When users log into your service they must select their organization. This allows your service to direct the login request to the correct identity provider. Generally, there are two ways that service providers handle organization selection. 1. Many service providers simply use the eduGAIN metadata feed for organization selection. In this case users will be able to choose “Feide” on your organization selection page, and the login request will be sent to Feide. 2. Some service providers manually configure organizations in their systems. In this case, you will have to manually direct login requests for the Norwegian organizations to the Feide identity provider. ### Identifying the organization after login Some service providers rely on the entity identifier of the SAML 2.0 identity provider to map users to organizations. Since Feide is a single identity provider representing multiple organizations, this will not work. Instead you will need to look at the user attributes in order to identify the organization. For example, you can look at the `eduPersonPrincipalName` attribute (`username@example.org`) or the `schacHomeOrganization` attribute (`example.org`). From these attributes you service can see that the user comes from the organization with the domain `example.org`. There is also the `eduPersonScopedAffiliation` attribute (`student@example.org`), but be aware that this attribute is not mandatory to register in Feide, and many organizations do not have it available. ## Attributes in SAML 2.0 metadata In order to receive user attributes from Feide, you service needs to list its required attributes in its SAML 2.0 metadata. Each attribute must be added as a ``-element. For example: ```xml ``` The `Name` field must contain a `urn:oid:`-value identifying the attribute. The `NameFormat` field must be set to `urn:oasis:names:tc:SAML:2.0:attrname-format:uri`. The `FriendlyName` and `isRequired` fields are ignored. If your service requests an attribute that is not supported by Feide, that attribute is ignored. (See the [example metadata](#edugain-metadata-example) for a more complete example.) ## Make the service discoverable Feide lists all available eduGAIN services in our self-service portal. In order to be discoverable on that page, it is important that your service has a name and description. Feide retrieves the name and description of the service from its SAML 2.0 metadata. It looks for the name and description in two locations: 1. The `` extension. 2. The `` element. (See the [example metadata](#edugain-metadata-example) for details.) ## Organizations must activate the service Feide is a opt-in federation, where each organization must activate a service before users from that organization can log into the service using Feide. If an organization has not activated your service, that organization will not be available on the Feide login page when logging into your service. It is up to each organization to decide on a process for activating services in Feide. Normally the best way is to have a user at the organization contact their IT support. IT support can then direct the request to the organizations Feide administrators, who can activate the service. **Note**: If no organizations have activated your service, your service will not be added to the Feide login system. In that case, users will receive a “Metadata not found” error: !["Metadata not found" error message](service_providers/edugain/edugain-metadata-not-found.png) ## Example SAML 2.0 metadata Here we have an example of SAML 2.0 metadata for a service provider. It shows where attribute requirements, name and description can be added to the metadata. Note that your federation operator may have additional requirements for the metadata they publish to eduGAIN. ```xml This service is just an example. ExampleService ExampleService This service is just an example. ExampleServiceProvider ExampleServiceProvider https://www.example.org/ ``` # Metadata Registration Practice Statement for Feide Version 1.0.2, last edited November 5th 2021. ## Practices on Identity Provider Registration Feide operates a single Identity Provider on behalf of educational and research institutions in Norway. The Feide operational team manually maintains the metadata entry for this Identity Provider. Users of the Feide Identity Provider select which institution to login on during the login process. Feide operates a opt-in model for institutions, where the institution must explicitly agree to accept eduGAIN connectivity before users are allowed to login through a given institution for any Service Provider within eduGAIN. Before new institutions are connected to the eduGAIN through Feide Identity Provider, the following requirements must be fulfilled: * Institution sends a [request to join Feide](https://www.feide.no/soknad-vertsorganisasjon). * Institution fills out a registration form on the technical connectivity, user storage and user registration practices. * Institution signs the [Feide Contract Part I](http://www.feide.no/sites/feide.no/files/documents/form-0002-1.1-no-feidekontrakt-del1-vertsorganisasjon.pdf) and [Part II](http://www.feide.no/sites/feide.no/files/documents/form-0003-1.1-no-feidekontrakt-del2-vertsorgansiasjon.pdf), and sends it to Feide by postal mail. * Feide validates the gather information, and may inspect the user storage to review if requirements are fulfilled, before accepting the institution to be connected. * Institution explicitly requests to connect to eduGAIN services through the [Feide Customer Portal](https://kunde.feide.no/). ## Practices on Service Provider Registration Feide will only expose Service Providers to eduGAIN that are official services connected to the Feide federation production environment. For a Service Provider to join the Feide federation, the following requirements must be met: * The Service provider must accept the terms and conditions in [customer portal](https://kunde.feide.no/) in order to publish a service. * The Service Provider must perform a technical test using the Feide Test Environment. * The Service Provider must fill out a registration form with necessary information about the service, including contact persons and attribute requirements. * The Service Provider provides SAML metadata to Feide. * Feide validates the provider information, including the attribute requirements, before accepting the Service Provider into the production environment. Before the Service Provider is exposed to eduGAIN, the Service Provider also must fulfill these requirements: * The Service Provider must explicitly request to connect to eduGAIN through Feide. * Feide makes a sanity check that the setup is technically sound, and that the Service Provider consumes the eduGAIN metadata. The metadata provided by the Service Provider will be manually processed by the Feide operational team, before being re-published through eduGAIN. For the Service Provider to make updates to the metadata entry, it must contact the [Feide Helpdesk](http://www.feide.no/kontakt-oss). ## Feide Metadata Aggregate Feide maintains an aggregate of all metadata it exposes to eduGAIN: * [Metadata](https://metadata.feide.no/feide-edugain-metadata.xml) The metadata document signature can be validated using the following X.509 certificate: ```default -----BEGIN CERTIFICATE----- MIIEaDCCA1CgAwIBAgIJAIqK28Ft/k4fMA0GCSqGSIb3DQEBBQUAMH8xCzAJBgNV BAYTAk5PMRIwEAYDVQQIEwlUcm9uZGhlaW0xEjAQBgNVBAcTCVRyb25kaGVpbTEQ MA4GA1UEChMHVU5JTkVUVDEOMAwGA1UECxMFRmVpZGUxJjAkBgNVBAMTHW1ldGFk YXRhLXNpZ25pbmcta2V5LmZlaWRlLm5vMB4XDTExMDUwNTA2MTM0MVoXDTIxMDUw NDA2MTM0MVowfzELMAkGA1UEBhMCTk8xEjAQBgNVBAgTCVRyb25kaGVpbTESMBAG A1UEBxMJVHJvbmRoZWltMRAwDgYDVQQKEwdVTklORVRUMQ4wDAYDVQQLEwVGZWlk ZTEmMCQGA1UEAxMdbWV0YWRhdGEtc2lnbmluZy1rZXkuZmVpZGUubm8wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCcKU4nXnyAnpV1ze7gPstxWOiG9CnC lT40n6ahOQNzp/RVhSHvr44YU5+hjKUYyEDKIfth94d3Zso/ytDieVcTaMKlvJLC rormiVIlcg/yQiXyAJSppScich/m1shUuOSiCWuO9wYF6IkIFXTT+kCTi8++s+iW XG8brorsyiTW5ztU4PUZ+ZyrWowbKl6DMybI5C9djbkgqeRgbJeTen8JGASS0Ezp YmuyHgmvy69X0cMr5a6fY2/f+bApiP/oPjr4AuoSASka4QQ8Fn0zWQfcIGAX+1iQ nbkpzaurz5YRfB06PjPrpYpobJ011tDrJqggxLxPB4AqZSSW1pCLI8DvAgMBAAGj geYwgeMwHQYDVR0OBBYEFAaysDNeH7PDb9Qoq7Jdm3D9gKbcMIGzBgNVHSMEgasw gaiAFAaysDNeH7PDb9Qoq7Jdm3D9gKbcoYGEpIGBMH8xCzAJBgNVBAYTAk5PMRIw EAYDVQQIEwlUcm9uZGhlaW0xEjAQBgNVBAcTCVRyb25kaGVpbTEQMA4GA1UEChMH VU5JTkVUVDEOMAwGA1UECxMFRmVpZGUxJjAkBgNVBAMTHW1ldGFkYXRhLXNpZ25p bmcta2V5LmZlaWRlLm5vggkAiorbwW3+Th8wDAYDVR0TBAUwAwEB/zANBgkqhkiG 9w0BAQUFAAOCAQEANcTJpNAeWg5R4PBBVvwNjCcpTCaMqpAXgNJMSCLIQrBHAQuT M/3dMJeUzo303erIpOsX9gJdhvKq/Ii8hF4/+J7aQZMg1E9yLU5P6/zUqS22vpAe DfVyIe38gTS3u67m3wSVjfp0THqIS7y6m+ID3KpeKFtdo1rSLFQBch/l+NivfIoU VVEZWWGHtxMSC9PM+x655f29wxVyAe74c+585nM62FUCUXGtli1B81GU2i/g7ADa Bv6Pp8GAajBToziaxSSsB0hmn6z0dxW1QsDlBKwPGr4e6BdRqnzqpUu5UPPVj4Z3 kUuV9JExHe7FRwcfxWcy3jyPpm2AUJmrHtYDFw== -----END CERTIFICATE----- ``` # Provisioning users and groups Traditionally, Feide has only provided user and group data in the context of an actual authenticated user. However, there are a lot of use cases for provisioning user data and/or group data outside of this context. ## Accessing user/group data without a user login Some APIs and endpoints allow services to fetch user/group data without a user needing to log in. To access user/group data in this manner you need to: > * Add the `system-all-users` scope to your service. > * Authenticate with [client credentials flow](../openid_connect/client_credentials_flow.html.md). The actual user and group data that can be fetched will depend on: > * The other scopes (attribute groups) that the service has access to > * Which organizations have activated the service in the Customer Portal > * What data is available for each API/endpoint. Refer to the detailed API documentation for more information: > * [List groups for a given organization](../../reference/apis/groups_api/groups_endpoints.html.md#orgs-groups-list) > * [Get group members for a given organization](../../reference/apis/groups_api/groups_endpoints.html.md#orgs-group-members) > * [Get details about a group at the given organization](../../reference/apis/groups_api/groups_endpoints.html.md#orgs-group-details) > * [Get details about a user at the given organization](../../reference/apis/attributes_feide/user_lookup.html.md) For testing these APIs please refer to the [test users](../../reference/testusers.html.md#ref-provisioning-test-users) documentation. # Finding the organization domain name of a school Feide uses the domain name (realm) of an organization to identify it. The domain name is chosen by the organization and can be something like `eksempel.kommune.no`, `feide.eksempel.kommune.no`, `eksempelskolen.no`, etc. Sometimes, you need to determine the domain name of a school’s organization. This page describes how to do this using data from the Nasjonalt Skoleregister (NSR) and Feide. ## Step 1: Find the organization number of the school owner - To find it interactively, visit Nasjonalt Skoleregister ([https://nsr.udir.no/](https://nsr.udir.no/)) and search for the school. At the page for the school, you can follow a link to the owner of the school and find its organization number. - To find it programmatically, use the NSR API ([https://data-nsr.udir.no/](https://data-nsr.udir.no/)). It is documented at [https://data-nsr.udir.no/swagger/](https://data-nsr.udir.no/swagger/). If you know the organization number of a school, its data can be found at `https://data-nsr.udir.no/v4/enhet/{organization_number}`. The format is JSON. The field `ForeldreRelasjoner` is a list of objects having the fields `Enhet` and `Relasjonstype`. You are looking for one where the `Id` is `1`. The organization number of the owner is the `Organisasjonsnummer` in the `Enhet` field. Example for the school “Skjåk barne- og ungdomsskule”, retrieved from [https://data-nsr.udir.no/v4/enhet/975274624](https://data-nsr.udir.no/v4/enhet/975274624): ```javascript { ..., "ForeldreRelasjoner": [ { "Enhet": { "Organisasjonsnummer": "961381096", "Navn": "Skjåk kommune" }, "Relasjonstype": { "Id": "1", "Navn": "Eierstruktur" } }, ... ], ... } ``` ## Step 2: Find the Host Organization Retrieve the list of organizations in Feide using the [organization list](../reference/apis/feide-api/organizations.html.md) of the Feide API. The URL is `https://api.feide.no/2/org/all?fields=name,realm,organization_number`. You can then search the returned data for an organization that matches the organization number you got from Nasjonalt Skoleregister. The domain name of the organization is the value of the `realm` field in the organization object. Example: ```json { "name": { "en": "Skjåk municipality", "nb": "Skjåk kommune", "nn": "Skjåk kommune" }, "realm": "skjaakskulane.no", "organization_number": "961381096" } ``` # Data sharing Data sharing in Feide Customer Portal makes it possible to share data between a data source (API) and Feide services in a secure way, with access control and authentication of clients and end users. You can create and publish data sources (APIs) and decide which Feide services should have access to different parts of the API. Data made available through data sharing will supplement the data that is currently found in [user directories](../reference/schema/attributes/index.html.md) Instead of this information being collected and stored locally at each service, the information is shared with the services that need the data. * [Available data sources](available_data_sources.html.md) * [Data Provider](data_provider/index.html.md) * [Creating new data source](data_provider/creating_new_data_source.html.md) * [Managing access to a data source](data_provider/managing_access_to_a_data_source.html.md) * [Deleting a data source](data_provider/delete_data_source.html.md) * [Working with Feide JWT tokens](data_provider/using_jwt_tokens.html.md) * [Accessing Feide data from a data source](data_provider/accessing_feide_from_data_source.html.md) * [Data Consumer](data_consumer/index.html.md) * [Getting access to data through data source](data_consumer/getting_access_to_data_through_data_source.html.md) * [Disconnecting a data source from a service](data_consumer/disconnect_data_source.html.md) * [Accessing data using JWT Token Exchange](data_consumer/jwt_token_exchange.html.md) # Available data sources Feide allows data owners to make new data sources available in a way that make them easy to use by service providers. All data sources that are available are listed in [Feide Customer Portal](https://kunde.feide.no/) under the Data Source tab. Feide also provide some API endpoints for common Feide data that can be used by services. [Click here for more information on these APIs](../reference/apis/index.html.md) If you have data that may be interesting for other services, you can [set up your own data source (API)](data_provider/creating_new_data_source.html.md). #### NOTE Legacy API gatekeepers cannot be managed in Feide Customer Portal. Please contact us at [kontakt@sikt.no](mailto:kontakt@sikt.no) if you want to modify a legacy API gatekeeper. Under the data source tab in Feide Customer Portal you can see the data sources available through Feide. This list contains all data sources that have been made public by the API owner. Internal data sources can only be seen by the owner. ![Screenshot of list of data sources in Customer Portal](data_sharing/data_provider/available1.png) If your organization has registered a data source, it is available under the **Provided by ** tab. If your organization has services that use a data source, they can be found under the **In use by ** tab. # Data Provider * [Creating new data source](creating_new_data_source.html.md) * [Managing access to a data source](managing_access_to_a_data_source.html.md) * [Deleting a data source](delete_data_source.html.md) * [Working with Feide JWT tokens](using_jwt_tokens.html.md) * [Accessing Feide data from a data source](accessing_feide_from_data_source.html.md) # Creating new data source Only create data sources using the Customer Portal for which you are the provider. If the data has multiple owners, we recommend the data provider create one data source for each. This will make the approval process for access to the data source easier for you to manage, as it is up to each data owner to decide if they want to share data with specific services. Data owner approval must be obtained outside of the Customer Portal, for example through email. Such approval flows will be supported at a later stage of the Customer Portal development. You can register a new data source under the “Data source” tab in the Feide Customer Portal. Click on “Create data source”. When registering a new data source, the required steps are shown in the top bar. You need to fill out the required fields marked with \* to complete creation. The information you enter will be saved for later if you can’t finish everything at once. Remember that the optional fields could be useful for the consumers of your data source. ## Information about the data source In “About the data source” you need to register information about the data source. This information will be made available to other users of the Customer Portal and later on feide.no and in Feide’s APIs if you choose to publish the data source in the last step. Use this information to describe your data source to other consumers. We recommend that you write the name of the data source and description in multiple languages to make your your data source easier to find. ![Screenshot of the About data source tab](data_sharing/data_provider/create1.png) **Privacy statement** A privacy statement intended to help organizations locate the privacy policy for the data source. You can enter a URL to a website containing the privacy statement of your data source. This link will be displayed when viewing the data source in the Customer Portal. **Terms of service** You can enter a URL to your terms of service if your data source has one. The link to the Terms of service will be displayed when viewing the data source in the Customer Portal. ### Technical Under the **Technical** tab you need to register a URL to a website containing technical documentation about how to use your data source. ![Screenshot of the Technical tab](data_sharing/data_provider/create2.png) This URL is made available to service providers when viewing your data source (if it is made public). This will make it easier for service providers to make use of your data source. ### Access levels Under the **Access** tab you define access levels for your data source. A data source can have multiple access levels. This is useful if the data source contains different types of information. It is required for a data source to have at least one access level. We recommend adding an access level for the different types of information in the data source. This will make it easier for the service to understand what information about the end user they receive. For example, if the data source has information about subjects and grades for the student, the subjects and grades should be two different access levels so services that only need subjects only get the subjects and not the grades. ![Screenshot of the Access levels tab](data_sharing/data_provider/access1.png) #### Creating a new Access level Click on “New access level” to create a new access level. ![Screenshot of the New access level dialog](data_sharing/data_provider/access2.png) When creating an access level, both a name and an identifier are needed. We recommend that the identifier and name reflect what kind of access the access level provides. The identifier needs to be unique for the data source and cannot contain spaces. The identifier is what **will become the actual scope** used by clients of the data source. The description is not required but recommended to give a description to the service about what type of information the access level provides. This will help the service provider decide if they are requesting the right access level to get the data they need. The access level can use different authorization modes. There are two modes: **Free access** and **Requires approval**. You can select the mode in the **data provider authorization** drop-down menu. If there is no need for the data owner to approve which services should be able to access data from the access level, set the authorization mode to Free access. If you choose Free access, requests from services for access to this access level will get automatically approved. Be mindful of what data you provide with free access, so you avoid sensitive or personal data being shared without the data owner assessing whether it is safe and necessary for the service to receive that data. If you choose **Requires approval**, services must ask for access to the given level, and you can approve or deny their request. This is done under the **Access control** tab on the data source. See [Managing access to a data source](managing_access_to_a_data_source.html.md) If you don’t want any requests from service provider to use the data source, you can mark the data source as internal, so it will not be shown in the list of available data sources. This is done in the **Visibility** tab when all the required information is entered. When you are finished adding all the access levels in the data source either go to the next tab or click on **Continue.** #### Changing access level You can at any time edit **data provider authorization** (authorization mode) of the access level. ![Screenshot showing context menu in Access level tab](data_sharing/data_provider/access3.png) This is done under the Edit tab on the data source. In the list of access level click on “…”/more on the right side and select “Edit”. If services have requested access to the access level with free access before this change, the service will still have access to the data. You can revoke access if these service should not have access to the data for the access level. ### Logo Under the Logo tab, you can upload a logo of the data source to make the data source more recognizable. The logo is displayed in the list of data sources in the Customer Portal. The logo must be in png, jpeg, or gif format, and should be at least 200x200 pixels. If the logo does not look good when reduced to 48x48 pixels, is it possible to add a smaller logo file as well. ### Creating and publishing the data source To create the data source, you need to register all the required information. ![Screenshot showing error messages in the Visibility tab](data_sharing/data_provider/access4.png) If there is information that is required but is not registered, you wil get an error message on the Visibility tab when creating the data source. What information is missing is described in the error message. You can go to the corresponding tab either by clicking on “Go to the field” on the error message or going to the tab in the top bar with an error icon shown. If you don’t have all the required information available, the information already entered is saved, enabling you to fill in the rest of the information later. ![Screenshot of the Visibility tab](data_sharing/data_provider/access5.png) When all required fields are registered, you can create the data source. In order for your data source (API) to be listed publicly for other service providers to use, it needs to select Public in the Visibility tab on the data source. When the data source is made public, services that want to connect to the data source may request access to use one or more access levels. If you don’t want services outside of the owner organization to connect to the data source, make the it internal. A public data source may be made internal at any time after creation by editing the data source. # Managing access to a data source #### NOTE It is now possible to create and manage access to data sources using our Customer Portal. Only the data provider will be able to manage such access in the Customer Portal. If the data provider and data owner are not the same organization, the data provider will need to get approval from the data owner directly (for example through an email). Support for such approval flows in the Customer Portal will be implemented at a later time. Please contact us at [kontakt@sikt.no](mailto:kontakt@sikt.no) if you need to make changes regarding a data source that was created using Dataporten Dashboard. The dashboard is no longer available. All data sources that are available are listed in [Feide Customer Portal](https://kunde.feide.no/) under the *Data Source tab*. ![Screenshot of list of data sources](data_sharing/data_provider/images/datasharing1.png) In Feide Customer Portal the data sources that the organization owns can be found in the tab “Provided by ” To manage access to the data sources, click on the data source in the list. ![Screenshot of empty access control tab](data_sharing/data_provider/images/datasharing2.png) Managing access to the data source can be done under the Access control tab on the data source. In order to be shown under “All data sources” and get requests from services for access, the data source needs to be set to Public. Setting the data source to Public can be done under the Visibility tab when editing the data source. ![Screenshot of access control tab with services requesting or having access](data_sharing/data_provider/images/datasharing3.png) Under the Access control tab of the Data source, you can manage the access services will get to your data source. The service providers that want to connect to the data source need to get access to a minimum of one access level. This is done by the service provider requesting an access level in the Customer Portal. A data source can have multiple access levels that grant access to different types of information available within the data source. These access level can have different authorization modes. There are two modes: **Free access** and **Requires approval**. Setting the authorization mode for an access level is done when registering or editing the data source under the tab “Access”. If set to **Requires approval** the service needs approval from the data owner. If set to **Free access** the access will be granted automatically when requested, without the need for approval from the data owner. If the data, the source and the service have the same owner, the request is automatically approved. Services that have access to the data source will be listed under “Services with access to the data source” on the Access control tab. ![Screenshot of Access requests section of access control tab](data_sharing/data_provider/images/datasharing4.png) The services waiting to get their request handled can be seen under “Access request”. Do not leave the requests unhandled, instead decline requests from services you don’t want to grant access to. ![Screenshot of access control tab with a service request expanded](data_sharing/data_provider/images/datasharing5.png) Click on the name of the service listed under Access request to see which access level the service is requesting. From there you can approve or deny access to all or some of the access levels requested. Some services will only request one access level, needing only the corresponding information. For example, if a service only needs the name of the subjects but not the grades of student in each subject. Ultimately, the data owner decides whether to approve or deny some or all access levels that the service provider has requested. To ensure the privacy of the end users, the data owner needs to consider whether or not the service needs or should get access to the data that they have requested. Contact the service provider directly as needed (for instance by email) to clarify how data will be used. Please ensure that any data access is covered by existing Data Processing Agreements, and if necessary revise the agreements and any associated risk assessments. ## Approving access levels ![Screenshot of access control tab with Approve/Deny buttons](data_sharing/data_provider/images/datasharing6.png) Click on “Approve” to the right of the access level and then confirm to approve service access. ![Screenshot of access control tab with services requesting or having access](data_sharing/data_provider/images/datasharing7.png) After access is approved the service wil be listed under “Services with access to the data source.” Click on the name of a service to see what access level(s) the service has. ## Denying access level ![Screenshot of access control tab with Approve/Deny buttons](data_sharing/data_provider/images/datasharing8.png) Click on “Deny” to the right of the access level and then confirm that you want to deny the service the access level requested. ![Screenshot of access control tab with services requesting or having access](data_sharing/data_provider/images/datasharing9.png) If you deny an access level request, it will disappear from the list. If denying access was done by mistake, the service provider will need to submit the request again. It can be useful to contact the service provider when denying requests, giving a reason as to why the service was denied access. This must be done outside of the Customer Portal, for example through email. You can revoke access after granting it if you think the service should no longer retrieve the information. If you revoke access, contact the service provider, since revoking access to information may affect the service adversely. So, make sure the service providers are informed about the revocation and have had time to adjust. ![Screenshot of access control tab with services requesting or having access](data_sharing/data_provider/images/datasharing10.png) To revoke access to the data source for a service, go to the data source and then to the Access control tab. Under “Services with access to the data source”, click on the name of the service. ![Screenshot of access control tab with Revoke access button](data_sharing/data_provider/images/datasharing11.png) Click on “Revoke access” to the right of the access level and then confirm to revoke access. When you revoke access the service will disappear from the list under “Services with access to the data source”. ![Screenshot of access control tab with revoked service no longer shown](data_sharing/data_provider/images/datasharing12.png) # Deleting a data source If you want to delete a data source, contact the service providers using your data source beforehand, as deleting the data source could cause the service to stop working. So make sure the service providers are informed and have had time to take appropriate action. ![Screenshot of Edit/Visibility tab with Delete the data source button](data_sharing/data_provider/delete1.png) Deleting a data source is done by navigating to your data source, choosing the Edit tab at the top, and then finding the **Visibility tab**. At the bottom there will be a button to delete the data source. When clicking the button you will be asked for confirmation. # Working with Feide JWT tokens When a data source has been created and the appropriate access levels/scopes have been configured in the Customer Portal, the service or API providing the data will need to work with the JWT tokens issued by Feide. The format and contents of the tokens can be found in the [reference docs](../../reference/tokens.html.md#ref-jwt-access-token). The service/API will then need a way to perform the following: 1. Receiving the token 2. Valdating the token 3. Perform authorization based on claims This can be done in several ways, including using a combination of these: * Using a proxy or API gateway with JWT support, some examples: * [Google API Gateway](https://cloud.google.com/api-gateway/docs/authenticating-users-jwt) * [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html) * [Gravitee](https://docs.gravitee.io/apim/3.x/apim_policies_jwt.html) * [Nginx+](https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-jwt-authentication/) * Using suitable middleware * Application code ## Receiving the token The way in which the token is received is dependent on the needs of the service/API. A typical way would be for the clients to send the JWT token as a Bearer token in the `Authorization` header in the request: ```http GET /resource HTTP/1.1 Host: api.example.com Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI... ``` ## Validating the token The service/API **must** validate the access token. In particular, `iss` has to be `https://auth.dataporten.no` and `aud` has to match the ID of the corresponding, registered data source prefixed by `https://n.feide.no/datasources/`. See [**the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens**](https://datatracker.ietf.org/doc/html/rfc9068.html#section-4) for full details about JWT access token validation. Furthermore, the token is only valid if the current time is in the interval between the `iat` and `exp` timestamps. ## Performing authorization At this stage, the service/API has access to all the claims from the token, and can use any combination of them as needed to authorize the request. The `scope` claim will contain one or more of the registered access levels for the data source. # Accessing Feide data from a data source A data source may need Feide data, such as user and group information, when processing a request from a service. To access the Feide data, the data source can do a token exchange to get a [Feide access token](../../reference/tokens.html.md#ref-feide-access-token). #### WARNING The service should *not* pass its own access token to the data source, as this would allow the data source to impersonate the service. ## Example flow Here is an example flow showing a data source that retrieves the user’s groups to determine if they have access: Steps 1 through 3 is the normal flow a service uses to access data from a data source in Feide. See [Accessing data using JWT Token Exchange](../data_consumer/jwt_token_exchange.html.md) for details. When the data source needs to access Feide data, the flow also includes steps 4 through 7. In step 4, the data source sends a token exchange request to Feide with the JWT it received from the service. See [Token exchange request from data source](#ref-token-exchange-request-from-datasource) for details about this request. Feide returns an access token to the data source in step 5. The data source then uses the access token to retrieve the user’s groups from Feide. These allow the data source to check that the user has access to the requested information, before returning the requested data to the service in step 8. ## Available Feide data A data source can access the same data from Feide as a normal service. Like for services, access to Feide data for data sources is configured in the Feide customer portal. ## Token exchange request from data source #### NOTE This is for the case when a data source wants a regular access token to pass to Feide. See [Token exchange request from service](../data_consumer/jwt_token_exchange.html.md#ref-token-exchange-request-from-service) for the case when a service wants a JWT to pass to Feide. A token exchange request includes `audience` and `scope` parameters. The `audience` must be `https://auth.dataporten.no`. The valid values for scopes are the Feide access levels which are configured in the customer portal for the data source. A token exchange request is made to the token endpoint using the HTTP “POST” method. Parameters are included in the HTTP request entity-body using the `application/x-www-form-urlencoded` format. The parameters are: audience : `https://auth.dataporten.no` client_id : The UUID of the data source making the exchange request. client_secret : The client secret of the data source. grant_type : The value `urn:ietf:params:oauth:grant-type:token-exchange` selects OAuth2 token exchange. requested_token_type : The value `urn:ietf:params:oauth:token-type:access_token` selects a regular access token. scope : A space separated list of scopes that should be enabled for the token. The scopes specify which information the data source can retrieve from Feide. See [Scopes, claims and attribute groups](../../reference/oauth_oidc/openid_connect_details.html.md#scopes-claims-attribute-groups).
The desired scopes must be enabled for the data source in the Feide customer portal. If this parameter is empty or left out, all scopes enabled in the Feide customer portal will be available. subject_token : The JWT the data source received from the service. subject_token_type : Must be `urn:ietf:params:oauth:token-type:jwt`. Here is an example: ```default POST https://auth.dataporten.no/oauth/token content-type: application/x-www-form-urlencoded audience=https://auth.dataporten.no &client_id=03dd959b-13ea-44b5-8930-bedae77973f1 &client_secret=7ec72f43-d697-40d3-9992-cd15f4016bae &grant_type=urn:ietf:params:oauth:grant-type:token-exchange &requested_token_type=urn:ietf:params:oauth:token-type:access_token &scope=groups-edu groups-other profile userid userid-feide &subject_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI... &subject_token_type=urn:ietf:params:oauth:token-type:jwt ``` ## Successful response A successful response has status 200 and an `application/json` body with the following attributes: token_type : The type is `Bearer`. issued_token_type : The type is `urn:ietf:params:oauth:token-type:access_token`. access_token : The access token that was issued. expires_in : Number of seconds until JWT expires. scope : The scopes that were granted. Here is an example: ```json { "access_token": "5f0941ec-9980-4398-a126-83ad8efb34ed", "token_type": "Bearer", "issued_token_type": "urn:ietf:params:oauth:token-type:access_token", "expires_in": 299, "scope": "groups-edu groups-other profile userid userid-feide" } ``` The access token is an opaque ASCII string, see the [reference documentation](../../reference/tokens.html.md#ref-feide-access-token). ## Token lifetimes The token lifetime is 5 minutes. If the data source needs access after the token has expired, it must obtain a new one. # Data Consumer * [Getting access to data through data source](getting_access_to_data_through_data_source.html.md) * [Disconnecting a data source from a service](disconnect_data_source.html.md) * [Accessing data using JWT Token Exchange](jwt_token_exchange.html.md) # Getting access to data through data source #### NOTE In order to connect your service to a data source (API), the service needs to be using OIDC for integrating with Feide. With data sharing in Feide, services can easily get additional data that is not available in the [user directories](../../reference/schema/attributes/index.html.md) of the host organizations. It enables sharing data from a data source (API) with services in a secure manner, using the existing access control and authentication mechanisms in Feide for clients and end users. Data owners such as host organizations, or data providers such as other service providers, can make their data available by creating data sources in Feide. Instead of users registering the same information in multiple services, based on exporting datasets, or setting up expensive integrations for every host organization uses a service, the data can be shared through the data sharing functionality in Feide. If your service needs additional data to implement some new functionality you can get information through a data source available in Feide. Lists of available data sources can be found in the Customer Portal. Read more about [existing data sources](../available_data_sources.html.md). ## Requesting access to data source #### NOTE You can only request access to data sources that are registered in the Feide Customer Portal. Please contact us at [kontakt@sikt.no](mailto:kontakt@sikt.no) if you need access to a legacy API gatekeeper. ![Screenshot of Data sources tab with Connect to data source button](data_sharing/data_consumer/requesting1.png) When editing your service go to the **Data source** tab and click **Connect to data source**. Here you will find a list of available data sources. Use the search field if the data source you are looking for is not visible. Any data source marked as internal by the data provider will not be shown. It may be that the source is meant for use by the owning organization only, or it might not be ready for production use yet. When you have found the data source you want to connect with, click on the name of the data source. ![Screenshot of Display data source tab](data_sharing/data_consumer/requesting2.png) Here you get more information about the data source, such as what organization provides it, description, the various information available (under the Access level tab), and link to technical documentation. We recommend reading the technical documentation shown before requesting access to the data source. To request access to the data source click on **Connect data source to service** in the right corner of the data source. ![Screenshot of Connect to data source form](data_sharing/data_consumer/requesting3.png) In the drop-down menu you select the service you want to access the data source with. Only services integrated using the OIDC protocol are listed since SAML protocol doesn’t support the use of Feide data sources. Then select the access level with the information the service needs. Before selecting the access level think about what information the service needs to know about the user and organization. Avoid requesting access to more information than the service needs. For example, some services only need to know that the user is a student, while others need to know the subjects and the grade of the students. If you find out later that the service needs more information, you can request additional access levels at that time. When selecting the access level click on **Connect** to request connecting to the data source. ## Getting access to a data source The access is either granted instantly or upon request. This depends on which authorization mode has been set by the data owner. The two different scenarios are illustrated below. ![Screenshot of Access granted message](data_sharing/data_consumer/requesting4.png) If you have requested an access level using the Free access mode, your service is granted access at once. ![Screenshot of Access requested message](data_sharing/data_consumer/requesting5.png) If you have requested an access level using approval mode, you need to wait for the data provider to approve the access for the service. Is up to the *data owner*, and not the *data provider*, whether or not they want to approve or deny some or all access levels that the service provider has requested. You will be notified by email when the request is granted or denied. It may take some time for the data provider to handle the request if the data provider is not also the data owner. The data provider needs the permission of the data owner to grant services access to the data. For now, this needs to be handled outside the Customer Portal. The data owner may also have to conduct a new risk assessment of your service and update their Data Processing Agreement if the service gets additional information. The data owner may contact you as a service provider if they are unsure about how the service will be using and storing the data before approving the access. This communication is done outside of the Customer Portal for example through email. ## Accessing data from a data source When you have been granted access to the data source, the service needs to access the data. This is done by [JWT-token exchange](jwt_token_exchange.html.md) # Disconnecting a data source from a service If you no longer need or want to use the data source, simply access the data source tab from the relevant service and disconnect it from the data source as shown in the figure below. ![image](data_sharing/data_consumer/requesting7.png) Should you need access to the data source at a later stage, please see [requesting and getting access to data source](getting_access_to_data_through_data_source.html.md) # Reference * [TLS requirements for LDAP servers](tls-requirements-ldap.html.md) * [TLS protocol version](tls-requirements-ldap.html.md#tls-protocol-version) * [TLS cipher suites](tls-requirements-ldap.html.md#tls-cipher-suites) * [Certificates](tls-requirements-ldap.html.md#certificates) * [Testing compatibility](tls-requirements-ldap.html.md#testing-compatibility) * [Information models and object specification](schema/index.html.md) * [Attribute groups](schema/attributegroups/index.html.md) * [Attributes](schema/attributes/index.html.md) * [Person and account identifiers in Feide](schema/identifiers/index.html.md) * [The Feide information model for lower education](schema/info_go/index.html.md) * [Feides information model for higher education](schema/info_uh/index.html.md) * [norEdu\* Object Class Specification](schema/noredu/index.html.md) * [LDAP validator](ldap_validator/index.html.md) * [Running the LDAP validator](ldap_validator/running.html.md) * [Validator errors](ldap_validator/errors/index.html.md) * [APIs](apis/index.html.md) * [Feide API](apis/feide-api/index.html.md) * [Groups API](apis/groups_api/index.html.md) * [OpenID Connect userinfo](apis/userinfo.html.md) * [Feide user attributes](apis/attributes_feide/index.html.md) * [Guardian API](apis/guardianapi.html.md) * [Deprecated APIs](apis/deprecated/index.html.md) * [MFA](mfa/index.html.md) * [Technical specification](mfa/technical_reqs.html.md) * [MFA Examples](mfa/examples.html.md) * [OpenID Connect and OAuth 2.0](oauth_oidc/index.html.md) * [User IDs](oauth_oidc/userids.html.md) * [OpenID Connect details](oauth_oidc/openid_connect_details.html.md) * [Logout](oauth_oidc/logout.html.md) * [SAML 2.0](saml/index.html.md) * [Introduction](saml/saml2_technical_guide.html.md) * [SAML in Feide](saml/saml2_technical_guide.html.md#saml-in-feide) * [The user’s Feide session](saml/saml2_technical_guide.html.md#the-users-feide-session) * [Metadata](saml/saml2_technical_guide.html.md#metadata) * [User attributes](saml/saml2_technical_guide.html.md#user-attributes) * [Testing](saml/saml2_technical_guide.html.md#testing) * [Technical requisites](saml/saml2_technical_requisites.html.md) * [Selecting the user organization](saml/selectorg.html.md) * [Tokens used in Feide](tokens.html.md) * [Feide access token](tokens.html.md#feide-access-token) * [Feide JWT access token](tokens.html.md#feide-jwt-access-token) * [ID token](tokens.html.md#ref-id-token) * [Feide test users](testusers.html.md) * [Organizations and units](testusers.html.md#organizations-and-units) * [Generic test users](testusers.html.md#generic-test-users) * [Test users that work with provisioning APIs](testusers.html.md#test-users-that-work-with-provisioning-apis) # TLS requirements for LDAP servers This document describes the requirements for the SSL/TLS configuration of LDAP servers connected to Feide ## TLS protocol version Feide requires LDAP servers to support TLS version 1.2. *Note*: On Windows Server 2008 R2, TLS version 1.2 must be enabled. See [Protocols in TLS/SSL (Schannel SSP)](https://docs.microsoft.com/en-us/windows/desktop/SecAuthN/protocols-in-tls-ssl--schannel-ssp-) for details. TLS 1.1, TLS 1.0, SSL version 3.0 and older is not supported by Feide. ## TLS cipher suites Feide requires LDAP servers to support at least one of the following cipher suites: * `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)` * `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)` * `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)` * `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)` * `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)` * `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)` * `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)` * `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)` * `TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)` * `TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)` * `TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)` * `TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)` ## Certificates Feide requires LDAP servers to be configured with a certificate issued from a public certificate provider. The [Mozilla CA-bundle](https://wiki.mozilla.org/CA/Included_Certificates) can be used as a reference for the list of supported root certificates in Feide. ## Testing compatibility The [LDAP connection test](https://ssltest.feide.no/) tool can be used to test the LDAP server against these requirements. # Information models and object specification These documents describe the information models used in higher and lower education in Feide. Detailed information about the LDAP object classes and attributes are also documented. * [Attribute groups](attributegroups/index.html.md) * [Attributes](attributes/index.html.md) * [Person and account identifiers in Feide](identifiers/index.html.md) * [The Feide information model for lower education](info_go/index.html.md) * [Feides information model for higher education](info_uh/index.html.md) * [norEdu\* Object Class Specification](noredu/index.html.md) # Attribute groups What information the service can receive about the end user is defined in the attribute groups that the service provider sets for the service in the customer portal (kunde.feide.no). The attribute groups contain a set of attributes about the user and the organization sent from the host organization’s directory. The availability of the information depends on whether it is registered about the user in the host organization’s directory. Read about attributes and their availability in [Feide documentation](../attributes/index.html.md). Before selecting attribute groups think about what information the service needs to know about the user and organization. Avoid requesting access to more information than the service needs to work. Some services only need to log in to ensure that there is a person associated with the education sector, while others need more to personalize the service for the user. If you find out later that the service needs more information about the user, you can add more attribute groups. The ways in which applications can access this information differs between OpenID Connect and SAML. Read in [OpenID Connect details](../../oauth_oidc/openid_connect_details.html.md#scopes-claims-attribute-groups) about the relationship between SAML attributes and OpenID Connect claims and scopes. Below is an overview of the information each attribute group contains. ## Personal information Below are attribute groups with personal information about the user like name, user identifier, mail, mobile and preferred language. ### Name (userinfo-name) | Attribute name | | |------------------------------------------------------------------------------------------------------|--------------| | [givenName](../attributes/givenname.html.md#saml-attribute-givenname) | Given name | | [sn](../attributes/sn.html.md#saml-attribute-sn) | Surname | | [norEduPersonLegalName](../attributes/noredupersonlegalname.html.md#saml-attribute-noredupersonlegalname) | Legal name | | [displayName](../attributes/displayname.html.md#saml-attribute-displayname) | Display name | | [cn](../attributes/cn.html.md#saml-attribute-cn) | Common name | | OpenID Connect claim name | claim value | |-----------------------------|---------------| | name | Display name | ### User identifiers at organization (userid-feide) | Attribute name | | | |------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------|----------------------------------------| | [eduPersonPrincipalNamePrior](../attributes/edupersonprincipalnameprior.html.md#saml-attribute-edupersonprincipalnameprior) | Person’s previous Feide IDs at the organization | | | [eduPersonPrincipalName](../attributes/edupersonprincipalname.html.md#saml-attribute-edupersonprincipalname) | Person’s Feide IDs organization | | | [uid](../attributes/uid.html.md#saml-attribute-uid) | User name | | | [eduPersonTargetedID](../attributes/edupersontargetedid.html.md#saml-attribute-edupersontargetedid) | Service specific identifier | Only available with SAML configuration | | [eduPersonUniqueId](../attributes/edupersonuniqueid.html.md#saml-attribute-edupersonuniqueid) | Long lived principal identifier | Only available with SAML configuration | | OpenID Connect claim name, ID token | claim value | availability | |--------------------------------------------------|------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------| | https://n.feide.no/claims/eduPersonPrincipalName | See [userinfo](../../apis/userinfo.html.md#ref-https-n-feide-no-claims-edupersonprincipalname) docs | when logged in to a Feide host organization | | https://n.feide.no/claims/userid_sec | See [userinfo](../../apis/userinfo.html.md#ref-https-n-feide-no-claims-userid-sec) docs | always, includes eduPersonPrincipalName only when logged in to a Feide host organization | These are claim *names*. They do not refer to pages on the web | OpenID connect claim name, userinfo | claim value | availability | |--------------------------------------------------|------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------| | dataporten-userid_sec (Deprecated) | See [userinfo](../../apis/userinfo.html.md#ref-dataporten-userid-sec) docs | always, includes eduPersonPrincipalName only when logged in to a Feide host organization | | https://n.feide.no/claims/userid_sec | See [userinfo](../../apis/userinfo.html.md#ref-https-n-feide-no-claims-userid-sec) docs | always, includes eduPersonPrincipalName only when logged in to a Feide host organization | | https://n.feide.no/claims/eduPersonPrincipalName | See [userinfo](../../apis/userinfo.html.md#ref-https-n-feide-no-claims-edupersonprincipalname) docs | when logged in to a Feide host organization | ### Mail (email) | Attribute name | | |---------------------------------------------------|-------| | [mail](../attributes/mail.html.md#saml-attribute-mail) | Email | | OpenID Connect claim name | claim value | |-----------------------------|---------------| | email | Email | ### Mobile (userinfo-mobile) | Attribute name | | |---------------------------------------------------------|--------| | [mobile](../attributes/mobile.html.md#saml-attribute-mobile) | Mobile | No OpenID Connect claims for this attribute group. The [extended userinfo endpoint](../../apis/attributes_feide/extended_userinfo.html.md#extended-userinfo) can be used. ### Preferred language (userinfo-language) | Attribute name | | |------------------------------------------------------------------------------------------|--------------------| | [preferredLanguage](../attributes/preferredlanguage.html.md#saml-attribute-preferredlanguage) | Preferred language | No OpenID Connect claims for this attribute group. The [extended userinfo endpoint](../../apis/attributes_feide/extended_userinfo.html.md#extended-userinfo) can be used. ### Identity number (userid-nin) The information in this attribute group is by the general public and Feide considered as semi-sensitive information. This attribute group is only released where actual need is demonstrated. Therefore, it can only can be added to a service by Sikt. Send an email to [kontakt@sikt.no](mailto:kontakt@sikt.no) and explain why the service requires this attribute group, and why it is not enough with another user identifier available through Feide. | Attribute name | | |------------------------------------------------------------------------------------|------------------------------------------------| | [norEduPersonNIN](../attributes/noredupersonnin.html.md#saml-attribute-noredupersonnin) | Identity number assigned by public authorities | | OpenID Connect claim name, ID token | claim value | availability | |---------------------------------------|------------------------------------------------------------------------------------|--------------------------------------------------------| | https://n.feide.no/claims/userid_sec | See [userinfo](../../apis/userinfo.html.md#ref-https-n-feide-no-claims-userid-sec) docs | always, includes NIN only when logged in via ID-porten | | https://n.feide.no/claims/nin | See [userinfo](../../apis/userinfo.html.md#ref-https-n-feide-no-claims-nin) docs | always | These are claim *names*. They do not refer to pages on the web. | OpenID connect claim name, userinfo | claim value | availability | |---------------------------------------|------------------------------------------------------------------------------------|--------------------------------------------------------| | dataporten-userid_sec (Deprecated) | See [userinfo](../../apis/userinfo.html.md#ref-dataporten-userid-sec) docs | always, includes NIN only when logged in via ID-porten | | https://n.feide.no/claims/userid_sec | See [userinfo](../../apis/userinfo.html.md#ref-https-n-feide-no-claims-userid-sec) docs | always, includes NIN only when logged in via ID-porten | | https://n.feide.no/claims/nin | See [userinfo](../../apis/userinfo.html.md#ref-https-n-feide-no-claims-nin) docs | always | ### Identity assurance (userinfo-assurance) | Attribute name | | |---------------------------------------------------------------------------------------------|--------------------| | [eduPersonAssurance](../attributes/edupersonassurance.html.md#saml-attribute-edupersonassurance) | Identity assurance | For OpenID Connect, see [acr and acr_values](https://openid.net/specs/openid-connect-core-1_0.html#acrSemantics) in the standard. ## Roles, affiliations and groups Below are attribute groups with information about the user’s roles, affiliations and groups in their organization. ### Organizational affiliations (groups-org) Information about the home organization, organization unit (school/department) and the person’s roles in the organization. This attribute group gives access to the following group types in the OpenID Connect groups API: - [School owner](../../apis/groups_api/group_types/pse_school_owner.html.md) (Primary and secondary schools) - [Schools](../../apis/groups_api/group_types/pse_school.html.md) (Primary and secondary schools) - [Organization groups](../../apis/groups_api/group_types/he_organization.html.md) (Higher education) - [Organization unit groups](../../apis/groups_api/group_types/he_organization_unit.html.md) (Higher education) | Attribute name | | |----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------| | [eduPersonAffiliation](../attributes/edupersonaffiliation.html.md#saml-attribute-edupersonaffiliation) | Affiliation at home organization | | [eduPersonPrimaryAffiliation](../attributes/edupersonprimaryaffiliation.html.md#saml-attribute-edupersonprimaryaffiliation) | Primary affiliation at home organization | | [eduPersonScopedAffiliation](../attributes/edupersonscopedaffiliation.html.md#saml-attribute-edupersonscopedaffiliation) | Affiliation and institution at home organization | | [eduPersonOrgUnitDN:norEduOrgUnitUniqueIdentifier](../attributes/edupersonorgunitdn-noreduorgunituniqueidentifier.html.md#saml-attribute-edupersonorgunitdn-noreduorgunituniqueidentifier) | Unique identifier of home organization | | [feideSchoolList](../attributes/feideschoollist.html.md#saml-attribute-feideschoollist) | List of schools | | [eduPersonOrgUnitDN:ou](../attributes/edupersonorgunitdn-ou.html.md#saml-attribute-edupersonorgunitdn-ou) | Name of organization units | | [eduPersonOrgUnitDN:mail](../attributes/edupersonorgunitdn-mail.html.md#saml-attribute-edupersonorgunitdn-mail) | Email address of organizational unit | | [eduPersonOrgDN:norEduOrgNIN](../attributes/edupersonorgdn-noreduorgnin.html.md#saml-attribute-edupersonorgdn-noreduorgnin) | Organization number | | [schacHomeOrganization](../attributes/schachomeorganization.html.md#saml-attribute-schachomeorganization) | Realm of home organization | | [eduPersonOrgDN:o](../attributes/edupersonorgdn-o.html.md#saml-attribute-edupersonorgdn-o) | Name of home organization | | [eduPersonOrgDN:eduOrgLegalName](../attributes/edupersonorgdn-eduorglegalname.html.md#saml-attribute-edupersonorgdn-eduorglegalname) | Legal name of home organization | | [eduPersonOrgDN:mail](../attributes/edupersonorgdn-mail.html.md#saml-attribute-edupersonorgdn-mail) | Organization email address | | [eduPersonOrgUnitDN](../attributes/edupersonorgunitdn.html.md#saml-attribute-edupersonorgunitdn) | Distinguished name of organization unit | | [eduPersonPrimaryOrgUnitDN](../attributes/edupersonprimaryorgunitdn.html.md#saml-attribute-edupersonprimaryorgunitdn) | Distinguished name of primary organization unit | | [eduPersonOrgUnitDN:postalAddress](../info_go/go_attributter_ch04.html.md#edupersonorgunitdn-postaladdress) | Postal address of educational unit | | [eduPersonOrgUnitDN:telephoneNumber](../info_go/go_attributter_ch04.html.md#edupersonorgunitdn-telephonenumber) | Telephone number of organizational unit | | [eduPersonOrgUnitDN:norEduOrgAcronym](../noredu/noredu_ch03.html.md#edupersonorgunitdn-noreduorgacronym) | Acronym for the organizational unit | | [eduPersonOrgDN:cn](../noredu/noredu_ch03.html.md#edupersonorgdn-cn) | Common name of home organization | | [EduPersonOrgDN](../info_uh/uh_attributter_ch02.html.md#edupersonorgdn-uh) used in universities and university colleges and [EduPersonOrgDN](../info_go/go_attributter_ch02.html.md#edupersonorgdn-go) in primary and secondary schools. | Distinguished name of home organization | | [eduPersonOrgDN:norEduOrgUniqueIdentifier](../info_uh/uh_attributter_ch04.html.md#edupersonorgdn-noreduorguniqueidentifier-uh) used in universities and university colleges and [eduPersonOrgDN:norEduOrgUniqueIdentifier](../info_go/go_attributter_ch04.html.md#edupersonorgdn-noreduorguniqueidentifier-go) in primary and secondary schools. | Unique identifier of home organization | | [eduPersonOrgDN:telephoneNumber](../info_go/go_attributter_ch03.html.md#edupersonorgdn-telephonenumber) | Telephone number of home organization | | [eduPersonOrgDN:eduOrgHomePageURI](../noredu/noredu_ch03.html.md#edupersonorgdn-eduorghomepageuri) | Home page of home organization | | [eduPersonOrgDN:norEduOrgAcronym](../noredu/noredu_ch03.html.md#edupersonorgunitdn-noreduorgacronym) | Acronym for the educational institution | | [eduPersonOrgDN:norEduOrgSchemaVersion](../attributes/edupersonorgdn-noreduorgschemaversion.html.md#saml-attribute-edupersonorgdn-noreduorgschemaversion) | Version of norEdu specification of home organization | ### Education groups (groups-edu) For primary, lower and upper secondary schools, this provides access to grade, basis groups, teaching groups and other groups registered in the attribute [eduPersonEntitlement](../attributes/edupersonentitlement.html.md#saml-attribute-edupersonentitlement). For users in higher education, this gives access to groups from the [Common Student System](https://www.fellesstudentsystem.no/) (Felles studentsystem). This attribute group gives access to the following group types in the OpenID Connect groups API: - [Basis group](../../apis/groups_api/group_types/pse_basis.html.md) (Primary and secondary schools) - [Teaching group](../../apis/groups_api/group_types/pse_teaching.html.md) (Primary and secondary schools) - [Other group](../../apis/groups_api/group_types/pse_other.html.md) (Primary and secondary schools) - [Grep group](../../apis/groups_api/group_types/pse_grep.html.md) (Primary and secondary schools) - [Program of study (studieprogram)](../../apis/groups_api/group_types/fs_program_of_study.html.md) (Higher education) - [Cohort (kull)](../../apis/groups_api/group_types/fs_cohort.html.md) (Higher education) - [Class (klasse)](../../apis/groups_api/group_types/fs_class.html.md) (Higher education) - [Course (emne)](../../apis/groups_api/group_types/fs_course.html.md) (Higher education) - [Field of study (studieretning)](../../apis/groups_api/group_types/fs_field_of_study.html.md) (Higher education) #### Groups in eduPersonEntitlement For users in primary, lower and upper secondary schools, group data is registered in the [eduPersonEntitlement](../attributes/edupersonentitlement.html.md#saml-attribute-edupersonentitlement) attribute. These are eduPersonEntitlement values starting with `urn:mace:feide.no:go:grep:` and `urn:mace:feide.no:go:group:`. The values starting with `urn:mace:feide.no:go:grep:` describe the grade, education program and program area of the student. For primary and lower secondary school this contains the grade level. For upper secondary school, this contains grade level, education program and program area. More information about Grep values in Feide can be found [here](../info_go/go_attributter_ch02.html.md). The eduPersonEntitlement values starting with `urn:mace:feide.no:go:group:` contain the basis groups, teaching groups and other groups for both students and teachers in primary, lower and upper secondary schools. Example of Group: `urn:mace:feide.no:go:group:b::NO975278964:6a:2014-08-01:2015-06-15:student:Klasse%206A` More information about registration of group values in Feide can be found [here](../info_go/go_attributter_ch03.html.md). #### Groups from Common Student System (FS) These are only available to OpenID Connect service configurations. FS is the [Common Student System](https://www.fellesstudentsystem.no/) (Felles studentsystem). It is a student administration system developed for higher education in Norway. These groups are only available if the FS integration with Feide has been enabled for the user’s organization. Send a request to [kontakt@sikt.no](mailto:kontakt@sikt.no) if you want to enable this integration for your organization. ### Group members’ identifiers (groups-memberids) Identifiers of other members of the user’s groups This allows the service to retrieve information about teachers and students in a group, without each student having logged in beforehand. This is only available to OpenID Connect service configurations. To get this information in the attribute group, Sikt need to add this to the service. Send a request to [kontakt@sikt.no](mailto:kontakt@sikt.no) containing the name of the service and why the service needs information about groups. More information about receiving this information, read about the [group API](../../apis/groups_api/index.html.md). ### Custom prefix (userinfo-entitlement) Custom prefixes for the [eduPersonEntitlement](../attributes/edupersonentitlement.html.md#saml-attribute-edupersonentitlement) attribute. ## Not commonly used attributes ### Other groups (groups-other) Ad hoc groups. They can be managed from [Feide Innsyn](https://innsyn.feide.no/groups). OpenID Connect service configurations can get information about them from the groups API. ### Date of birth (userinfo-birthdate) | Attribute name | | |---------------------------------------------------------------------------------------|---------------| | [norEduPersonBirthDate](../noredu/noredu_ch03.html.md#noredupersonbirthdate) | Date of birth | | [feideYearOfBirth](../attributes/feideyearofbirth.html.md#saml-attribute-feideyearofbirth) | Year of birth | No OpenID Connect claims for this attribute group. The [extended userinfo endpoint](../../apis/attributes_feide/extended_userinfo.html.md#extended-userinfo) can be used. ### Title (userinfo-title) | Attribute name | | |----------------------------------------------------|---------------------------| | [title](../noredu/noredu_ch03.html.md#noredu-ch3-title) | Title in the organization | No OpenID Connect claims for this attribute group. The [extended userinfo endpoint](../../apis/attributes_feide/extended_userinfo.html.md#extended-userinfo) can be used. ### Other phone number (userinfo-phone) | Attribute name | | |------------------------------------------------------------------------|-----------------------| | [telephoneNumber](../noredu/noredu_ch03.html.md#noredu-ch3-telephonenumber) | Telephone number | | [homePhone](../noredu/noredu_ch03.html.md#noredu-ch3-homephone) | Home telephone number | No OpenID Connect claims for this attribute group. The [extended userinfo endpoint](../../apis/attributes_feide/extended_userinfo.html.md#extended-userinfo) can be used. ### Local identity number (userid-lin) | Attribute name | | |-------------------------------------------------------------|--------------------------------------------------------| | [norEduPersonLIN](../noredu/noredu_ch03.html.md#noredupersonlin) | Local identity number, i.e. student or employee number | No OpenID Connect claims for this attribute group. The [extended userinfo endpoint](../../apis/attributes_feide/extended_userinfo.html.md#extended-userinfo) can be used. ### ORCID researcher identifier (userid-orcid) | Attribute name | | |---------------------------------------------------------------------------------|-----------------------------| | [eduPersonOrcid](../attributes/edupersonorcid.html.md#saml-attribute-edupersonorcid) | ORCID researcher identifier | No OpenID Connect claims for this attribute group. The [extended userinfo endpoint](../../apis/attributes_feide/extended_userinfo.html.md#extended-userinfo) can be used. ### eduGAIN user identifier (userid-edugain) Identifier used when the user logs in via eduGAIN to an OIDC service configured in Feide. | OpenID Connect claim name, ID token | claim value | availability | |---------------------------------------|------------------------------------------------------------------------------------|-----------------------------------------------------------------------| | https://n.feide.no/claims/userid_sec | See [userinfo](../../apis/userinfo.html.md#ref-https-n-feide-no-claims-userid-sec) docs | always, includes eduGAIN identifier only when logged in using eduGAIN | These are claim *names*. They do not refer to pages on the web | OpenID connect claim name, userinfo | claim value | availability | |---------------------------------------|------------------------------------------------------------------------------------|-----------------------------------------------------------------------| | dataporten-userid_sec (Deprecated) | See [userinfo](../../apis/userinfo.html.md#ref-dataporten-userid-sec) docs | always, includes eduGAIN identifier only when logged in using eduGAIN | | https://n.feide.no/claims/userid_sec | See [userinfo](../../apis/userinfo.html.md#ref-https-n-feide-no-claims-userid-sec) docs | always, includes eduGAIN identifier only when logged in using eduGAIN | ## Special attribute groups ### Access to information outside of the login session (system-all-users) This special scope allows services using the [client credentials flow](../../../service_providers/openid_connect/client_credentials_flow.html.md) to fetch user/group information without a user needing to log in, commonly used for [provisioning](../../../service_providers/provisioning/index.html.md) ### Checking user existence (system-check-user-existence) This special scope allows services using the [client credentials flow](../../../service_providers/openid_connect/client_credentials_flow.html.md) to check whether a user exists in an organization’s directory without retrieving any user attributes. See [Check user existence](../../apis/attributes_feide/check_user_existence.html.md#check-user-existence) for the available endpoints. # Attributes | | Short description | Availability in higher education. | Availability, primary and secondary school. | |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------|-------------------------------------|-----------------------------------------------| | [cn](cn.html.md#saml-attribute-cn) | General name on the person object | High | High | | [displayName](displayname.html.md#saml-attribute-displayname) | Person’s preferred name | Medium | Medium | | [eduPersonAffiliation](edupersonaffiliation.html.md#saml-attribute-edupersonaffiliation) | Person’s role (ex. student, employee) | High | High | | [eduPersonAssurance](edupersonassurance.html.md#saml-attribute-edupersonassurance) | Set of URIs that assert compliance with specific standards for identity assurance | Low | Low | | [eduPersonEntitlement](edupersonentitlement.html.md#saml-attribute-edupersonentitlement) | URI indicating rights to specific resources (primary and secondary school: Grep codes) | Low | Medium | | [eduPersonOrcid](edupersonorcid.html.md#saml-attribute-edupersonorcid) | Person’s ORCID IDs | Low | Low | | [eduPersonOrgDN:eduOrgLegalName](edupersonorgdn-eduorglegalname.html.md#saml-attribute-edupersonorgdn-eduorglegalname) | Home organization legal name | High | High | | [eduPersonOrgDN:mail](edupersonorgdn-mail.html.md#saml-attribute-edupersonorgdn-mail) | Home organization mail address | High | High | | [eduPersonOrgDN:norEduOrgNIN](edupersonorgdn-noreduorgnin.html.md#saml-attribute-edupersonorgdn-noreduorgnin) | Home organization’s organization number | High | High | | [eduPersonOrgDN:norEduOrgSchemaVersion](edupersonorgdn-noreduorgschemaversion.html.md#saml-attribute-edupersonorgdn-noreduorgschemaversion) | Home organization’s version of norEdu\* specification | High | High | | [eduPersonOrgDN:o](edupersonorgdn-o.html.md#saml-attribute-edupersonorgdn-o) | Home organization name | High | High | | [eduPersonOrgUnitDN](edupersonorgunitdn.html.md#saml-attribute-edupersonorgunitdn) | List of internal LDAP DNs for the user’s schools | Low | High | | [eduPersonOrgUnitDN:mail](edupersonorgunitdn-mail.html.md#saml-attribute-edupersonorgunitdn-mail) | School email address (primary and secondary school) | Low | High | | [eduPersonOrgUnitDN:norEduOrgUnitUniqueIdentifier](edupersonorgunitdn-noreduorgunituniqueidentifier.html.md#saml-attribute-edupersonorgunitdn-noreduorgunituniqueidentifier) | School unique identifier (primary and secondary schools) | Low | High | | [eduPersonOrgUnitDN:ou](edupersonorgunitdn-ou.html.md#saml-attribute-edupersonorgunitdn-ou) | School name (primary and secondary schools) | Low | High | | [eduPersonPrimaryAffiliation](edupersonprimaryaffiliation.html.md#saml-attribute-edupersonprimaryaffiliation) | Person’s primary role (ex. student, employee) | Medium | Medium | | [eduPersonPrimaryOrgUnitDN](edupersonprimaryorgunitdn.html.md#saml-attribute-edupersonprimaryorgunitdn) | Internal LDAP DN for the user’s primary school | Low | Medium | | [eduPersonPrincipalName](edupersonprincipalname.html.md#saml-attribute-edupersonprincipalname) | Person’s Feide ID | High | High | | [eduPersonPrincipalNamePrior](edupersonprincipalnameprior.html.md#saml-attribute-edupersonprincipalnameprior) | Person’s previous Feide IDs at the organization | Low | Low | | [eduPersonScopedAffiliation](edupersonscopedaffiliation.html.md#saml-attribute-edupersonscopedaffiliation) | Person’s role and organization | Low | Low | | [eduPersonTargetedID](edupersontargetedid.html.md#saml-attribute-edupersontargetedid) | Anonymous user identifier | High | High | | [feideSchoolList](feideschoollist.html.md#saml-attribute-feideschoollist) | List of school(s) the person is associated with | High | High | | [feideYearOfBirth](feideyearofbirth.html.md#saml-attribute-feideyearofbirth) | Person’s year of birth | High | High | | [givenName](givenname.html.md#saml-attribute-givenname) | Person’s first name | High | High | | [mail](mail.html.md#saml-attribute-mail) | Person’s email address | High | Medium | | [mobile](mobile.html.md#saml-attribute-mobile) | Person’s mobile telephone number | Medium | Low | | [norEduPersonLegalName](noredupersonlegalname.html.md#saml-attribute-noredupersonlegalname) | Person’s formal name | Medium | Medium | | [norEduPersonNIN](noredupersonnin.html.md#saml-attribute-noredupersonnin) | Person’s national identity number | High | High | | [preferredLanguage](preferredlanguage.html.md#saml-attribute-preferredlanguage) | Person’s preferred language | Low | Low | | [schacHomeOrganization](schachomeorganization.html.md#saml-attribute-schachomeorganization) | Realm for the person’s home organization | High | Low | | [sn](sn.html.md#saml-attribute-sn) | Person’s surname | High | High | | [uid](uid.html.md#saml-attribute-uid) | Person’s local username | High | High | More information about attribute availability: High: : The attribute is available for all users. Medium: : The attribute is not widely populated yet, but is mandatory as of norEdu\* specification v. 1.6. This means that the attribute will be available for all users gradually, but service providers should not rely on the attribute being available for all users yet. Low: : The attribute is usually not available for users. # cn ## Description Common name. General name on the person object. This attribute should not be considered unique across the educational sector. ## Format This multivalued attribute contains the person’s name(s). Can be the person’s full name or internal system name. ## Examples A user could have some or all of these values: * `Arnt Ola Nordmann` * `olanor123` * `Arnt Ola Olsen Nordmann` * `olanor123 (Arnt Ola Nordmann)` ## Technical details Cardinality: : Multivalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : person Short description: : General name on the person object # displayName ## Description The preferred name of a person to be used when displaying the person’s name. ## Format This singlevalued attribute is usually on the form: “firstname lastname” ## Examples A person can only have one value for displayName: * `Ola Nordmann` ## Technical details Cardinality: : Singlevalued Availability in higher education.: : Medium Availability, primary and secondary school.: : Medium Entry type: : person Short description: : Person’s preferred name # eduPersonAffiliation ![Hierarchy of roles showing first level entities member, affiliate, alum and library-walk in. Under member is shown student and employee. Under employee is showm faculty and staff.](reference/schema/attributes/roller.png) ## Description Specifies the person’s role at the organization in broad categories such as student, staff, employee etc. ## Format Permissible values are: faculty, student, staff, alum, member, affiliate, employee, library-walk-in. These are arranged in a hierarchy (as shown in the figure to the right). A student/pupil will have the values member and student. An educational employee will have all the values member, employee and faculty. A person serving as both principal and teacher will have the values member, employee, and both staff and faculty. The attribute [eduPersonPrimaryAffiliation](edupersonprimaryaffiliation.html.md#saml-attribute-edupersonprimaryaffiliation) gives the person’s primary role. ## Examples A pupil/student has all the values: * `student` * `member` A teacher (or in higher education: member of the scientific staff) has all the values: * `faculty` * `employee` * `member` An employee without any educational responsibility has all the values: * `staff` * `employee` * `member` The value “affiliate” is used to show that a person is affiliated with the organization, but that there is no formal contracts of employment or studying: * `affiliate` A person can fill several roles, in example be both an employee and a student at the same time. The person then has all the roles: * `student` * `staff` * `employee` * `member` Another example of multiple roles is when a person serves as both a principal and a teacher. In this case, the person holds the values of both staff and faculty. * `staff` * `faculty` * `employee` * `member` ## Technical details Cardinality: : Multivalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : person Short description: : Person’s role (ex. student, employee) # eduPersonAssurance ## Description Specifies the person’s identity assurance profiles (IAPs), which are the set of standards that are met by an identity assertion, based on the Home Organization’s identity management processes, the type of authentication credential used, the strength of its binding, etc. Feide populates this attribute with the corresponding profile defined by the Norwegian regulations, [Rammeverk for autentisering og uavviselighet i elektronisk kommunikasjon med og i offentlig sektor](https://www.regjeringen.no/no/dokumenter/rammeverk-for-autentisering-og-uavviseli/id505958/) (also known as FAD-08, only in Norwegian). ## Format The attribute values take the form of a URI that identifies the identity assurance profile that corresponds to a specific assertion. In Feide, the main profiles expressed will use the prefix `urn:mace:feide.no:auth:level:fad08:`, appended by a number from 1 to 4 (both included) that identifies the specific profile in use. ## Examples Currently, Feide supports two different two-factor authentication methods, based on text messages and Google Authenticator, both providing the same identity assurance profile: * `urn:mace:feide.no:auth:level:fad08:3` ## Technical details Cardinality: : Multivalued Availability in higher education.: : Low Availability, primary and secondary school.: : Low Entry type: : person Short description: : Set of URIs that assert compliance with specific standards for identity assurance # eduPersonEntitlement ## Description URI (either URN or URL) that indicates a set of rights to specific resources. A service might require that a user has a specific value registered here to allow access to the service. For primary and secondary education information about a pupil’s grade, subjects, major area etc is represented in codes according to the [Grep framework](https://data.udir.no/kl06) (governed by the Norwegian Directorate for Education and Training), prefixed by the string “urn:mace:feide.no:go:grep:”. Information on how to use Grep codes in your service can be found on the [Grep wiki](http://grepwiki.udir.no/index.php?title=Kom_i_gang). ## Format This multivalued attribute contains URIs (URNs and URLs). ## Examples Pupil in 6th grade in primary school: * `urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn6` Pupil in 3th grade in secondary school majoring in science: * `urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/vg3` * `urn:mace:feide.no:go:grep:http://psi.udir.no/ontologi/utdanningsprogram/studiespesialisering` * `urn:mace:feide.no:go:grep:uuid:5c682a18-585d-4a6b-bef9-bcd95c73714e` ## Technical details Cardinality: : Multivalued Availability in higher education.: : Low Availability, primary and secondary school.: : Medium Entry type: : person Short description: : URI indicating rights to specific resources (primary and secondary school: Grep codes) # eduPersonOrcid ## Description ORCID iDs are persistent digital identifiers for individual researchers. Their primary purpose is to unambiguously and definitively link them with their scholarly work products. ORCID iDs are assigned, managed and maintained by the [ORCID organization](https://orcid.org/). ## Format The [preferred format of the attribute](https://support.orcid.org/hc/en-us/articles/360006897674-Structure-of-the-ORCID-Identifier) is `https://orcid.org/xxxx-xxxx-xxxx-xxxx`. ## Examples * `https://orcid.org/0000-0002-1825-0097` ## Technical details Cardinality: : Multivalued Availability in higher education.: : Low Availability, primary and secondary school.: : Low Entry type: : person Short description: : Person’s ORCID IDs # eduPersonOrgDN:eduOrgLegalName ## Description The legal corporate name of the home organization. For primary schools, this is the legal corporate name of the municipality (kommune). For secondary schools, this is the legal corporate name of the county (fylkeskommune). For higher education this is the legal corporate name of the university college or university. ## Format This multivalued attribute contains an organization name. ## Examples A person associated with Vinje primary school in the municipality of Snåsa has the following value: * `Snåsa kommune` * `Snåasen tjielte` A person associated with Lien secondary school in Oppland county has the following value: * `Oppland fylkeskommune` A person associated with the University of Oslo has the following values: * `Universitetet i Oslo` * `University of Oslo` ## Technical details Cardinality: : Multivalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : org Short description: : Home organization legal name # eduPersonOrgDN:mail ## Description The home organization’s mail address. For primary school this is the mail address of the municipality (kommune). For secondary school this is the mail address of the county (fylkeskommune). For higher education this is the mail address of the university college or university. ## Format This multivalued attribute contains an email address. ## Example A person associated with Hylla primary school in Skotthyll kommune has the following value: * `info@skotthyll.kommune.no` A person associated with Lien secondary school in Oppland county has the following values: * `kontakt@oppland.fylke.no` * `skole@oppland.fylke.no` A person associated with Oslo University has the following value: * `post@uio.no` ## Technical details Cardinality: : Multivalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : org Short description: : Home organization mail address # eduPersonOrgDN:norEduOrgNIN ## Description The organization number assigned by the Norwegian Register of Business Enterprises (Brønnøysundregistrene, Foretaksregisteret) of the organization the user belongs to. For primary schools this is the organization number of the municipality the school belongs to. For secondary schools this is the organization number of the county the school belongs to. For higher education this is the organization number of the university or university college. ## Format The value of this attribute consists of “NO” followed by the nine-digit organization number. ## Examples A person associated with Hylla primary school in the municipality of Skotthyll has the following value: * `NO939377801` A person associated with Lien secondary school in Oppland county has the following value: * `NO974642069` A person associated with the Norwegian University of Science and Technology has the following value: * `NO974767880` ## Technical details Cardinality: : Singlevalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : org Short description: : Home organization’s organization number # eduPersonOrgDN:norEduOrgSchemaVersion ## Description This is the version number of the norEdu\* specification that is used at the home organization. The version number has impact on which attributes one should assume is available for the users at the home organization. If this number is “1.5” the attributes marked with availability “Medium” should be available. ## Format This singlevalued attribute contains a version number. ## Example A person from an organization using norEdu\* specification v.1.5 will have the following value: * `1.5` If the organization is still on version 1.4.1 of the norEdu\* specification, the attribute will have the following value: * `1.4.1` ## Technical details Cardinality: : Singlevalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : org Short description: : Home organization’s version of norEdu\* specification # eduPersonOrgDN:o ## Description For primary and secondary school this is the name of the school owner with which this person is associated. For primary school this is the name of the municipality (kommunen). For secondary school this is the name of the county (fylkeskommunen). For higher education this is the name of the top-level organization (university college or university) with which this person is associated. ## Format This multivalued attribute contains the name of the home organization. ## Examples A person associated with Hylla primary school in the municipality of Skotthyll has the following value: * `Skotthyll kommune` A person associated with Lien secondary school in Oppland county has the following value: * `Oppland fylkeskommune` A person associated with the University of Oslo has the following values: * `Universitetet i Oslo` * `University of Oslo` ## Technical details Cardinality: : Multivalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : org Short description: : Home organization name # eduPersonOrgUnitDN ## Description This attribute contains the internal “distinguished name” (DN) of the user’s schools in the home organizations user directory. This attribute can be used in conjunction with the [eduPersonPrimaryOrgUnitDN](edupersonprimaryorgunitdn.html.md#saml-attribute-edupersonprimaryorgunitdn) to determine which of the [eduPersonOrgUnitDN:mail](edupersonorgunitdn-mail.html.md#saml-attribute-edupersonorgunitdn-mail), [eduPersonOrgUnitDN:norEduOrgUnitUniqueIdentifier](edupersonorgunitdn-noreduorgunituniqueidentifier.html.md#saml-attribute-edupersonorgunitdn-noreduorgunituniqueidentifier) and [eduPersonOrgUnitDN:ou](edupersonorgunitdn-ou.html.md#saml-attribute-edupersonorgunitdn-ou) attributes belongs to the user’s primary school. More information about this is available on the [eduPersonPrimaryOrgUnitDN](edupersonprimaryorgunitdn.html.md#saml-attribute-edupersonprimaryorgunitdn) page. Note: This attribute should not be used to identify the user’s schools, since it isn’t unique across different organizations, and can be changed. ## Format This attribute contains a list of LDAP DNs. There will be one attribute value for each school ## Examples A student at Hylla skole: * `ou=Hylla skole,cn=organization,dc=Skotthyll,dc=kommune,dc=no` A teacher that works for both Hylla skole and Leira skole: * `ou=Hylla skole,cn=organization,dc=Skotthyll,dc=kommune,dc=no` * `ou=Leira skole,cn=organization,dc=Skotthyll,dc=kommune,dc=no` ## Technical details Cardinality: : Multivalued Availability in higher education.: : Low Availability, primary and secondary school.: : High Entry type: : orgunit Short description: : List of internal LDAP DNs for the user’s schools # eduPersonOrgUnitDN:mail ## Description For primary and secondary schools, this attribute contains the email address of the user’s schools. For higher education, no assumptions about the contents of this attribute can be made. ## Format The value of this attribute is a string containing the email address. If the school has multiple addresses, each address will be separated with a pipe symbol (‘|’). If the user belongs to multiple schools, each school will be sent in a separate attribute value. ## Example A person at Hylla school will have the following value: * `hylla@skotthyll.kommune.no` If the school uses multiple addresses, each address will be separated by a ‘|’: * `hylla@skotthyll.kommune.no|post@hylla.skotthyll.kommune.no` A teacher working at both Hylla school and Skott school will have one attribute value for each school: * `hylla@skotthyll.kommune.no|post@hylla.skotthyll.kommune.no` * `skott@skotthyll.kommune.no` ## Technical details Cardinality: : Multivalued Availability in higher education.: : Low Availability, primary and secondary school.: : High Entry type: : orgunit Short description: : School email address (primary and secondary school) # eduPersonOrgUnitDN:norEduOrgUnitUniqueIdentifier ## Description For primary and secondary schools, this attribute contains the unique identifier of the user’s schools. For higher education, no assumptions about the contents of this attribute can be made. ## Format The value of this attribute consists of “NO” followed by the nine-digit organization number. ## Example A student at Lade skole will have the following value: * `NO975278921` A teacher working at multiple schools will have one number for each school: * `NO975278921` * `NO975289443` ## Technical details Cardinality: : Multivalued Availability in higher education.: : Low Availability, primary and secondary school.: : High Entry type: : orgunit Short description: : School unique identifier (primary and secondary schools) # eduPersonOrgUnitDN:ou ## Description For primary and secondary schools, this attribute contains the official name of the user’s schools. For higher education, no assumptions about the contents of this attribute can be made. ## Format A string with the name of the user’s school. f the school has multiple names, each name will be separated by a pipe (‘|’). If the user belongs to multiple schools, the name of each school will be delivered in a separate attribute value. ## Example A student at Hylla skole may have the following value: * `Hylla skole` If the school uses multiple names, each name will be separated by ‘|’: * `Hylla skole|Hylla` A teacher working at multiple schools will have one value for each school: * `Hylla skole|Hylla` * `Lade skole` ## Technical details Cardinality: : Multivalued Availability in higher education.: : Low Availability, primary and secondary school.: : High Entry type: : orgunit Short description: : School name (primary and secondary schools) # eduPersonPrimaryAffiliation ## Description Specifies the person’s primary role at the home organization in broad categories such as student, faculty, staff, alum, etc. See also [eduPersonAffiliation](edupersonaffiliation.html.md#saml-attribute-edupersonaffiliation). ## Format See also [eduPersonAffiliation](edupersonaffiliation.html.md#saml-attribute-edupersonaffiliation). The most common values for eduPersonPrimaryAffiliation are *employee* for employees and *student* for students/pupils. ## Examples A pupil/student has the value: * `student` A teacher has the value: * `employee` ## Technical details Cardinality: : Singlevalued Availability in higher education.: : Medium Availability, primary and secondary school.: : Medium Entry type: : person Short description: : Person’s primary role (ex. student, employee) # eduPersonPrimaryOrgUnitDN ## Description This attribute contains the internal “distinguished name” (DN) of the user’s primary school in the home organizations user directory. This attribute can be used in conjunction with the [eduPersonOrgUnitDN](edupersonorgunitdn.html.md#saml-attribute-edupersonorgunitdn) to determine which of the [eduPersonOrgUnitDN:mail](edupersonorgunitdn-mail.html.md#saml-attribute-edupersonorgunitdn-mail), [eduPersonOrgUnitDN:norEduOrgUnitUniqueIdentifier](edupersonorgunitdn-noreduorgunituniqueidentifier.html.md#saml-attribute-edupersonorgunitdn-noreduorgunituniqueidentifier) and [eduPersonOrgUnitDN:ou](edupersonorgunitdn-ou.html.md#saml-attribute-edupersonorgunitdn-ou) attributes belongs to the user’s primary school. To determine the primary school’s name, you need to find the index of the eduPersonPrimaryOrgUnitDN attribute in the eduPersonOrgUnitDN attribute. You can then look up the corresponding index in the eduPersonOrgUnitDN:ou attribute to determine the name. Note: This attribute should not be used to identify the user’s school, since it isn’t unique across different organizations, and can be changed. ## Format This attribute contains a single LDAP DN. ## Examples A student at Hylla skole: * `ou=Hylla skole,cn=organization,dc=Skotthyll,dc=kommune,dc=no` A teacher at Leira skole: * `ou=Leira skole,cn=organization,dc=Skotthyll,dc=kommune,dc=no` ## Technical details Cardinality: : Singlevalued Availability in higher education.: : Low Availability, primary and secondary school.: : Medium Entry type: : orgunit Short description: : Internal LDAP DN for the user’s primary school # eduPersonPrincipalName ## Description This attribute identifies the user that logged in to Feide. This attribute is guaranteed unique across the educational sector. ## Format The format of the attribute is `username@realm`, where `username` is the person’s username, while `realm` identifies the home organization the user belongs to. ## Examples A person with username olanor123 from Skotthyll kommune: * `olanor123@skotthyll.kommune.no` ## Technical details Cardinality: : Singlevalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : person Short description: : Person’s Feide ID # eduPersonPrincipalNamePrior ## Description This attribute may contain eduPersonPrincipalNames the user have previously had **at the same legal organization**, either because the principal name has been changed for some reason or through a merger of organizations. ## Format The format of the attribute is `username@realm`, where `username` is the person’s previous username(s), while `realm` identifies the home organization(s) the user belonged to. ## Examples A person with username olanor567 from Skotthyll kommune: * `olanor567@skotthyll.kommune.no` ## Technical details Cardinality: : Multivalued Availability in higher education.: : Low Availability, primary and secondary school.: : Low Entry type: : person Short description: : Person’s previous Feide IDs at the organization # eduPersonScopedAffiliation ## Description Specifies the person’s role and home organization or school. See also [eduPersonAffiliation](edupersonaffiliation.html.md#saml-attribute-edupersonaffiliation). ## Format Syntax for eduPersonScopedAffiliation is: ```default @. ``` and ```default @ ``` “Affiliation” has to be one of the values in “eduPersonAffiliation”, while “realm” equals the right part (after @) of “eduPersonPrincipalName”. ## Examples A pupil from Lade school in Trondheim kommune has the values: * `student@trondheim.kommune.no` * `student@no975278921.trondheim.kommune.no` A student at NTNU has the value: * `student@ntnu.no` A lecturer at NTNU has the value: * `employee@ntnu.no` ## Technical details Cardinality: : Multivalued Availability in higher education.: : Low Availability, primary and secondary school.: : Low Entry type: : person Short description: : Person’s role and organization # eduPersonTargetedID ## Description This is a persistent, non-reassigned, privacy-preserving identifier for a person. Feide recommends using this as an identifier. * Persistent: The service will receive the same value each time the user logs in. * Non-reassigned: No other users will ever be assigned the same value at a later time. * Privacy-preserving: This is a pseudo-random identifying string which reveals no information about the user. ## Format This attribute is singlevalued per service, and is a pseudo-random string. It will not exceed 256 characters in length. ## Example A person has the following value: * `24d66f51ac1c0b140e617af335b9abb4b8d88a5b` ## Technical details Cardinality: : Singlevalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : person Short description: : Anonymous user identifier # eduPersonUniqueId ## 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. ## Format This identifier is scoped to the domain of the organization. It has the format `uniqueID@domain`. The “uniqueID” portion is unique within the organization. It is a string of up to 64 alphanumeric characters (a-z, A-Z, 0-9). The “domain” portion is the same domain name as used to identify the users organization in other attributes, e.g. `eduPersonPrincipalName` and `schacHomeOrganization`. ## Examples eduPersonUniqueId: `28c5353b8bb34984a8bd4169ba94c606@foo.edu` ## Technical details Cardinality: : Singlevalued Entry type: : person Short description: : Person’s long-lived, non re-assignable ID. ## Notes This attribute is only used for special purposes right now, but will be added to the next schema version. For more information about the identifier, see [Person and account identifiers in Feide](../identifiers/index.html.md) # feideSchoolList ## Description A list of the organization number of all the schools the person belongs to. The primary school is listed first. ## Format This attribute consist of “NO” followed by the nine-digit organization number. If the user belongs to multiple schools, each school will appear as a separate attribute value with the primary school organization number listed first (if one is listed as primary organization unit). For higher education, only the organization number of the university college or university will be listed. ## Examples A pupil at Manstad school has the following value: * `NO974565633` A teacher working for Valle secondary school, and sometimes substituting in History at Lena secondary school, has the following values: * `NO974597403` * `NO974597322` ## Note This attribute is generated by Feide based on the values of `eduPersonOrgDN:norEduOrgNIN` (for university and university colleges) and `eduPersonOrgUnitDN:norEduOrgUnitUniqueIdentifier` (for primary and secondary schools). ## Technical details Cardinality: : Multivalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : person Short description: : List of school(s) the person is associated with # feideYearOfBirth ## Description The year of birth for this person. ## Note This is a temporary attribute that has been added due to the delayed rollout of GREP codes. It can be used to guess the person’s grade. Feide generates this attribute based on the person’s national identity number. The attribute is scheduled for removal during the summer of 2012. ## Format This attribute consist of four digits with the person’s year of birth. ## Examples A pupil born in 2002: * `2002` A teacher born in 1967: * `1967` ## Note This attribute is generated by Feide based on information in the `norEduPersonBirthDate` attribute if it is available. If it is not available, we will attempt to extract the year of birth from the national identity number (`norEduPersonNIN`). ## Technical details Cardinality: : Singlevalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : person Short description: : Person’s year of birth # givenName ## Description Contains names that are part of the person’s first name (not their surname). ## Format This multivalued attribute contains name strings. ## Examples A person named Arnt Ola Olsen Nordmann has the value: * `Arnt Ola` A person named Kari Hansine Hansen has the value: * `Kari` ## Technical details Cardinality: : Multivalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : person Short description: : Person’s first name # mail ## Description A personal email address. This attribute should not be considered unique across the educational sector. ## Format This multivalued attribute is usually on the form `name@some.domain`. ## Examples A person from university college or university has one or more of the following values: * `ola.nordmann@stud.universitetet.no` * `olanor123@stud.universitetet.no` * `olanord@gmail.com` ## Technical details Cardinality: : Multivalued Availability in higher education.: : High Availability, primary and secondary school.: : Medium Entry type: : person Short description: : Person’s email address # mobile ## Description A personal mobile telephone number. The attribute is not recommended used when sending out one-time password etc. ## Format This multivalued attribute is usually on the form +47 followed by an eight digit telephone number. ## Examples A person from university college or university has one or more of the following values: * `+47 40404040` * `+47 44444444` ## Technical details Cardinality: : Multivalued Availability in higher education.: : Medium Availability, primary and secondary school.: : Low Entry type: : person Short description: : Person’s mobile telephone number # norEduPersonLegalName ## Description The person’s full formal name as registered by public authorities. ## Format This singlevalued attribute contains a name. ## Example A person registered as Arnt Ola Olsen Nordmann by public authorities (Folkeregistreret) has the following value: * `Arnt Ola Olsen Nordmann` ## Technical details Cardinality: : Singlevalued Availability in higher education.: : Medium Availability, primary and secondary school.: : Medium Entry type: : person Short description: : Person’s formal name # norEduPersonNIN ## Description This is a unique personal identity number issued by the National Registry (Folkeregisteret), Norwegian Directorate of Immigration (Utlendingsdirektoratet, UDI) or The Norwegian Universities and Colleges Admission Service (Samordna Opptak): * Norwegian personal number (fødselsnummer) * provisional Norwegian personal number (D-nummer) * DUF number * S number/SO number If a person does not fulfill the requirements for any of these numbers, no value will be registered. This attribute is by the general public and Feide considered as semi-sensitive information. This attribute is only released where actual need is demonstrated. ## Format `norEduPersonNIN` is purely numeric. ## Example Ola Nordmann has the following value: * `28089533134` ## Technical details Cardinality: : Singlevalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : person Short description: : Person’s national identity number # preferredLanguage ## Description The preferred written or spoken language for a person. ## Format Attribute values are restricted to two or three letter codes according to BCP 47: nn (Norwegian, nynorsk), nb (Norwegian, bokmål), no (Norwegian), en (English), se (Northern Sami), sma (Southern Sami) or smj (Lule Sami), used in accordance with recommendation in [BCP 47](https://www.rfc-editor.org/bcp/bcp47.txt) based on [ISO 639](https://www.w3.org/WAI/ER/IG/ert/iso639.htm) and [ISO 3166](https://www.iso.org/iso-3166-country-codes.html) country codes. ## Examples A person preferring nynorsk has the following value: * `nn` Another person preferring bokmål has the following value: * `nb` ## Technical details Cardinality: : Singlevalued Availability in higher education.: : Low Availability, primary and secondary school.: : Low Entry type: : person Short description: : Person’s preferred language # schacHomeOrganization ## Description Specifies a person’s home organization using the realm of the organization. The realm must be identical to the suffix in the person’s eduPersonPrincipalName. ## Format Domain name formating according to RFC 1035. ## Example * `ntnu.no` ## Technical details Cardinality: : Singlevalued Availability in higher education.: : High Availability, primary and secondary school.: : Low Entry type: : person Short description: : Realm for the person’s home organization # sn ## Description This is the person’s surname or family name. ## Format This multivalued attribute contains one or more names. ## Examples Person named Arnt Ola Olsen Nordmann has the following values: * `Nordmann` * `Olsen Nordmann` Person named Kari Hansine Hansen has the following value: * `Hansen` ## Technical details Cardinality: : Multivalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : person Short description: : Person’s surname # uid ## Description This is the person’s local username at the home organization. This attribute is not unique across the educational sector, and should therefore not be used as an identifier outside of the home organization. ## Format This multivalued attribute contains a local user ID. ## Examples Person Arnt Ola Olsen Nordmann has the following value: * `olanor123` ## Technical details Cardinality: : Multivalued Availability in higher education.: : High Availability, primary and secondary school.: : High Entry type: : person Short description: : Person’s local username # 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](#edupersonprincipalname) * [OpenID Connect subject identifier](#openid-connect-subject-identifier) * [eduPersonUniqueId](#edupersonuniqueid) * [uid](#uid) * [norEduPersonNIN](#noredupersonnin) * [email](#email) * [UH ID](#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](mailto: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".](reference/schema/identifiers/identifier1.png) **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".](reference/schema/identifiers/identifier2.png) 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".](reference/schema/identifiers/identifier3.png) ## 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: ```json { "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](mailto: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: ```json { "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. # The Feide information model for lower education **Usage of norEdu\* Object Class Specification v.2.0 for lower education** **Attribute document**
Version Date Initials Comments
2018-03 March 2018 SL New version based on norEdu\*-specification version 2.0. New requirements for group-IDs in lower education. See changelog for more details.
2015-09 September 2015 HV, JPC, SL New version based on norEdu\*-specification version 1.6. New requirements for group information and strong authentication. See changelog for more details.
* [Overview of the Feide LDAP structure](go_attributter_ch01.html.md) * [Object-classes](go_attributter_ch01.html.md#object-classes) * [Attributes](go_attributter_ch01.html.md#attributes) * [Person](go_attributter_ch02.html.md) * [Terminology](go_attributter_ch02.html.md#terminology) * [Mandatory - person](go_attributter_ch02.html.md#mandatory-person) * [cn](go_attributter_ch02.html.md#cn) * [displayName](go_attributter_ch02.html.md#displayname) * [norEduPersonLegalName](go_attributter_ch02.html.md#noredupersonlegalname) * [givenName](go_attributter_ch02.html.md#givenname) * [sn](go_attributter_ch02.html.md#sn) * [eduPersonPrincipalName](go_attributter_ch02.html.md#edupersonprincipalname) * [uid](go_attributter_ch02.html.md#uid) * [norEduPersonNIN](go_attributter_ch02.html.md#noredupersonnin) * [userPassword](go_attributter_ch02.html.md#userpassword) * [eduPersonOrgDN](go_attributter_ch02.html.md#edupersonorgdn) * [eduPersonOrgUnitDN](go_attributter_ch02.html.md#edupersonorgunitdn) * [eduPersonPrimaryOrgUnitDN](go_attributter_ch02.html.md#edupersonprimaryorgunitdn) * [eduPersonAffiliation](go_attributter_ch02.html.md#edupersonaffiliation) * [eduPersonEntitlement](go_attributter_ch02.html.md#edupersonentitlement) * [norEduPersonAuthnMethod](go_attributter_ch02.html.md#noredupersonauthnmethod) * [norEduPersonServiceAuthnLevel](go_attributter_ch02.html.md#noredupersonserviceauthnlevel) * [Recommended - person](go_attributter_ch02.html.md#recommended-person) * [mail](go_attributter_ch02.html.md#mail) * [mobile](go_attributter_ch02.html.md#mobile) * [preferredLanguage](go_attributter_ch02.html.md#preferredlanguage) * [schacHomeOrganization](go_attributter_ch02.html.md#schachomeorganization) * [eduPersonPrimaryAffiliation](go_attributter_ch02.html.md#edupersonprimaryaffiliation) * [eduPersonScopedAffiliation](go_attributter_ch02.html.md#edupersonscopedaffiliation) * [Organization](go_attributter_ch03.html.md) * [Mandatory - organization](go_attributter_ch03.html.md#mandatory-organization) * [eduOrgLegalName](go_attributter_ch03.html.md#eduorglegalname) * [o](go_attributter_ch03.html.md#o) * [norEduOrgNIN](go_attributter_ch03.html.md#noreduorgnin) * [mail](go_attributter_ch03.html.md#mail) * [norEduOrgSchemaVersion](go_attributter_ch03.html.md#noreduorgschemaversion) * [Recommended - organization](go_attributter_ch03.html.md#recommended-organization) * [telephoneNumber](go_attributter_ch03.html.md#telephonenumber) * [postalAddress](go_attributter_ch03.html.md#postaladdress) * [Organizational unit](go_attributter_ch04.html.md) * [Mandatory - organizational unit](go_attributter_ch04.html.md#mandatory-organizational-unit) * [ou](go_attributter_ch04.html.md#ou) * [norEduOrgUnitUniqueIdentifier](go_attributter_ch04.html.md#noreduorgunituniqueidentifier) * [mail](go_attributter_ch04.html.md#mail) * [Recommended - organizational unit](go_attributter_ch04.html.md#recommended-organizational-unit) * [telephoneNumber](go_attributter_ch04.html.md#telephonenumber) * [postalAddress](go_attributter_ch04.html.md#postaladdress) * [Optional attributes - person and organization](go_attributter_ch05.html.md) * [norEduOrgAcronym](go_attributter_ch05.html.md#noreduorgacronym) * [norEduPersonBirthDate](go_attributter_ch05.html.md#noredupersonbirthdate) * [norEduPersonLIN](go_attributter_ch05.html.md#noredupersonlin) * [eduOrgIdentityAuthNPolicyURI](go_attributter_ch05.html.md#eduorgidentityauthnpolicyuri) * [eduOrgHomePageURI](go_attributter_ch05.html.md#eduorghomepageuri) * [eduOrgWhitePagesURI](go_attributter_ch05.html.md#eduorgwhitepagesuri) * [eduPersonAssurance](go_attributter_ch05.html.md#edupersonassurance) * [eduPersonNickname](go_attributter_ch05.html.md#edupersonnickname) * [eduPersonPrincipalNamePrior](go_attributter_ch05.html.md#edupersonprincipalnameprior) * [eduPersonOrcid](go_attributter_ch05.html.md#edupersonorcid) * [facsimileTelephoneNumber](go_attributter_ch05.html.md#facsimiletelephonenumber) * [homePhone](go_attributter_ch05.html.md#homephone) * [homePostalAddress](go_attributter_ch05.html.md#homepostaladdress) * [jpegPhoto](go_attributter_ch05.html.md#jpegphoto) * [l (localityName)](go_attributter_ch05.html.md#l-localityname) * [labeledURI](go_attributter_ch05.html.md#labeleduri) * [manager](go_attributter_ch05.html.md#manager) * [postalCode](go_attributter_ch05.html.md#postalcode) * [postOfficeBox](go_attributter_ch05.html.md#postofficebox) * [street](go_attributter_ch05.html.md#street) * [title](go_attributter_ch05.html.md#title) * [userCertificate](go_attributter_ch05.html.md#usercertificate) * [userSMIMECertificate](go_attributter_ch05.html.md#usersmimecertificate) * [Changelog](go_attributter_ch06.html.md) * [From version 2012-02 to version 2013-10](go_attributter_ch06.html.md#from-version-2012-02-to-version-2013-10) * [From version 2014-01 to 2015-09](go_attributter_ch06.html.md#from-version-2014-01-to-2015-09) * [From version 2015-09 to 2018-03](go_attributter_ch06.html.md#from-version-2015-09-to-2018-03) * [Appendix 1 - LDIF-example](go_attributter_chA1.html.md) * [Person](go_attributter_chA1.html.md#person) * [Organization (School owner)](go_attributter_chA1.html.md#organization-school-owner) * [Organizational unit (School)](go_attributter_chA1.html.md#organizational-unit-school) * [Appendix 2 - Registration of Grep-codes within eduPersonEntitlement](go_attributter_chA2.html.md) * [Terminology](go_attributter_chA2.html.md#terminology) * [Teachers](go_attributter_chA2.html.md#teachers) * [Students in 1.-10.grade](go_attributter_chA2.html.md#students-in-1-10-grade) * [Students in videregående](go_attributter_chA2.html.md#students-in-videregaende) * [Grep-codes registered in school-administrative systems](go_attributter_chA2.html.md#grep-codes-registered-in-school-administrative-systems) * [Appendix 3 - Registration of group information within eduPersonEntitlement](go_attributter_chA3.html.md) * [Everyone that is connected to the group shall have the information registered](go_attributter_chA3.html.md#everyone-that-is-connected-to-the-group-shall-have-the-information-registered) * [Group types](go_attributter_chA3.html.md#group-types) * [Information elements about group and the person’s relation to the group](go_attributter_chA3.html.md#information-elements-about-group-and-the-person-s-relation-to-the-group) * [Formatting of group information](go_attributter_chA3.html.md#formatting-of-group-information) * [Case-sensitivity](go_attributter_chA3.html.md#case-sensitivity) * [Examples for group information in eduPersonEntitlement](go_attributter_chA3.html.md#examples-for-group-information-in-edupersonentitlement) * [Student in basis-group/class 6A at Berg school (Trondheim kommune)](go_attributter_chA3.html.md#student-in-basis-group-class-6a-at-berg-school-trondheim-kommune) * [Teacher in teaching group 2kja at Tiller VGS](go_attributter_chA3.html.md#teacher-in-teaching-group-2kja-at-tiller-vgs) * [Student in teaching group Norsk VG3 at Tiller VGS](go_attributter_chA3.html.md#student-in-teaching-group-norsk-vg3-at-tiller-vgs) * [Student in lab-group 3 Fysikk VG3 at Tiller VGS](go_attributter_chA3.html.md#student-in-lab-group-3-fysikk-vg3-at-tiller-vgs) * [Appendix 4 - Registration of group-IDs in eduPersonEntitlement](go_attributter_chA4.html.md) * [Everyone affiliated with the group shall have the identifier registered](go_attributter_chA4.html.md#everyone-affiliated-with-the-group-shall-have-the-identifier-registered) * [Relation to group information](go_attributter_chA4.html.md#relation-to-group-information) * [Construction of group-IDs](go_attributter_chA4.html.md#construction-of-group-ids) * [Formatting of group-IDs](go_attributter_chA4.html.md#formatting-of-group-ids) * [Examples with group-IDs in eduPersonEntitlement](go_attributter_chA4.html.md#examples-with-group-ids-in-edupersonentitlement) * [Student in basis-group/class 6A at Berg skole (Trondheim kommune)](go_attributter_chA4.html.md#student-in-basis-group-class-6a-at-berg-skole-trondheim-kommune) * [Teacher in teaching group 2kja at Tiller vgs](go_attributter_chA4.html.md#teacher-in-teaching-group-2kja-at-tiller-vgs) * [Student in teaching group Norsk VG3 at Tiller vgs](go_attributter_chA4.html.md#student-in-teaching-group-norsk-vg3-at-tiller-vgs) * [Student in lab-group 3 Fysikk VG3 at Tiller vgs](go_attributter_chA4.html.md#student-in-lab-group-3-fysikk-vg3-at-tiller-vgs) # Overview of the Feide LDAP structure ## Object-classes The structural requirements that Feide sets for the organization’s LDAP-catalogue are based on [«norEdu\* Object Class Specification»](../noredu/index.html.md). In addition to the specification, this document defines mandatory and recommended attributes for organizations in lower education from the norEdu\*-specification. The LDAP-catalogue with user-data located at the organizations is organized in a tree-structure. Within this structure lies nodes which are a collection of attributes and related data for: - persons - organization (school-owner) - organizational units (schools) norEdu\*-specification defines three important object classes: - norEduPerson - norEduOrg - norEduOrgUnit Each object class defines a set of attributes. Multiple object classes used in combination can yield a larger set of attributes, which results in all the information about a person, organization or organizational unit. For instance, a node with person-information will have attributes from the object classes `norEduPerson`, `schac`, `eduPerson` and `inetOrgPerson`. `inetOrgPerson` will use attributes from the object classes `person`, `organizationalPerson` and `top`. For more about object classes [«norEdu\* Object Class Specification»](../noredu/index.html.md). The two attributes (`eduPersonOrgDN` and `eduPersonOrgUnitDN`) describes which school owner and which schools a person is affiliated to. These attributes contains a unique pointer to nodes within the catalogue tree which contains information for school owner and schools. eduPersonPrimaryOrgUnitDN describes which school the person has their main affiliation to. The different nodes for person, organization and organizational units and the relational connections for these are shown below in Figure 1. ## Attributes When a user log in to a service through Feide, the service receives data describing user authentication and a collection of information elements that belongs to this user. Which information elements that the service receives are limited through an agreement with Feide and the service. In Feide we use the term *attributes* for the different information elements. In general, it is recommended to put as much information in the Feide catalogue as possible, and within the norEdu\*-specification you can find attributes for many different information elements. Quite a lot of the services request an increasingly number of types for the information elements, and the organizations that places large amounts of information in the Feide catalogue will be able to utilize the different services connected to Feide more effectively. In the customer portal, the host organizations can view which attributes a service receives. The host organization is responsible for the agreement between organization and service which describes the data processing details which regulates how the service uses the organization’s information. To make it easier for the host organizations and the services, Feide has chosen to classify attributes within three categories: - **Mandatory** – Shall be placed within Feide catalogue - **Recommended** – Recommended to be placed within Feide catalogue - **Optional** – These are all optional and it is up to the organization itself to decide if it want to add these to the Feide catalogue Mandatory and recommended attributes are attributes that the services expects to be delivered today. Despite this classification, Feide will encourage the host organizations to place as much information as possible within the Feide catalogue. A quick overview of mandatory, recommended and optional attributes can be found within this document. ![Figure showing person, organization and organizational unit within the Feide catalogue](reference/schema/info_go/go_attributter_figur01.jpg) # Person ## Terminology Årstrinn : Students grouped in year of the education they are attending to. Example is after kindergarten the persons starts in årstrinn 1. Then proceeds to årstrinn 2 the next year. Studieprogram : Program of study. A student is typically admitted to a particular *studieprogram* Kull : All students in a *studieprogram* admitted in a given year Klasse : A subdivision of a *kull* ## Mandatory - person ### cn
Attribute name cn
Short description General node name with person-information
Example cn: Arnt Nordmann
and/or
cn: olanor123
Multivalued Yes
### displayName
Attribute name displayName
Short description Person's preferred name.
Example displayName: Ola Nordmann
Multivalued No
### norEduPersonLegalName
Attribute name norEduPersonLegalName
Short description Person's legal name. Example can be person's name registered within Folkeregisteret.
Example norEduPersonLegalName: Arnt Ola Olsen Nordmann
Multivalued No
### givenName
Attribute name givenName
Short description Person's first name.
Example givenName: Ola
Multivalued Yes
### sn
Attribute name sn
Short description Person's surname.
Example sn: Nordmann
and/or
sn: Olsen Nordmann
Multivalued Yes
### eduPersonPrincipalName
Attribute name eduPersonPrincipalName
Short description Full Feide name.
Example eduPersonPrincipalName: olanor123@skotthyll.kommune.no
Multivalued No
`eduPersonPrincipalName` Is per definition non case sensitive. [OlaNor123@uin.no](mailto:OlaNor123@uin.no) is the same Feide name as [olanor123@uin.no](mailto:olanor123@uin.no). Even though the `eduPersonPrincipalName` is per definition non case sensitive, it will be added to the Feide catalogue in lower case for the sake of compatibility with other systems `eduPersonPrincipalName` should never be reused by a new person. The organization has to ensure that `eduPersonPrincipalName` is unique. If the organization chooses to reuse a `eduPersonPrincipalName` which is not in active use, the organization itself is responsible of making sure that this does not lead to any issues. For instance, `eduPersonPrincipalName` might have been used as an identifier in external systems/services, and this is something the organization has to take into consideration. `eduPersonPrincipalName` is comprised of two parts: @. Note that when the domain name is used as realm, this should be subject to a domain that the host organization is the registered owner for. The first part of `eduPersonPrincipalName` (before “@”) should equal `uid`. ### uid
Attribute Name uid
Short description The person's local username at the school-owner.
Example uid: olanor123
Multivalued Yes
Even though `uid` is multivalued in the first place, one should only register one value for this field. `uid` is non case sensitive, but should be entered into the catalogue in the same manner as `eduPersonPrincipalName`, alas in lower case. The first part of `eduPersonPrincipalName` shall be comprised of `uid`, before “@”. ### norEduPersonNIN
Attribute Name norEduPersonNIN
Short description National identity number.
Example norEduPersonNIN: 28089533134
Multivalued No
`norEduPersonNIN` Shall be a unique identification number issued by Folkeregisteret or Utlendingsdirektoratet (UDI): - National identity number - D-number - DUF-number If a person does not have any of these numbers, no value should be registered within `norEduPersonNIN` for this person A person can have a user in Feide without a value in `norEduPersonNIN`. This will not be an issue for most services, but for services that depend on `norEduPersonNIN`, the school-owner will have to find other solutions to grant access to the service for the user. Locally issued national identity numbers can be added to [norEduPersonLIN_GO](../noredu/noredu_ch03.html.md#noredupersonlin). ### userPassword
Attribute Name userPassword
Short description Person's password for Feide login.
Example userPassword: {CRYPT}$6$ufxrIZTs$hl3ocEOAb01o3HC1yk1DUTD6aaHnH7xD5ZDFCH9xnoNUWZky6lt0/
Multivalued Yes
Even though `userPassword` is multivalued in the first place, it is common to register only one password in this field. In this document, `userPassword` is set as a mandatory attribute because all users have to have one password at login. It’s worth mentioning that a password can be handled automatically by the catalogue system, and the need to handle this directly might not be needed. As long as each person can perform authentication towards the catalogue system, and thus Feide, with a concrete password. ### eduPersonOrgDN
Attribute Name eduPersonOrgDN
Short description Pointer to the LDAP node that contains information about the school-owner affiliated with the person.
Example eduPersonOrgDN: dc=Skotthyll,dc=kommune,dc=no
Multivalued No
### eduPersonOrgUnitDN
Attribute Name eduPersonOrgUnitDN
Short description Pointer to the LDAP node that contains information about the organizational unit(s) affiliated with the person.
Example eduPersonOrgDN: ou=Hylla skole,cn=organization,dc=Skotthyll,dc=kommune,dc=no
Multivalued Yes
`eduPersonOrgUnitDN` is mandatory for persons affiliated with a school. For those persons that needs a Feide user on a day to day basis, but having no affiliation with a school, there shall not be registered any value within `eduPersonOrgUnitDN` ### eduPersonPrimaryOrgUnitDN
Attribute Name eduPersonPrimaryOrgUnitDN
Short description Pointer to the LDAP node that contains information about the organizational unit that the person has its main affiliation to.
Example eduPersonPrimaryOrgUnitDN: ou=Hylla skole,cn=organization,dc=Skotthyll,dc=kommune,dc=no
Multivalued No
For clarification, the value used within `eduPersonPrimaryOrgUnitDN` also has to be present within `eduPersonOrgUnitDN` ### eduPersonAffiliation
Attribute Name eduPersonAffiliation
Short description Roles at school-owner.
Example eduPersonAffiliation: member
eduPersonAffiliation: student

or

eduPersonAffiliation: faculty
eduPersonAffiliation: employee
eduPersonAffiliation: member
Multivalued Yes
`eduPersonAffiliation` contains information about the person’s general roles at the organization. Within figure 2 a small set of general roles have been presented as a hierarchy. A student will have all of these values: - `eduPersonAffiliation: student` - `eduPersonAffiliation: member` A pedagogical employee will have all these values: - `eduPersonAffiliation: faculty` - `eduPersonAffiliation: employee` - `eduPersonAffiliation: member` A non pedagogical employee will have all these values: - `eduPersonAffiliation: staff` - `eduPersonAffiliation: employee` - `eduPersonAffiliation: member` The value “affiliate” is used to express that a person is affiliated with the organization, but without any formal contracts related to employment or a position as student(for example students attending a private school) - `eduPersonAffiliation: affiliate` A person can have multiple roles, for instance both be an employee and a student: - `eduPersonAffiliation: student` - `eduPersonAffiliation: staff` - `eduPersonAffiliation: employee` - `eduPersonAffiliation: member` Another example of multiple roles is when a person serves as both a principal and a teacher. In this case, the person holds the values of both staff and faculty. - `eduPersonAffiliation: staff` - `eduPersonAffiliation: faculty` - `eduPersonAffiliation: employee` - `eduPersonAffiliation: member` ![Figure showing the role hierarchy for eduPersonAffiliation values. Shows a tree structure with different branches for affiliation values. There are four branches off the root - "member", "affiliate", "alum" and "library-walk-in". The branches for "affiliate", "alum" and "library-walk-in" have no additional affiliations. The "member" affiliation has two child branches - "student" and "employee". The "employee" branch has two additional child branches - "faculty" and "staff". The "student" branch does not have any additional branches.](reference/schema/info_go/go_attributter_figur02.jpg) ### eduPersonEntitlement
Attribute Name eduPersonEntitlement
Short description Information about rights, roles and groups that this person has.
Example Example for årstrinn:
eduPersonEntitlement:
urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn6

Example for studieprogram:
eduPersonEntitlement:
urn:mace:feide.no:go:grep:http://psi.udir.no/ontologi/utdanningsprogram/studiespesialisering

Example for basis-group:
eduPersonEntitlement:
urn:mace:feide.no:go:group:b::NO975278964:6A:2014-08-01:2015-06-15:student:Klasse%206A

Example for teaching group:
eduPersonEntitlement:
urn:mace:feide.no:go:group:u:NOR1211:NO974558386:3aaa%2F3nh:2014-08-01:2015-06-15:student:Norsk%20hovedm%C3%A5l%20VG3

Example for other group:
eduPersonEntitlement:
urn:mace:feide.no:go:group:a::NO974558386:3fysa%2Flb3:2014-08-01:2014-12-31:student:Labgruppe%203%20Fysikk%20VG3

Example for group-IDs:
eduPersonEntitlement:
urn:mace:feide.no:go:groupid:b:NO975278964:6a:2014-08-01:2015-06-15
eduPersonEntitlement:
urn:mace:feide.no:go:groupid:u:NO974558386:3aaa%2F3nh:2014-08-01:2015-06-15
eduPersonEntitlement:
urn:mace:feide.no:go:groupid:a:NO974558386:3fysa%2Flb3:2014-08-01:2014-12-31
Multivalued Yes
`eduPersonEntitlement` contains specific rights or roles that the person has. This can be expressed as a job code or specific rights related to a specific service. As long as any such information is present for a person, the general recommendation is that this is registered within `eduPersonEntitlement` Values used in the field for eduPersonEntitlement shall be valid URIs(Uniform Resource Identifier). We recommend the use of URNs(Uniform Resource Name). If new URN values for `eduPersonEntitlement` are created, these shall be registered within a [register that is administered by Feide](https://www.feide.no/urn). Requests for issuing namespace is sent to email: [support@feide.no](mailto:support@feide.no) For lower education, information about a person’s årstrinn, studieprogram, program area and class shall be registered within the attribute `eduPersonEntitlement`, using codes from utdanningsdirektoratets [Grep framework](http://grepwiki.udir.no/index.php?title=Kom_i_gang"Grep-rammeverket"). årstrinn, studieprogram and program area are mandatory, meaning that the attribute shall be present and shall have content. Students in lower education are not affiliated with a studieprogram and program area, and shall not have these filled out. Grep codes shall be prefixed with the string “[urn:mace:feide.no:go:grep](urn:mace:feide.no:go:grep):”. The person’s information regarding årstrinn, studieprogram and program area is not connected to every school, but the sum of the person’s values with all the schools they are affiliated with. See [Registration of Grep codes in eduPersonEntitlement](go_attributter_chA2.html.md) for detailed information. Information regarding person’s affiliations to groups shall be registered in the attribute `eduPersonEntitlement`. Student and teacher affiliations to basis-groups/classes and teaching groups are mandatory, and must be filled out. Affiliations to other types of groups can be filled out. Group information shall be prefixed with the string “[urn:mace:feide.no:go:group](urn:mace:feide.no:go:group):”. The person’s information about groups is constructed in such a way that it is connected to each school the person belongs to. See [Registration of group information in eduPersonEntitlement](go_attributter_chA3.html.md) for detailed information. Information about person’s group-IDs shall be registered in the attribute `eduPersonEntitlement`. It is mandatory to fill out the group identifiers to groups that the person belongs to as described in the section above. group-IDs shall be prefixed with the string “[urn:mace:feide.no:go:groupid](urn:mace:feide.no:go:groupid):” and have strict demands for how it is constructed. See [Registration of group-IDs in eduPersonEntitlement](go_attributter_chA4.html.md). for detailed information. ### norEduPersonAuthnMethod
Attribute Name norEduPersonAuthnMethod (Only mandatory when used with strong authentication)
Short description List of methods for strong authentication which are available for the person.
Example norEduPersonAuthnMethod:
urn:mace:feide.no:auth:method:sms +4712345678 label=Work%20phone

and/or

norEduPersonAuthnMethod:
urn:mace:feide.no:auth:method:ga eyEUJfe...WERIW
Multivalued Yes
This attribute is mandatory for persons logging into services with strong authentication. Valid values are constructed in this manner: ` ` Identifier for SMS: `urn:mace:feide.no:auth:method:sms` Identifier for Approver/Authenticator: `urn:mace:feide.no:auth:method:ga` Method for authentication can be marked with an optional note to show a user friendly text, and provide separation for the different methods. The marking `label=` shall only be present when there is a note, and it shall not be empty. Examples: When using one time password for sms: - `norEduPersonAuthnMethod: urn:mace:feide.no:auth:method:sms +4712345678 label=Work%20phone` When using the method one time password on sms, without note: - `norEduPersonAuthnMethod: urn:mace:feide.no:auth:method:sms +4712345678` When using the method Approver/Authenticator: - `urn:mace:feide.no:auth:method:ga eyEUJfe...WERIW label=Authenticator%20(Feide)` ### norEduPersonServiceAuthnLevel
Attribute Name norEduPersonServiceAuthnLevel (Can be used with strong authentication, and is not mandatory)
Short description Specifies which services that requires strong authentication
Example norEduPersonServiceAuthnLevel:
urn:mace:feide.no:spid:12345 urn:mace:feide.no:auth:level:fad08:3

and/or

norEduPersonServiceAuthnLevel:
urn:mace:feide.no:spid:all urn:mace:feide.no:auth:level:fad08:3
Multivalued Yes
This attribute provides the possibility to list which services a single person can utilize strong authentication for. This can for instance be useful for persons that have extended rights to one or more services. Valid values are: - `urn:mace:feide.no:spid: `: Is set for a single service that the person will log in to using strong authentication. The Feide-id for a service can be found below the service logo on the page of the service in the customer portal. - `urn:mace:feide.no:spid:all `: Is set if the person shall log in to all services using strong authentication. For strong authentication through Feide, the uri for authentication level is: `urn:mace:feide.no:auth:level:fad08:3` ## Recommended - person ### mail
Attribute Name mail
Short description The person's email. Shall be a personal address.
Example mail: ola.nordmann@elev.skotthyll.kommune.no

and/or

mail: arnt1990@gmail.com
Multivalued Yes
`mail` Shall be a personal email that the user alone has access to. Some services treats `eduPersonPrincipalName` as an email. They are not supposed to, but some use the value to send the user invitations to resources, messages from other users and more. If the user’s email is different from the value in `eduPersonPrincipalName`, the host organization should consider if they will place this value as an email alias for the user in the email system. Depending on how visible the organization want this alias to be, it can also be added as a value to the `mail` attribute in Feide. ### mobile
Attribute Name mobile
Short description Mobile number connected to this person.
Example mobile: +47 40404040
Multivalued Yes
`mobile` shall be a personal mobile number that the user alone uses. ### preferredLanguage
Attribute Name preferredLanguage
Short description The person's preferred language, defined by ISO 639-3 og BCP 47.
Example preferredLanguage: nn
or
preferredLanguage: nb
Multivalued No
### schacHomeOrganization
Attribute Name schacHomeOrganization
Short description Realm to the organization that the person affiliates to.
Example schacHomeOrganization: skotthyll.kommune.no
Multivalued No
### eduPersonPrimaryAffiliation
Attribute Name eduPersonPrimaryAffiliation
Short description Primary role at the school-owner.
Example eduPersonPrimaryAffiliation: student

or

eduPersonPrimaryAffiliation: employee
Multivalued No
`eduPersonPrimaryAffiliation` Defines the person’s primary role at the organization. For instance this can be valuable if a person acts as both student and employee at the organization. For valid values, see more information on page 10 (`eduPersonAffiliation`). It should be noted that all values within Figure 2 can be used, but the value used must also be set within `eduPersonAffiliation`. ### eduPersonScopedAffiliation
Attribute Name eduPersonScopedAffiliation
Short description Person's role and institution.
Example eduPersonScopedAffiliation: employee@NO179530458.skotthyll.kommune.no

og

eduPersonScopedAffiliation: employee@skotthyll.kommune.no
Multivalued Yes
For persons affiliated to a school, `eduPersonScopedAffiliation` defines the person’s role at the school, and which school this applies to. Construction for `eduPersonScopedAffiliation` is: `@.` and `@` Role must be one of the values in `eduPersonAffiliation`, and realm represents the right side(after @) in `eduPersonPrincipalName` # Organization ## Mandatory - organization ### eduOrgLegalName
Attribute Name eduOrgLegalName
Short description The official name of the organization.
Example eduOrgLegalName: Skotthyll kommune

and/or

eduOrgLegalName: Skotthyll gielda
Multivalued Yes
### o
Attribute Name o
Short description Organization's name.
Example o: Skotthyll kommune

and/or

o: Skotthyll gielda
Multivalued Yes
### norEduOrgNIN
Attribute Name norEduOrgNIN
Short description Organization's number from Brønnøysundregistrene
Example norEduOrgNIN: NO179530459
Multivalued No
Note that norEduOrgNIN shall be the organization number from Brønnøysundregisteret which is the registered school-owner in [National school register](https://nsr.udir.no). It shall be comprised of nine digits that are prefixed with NO, and it shall not contain hyphens or spaces. ### mail
Attribute Name mail
Short description Email to organization.
Example mail: info@skotthyll.kommune.no
Multivalued Yes
### norEduOrgSchemaVersion
Attribute Name norEduOrgSchemaVersion
Short description Which version of norEdu\* object Class specification the organization is using.
Example norEduOrgSchemaVersion: 2.0
Multivalued No
## Recommended - organization ### telephoneNumber
Attribute Name telephoneNumber
Short description Telephone number to the organization.
Example telephoneNumber: +47 73557900
Multivalued Yes
### postalAddress
Attribute Name postalAddress
Short description The postal address of the organization.
Example postalAddress: Postboks 340$7640 Skotthyll

and/or

postalAddress: Kongens gate 12$7640 Skotthyll
Multivalued Yes
Note that line breaks within postal addresses are typically a $-sign (See example above). This is typically handled by the system that imports the data to the catalogue. # Organizational unit Every school affiliated to the school owner is originally its own organization unit. ## Mandatory - organizational unit ### ou
Attribute name ou
Short description The official name of the school.
Example ou: Hylla skole

and/or

ou: Hylla
Multivalued Yes
### norEduOrgUnitUniqueIdentifier
Attribute name norEduOrgUnitUniqueIdentifier
Short description A unique identifier for the school. Either an organization number or underlying business number from Brønnøysundregistrene
Example norEduOrgUnitUniqueIdentifier:NO179530458
Multivalued No
`norEduOrgUnitUniqueIdentifier` shall contain the school’s organization number or underlying business number from Brønnøysundregistrene registered in [National school register](https://nsr.udir.no). It shall be comprised of nine digits that are prefixed with `NO`, and it shall not contain hyphens or spaces. If the school owner and school is the same organization the `norEduOrgUnitUniqueIdentifier` shall equal the `norEduOrgNIN`. ### mail
Attribute name mail
Short description Email to the organizational unit
Example mail: hylla@skotthyll.kommune.no

and/or

mail: post@hylla.skotthyll.kommune.no
Multivalued Yes
## Recommended - organizational unit ### telephoneNumber
Attribute name telephoneNumber
Short description Phone-number to the school.
Example telephoneNumber: +47 73557900
Multivalued Yes
### postalAddress
Attribute name postalAddress
Short description Postal address to the school.
Example postalAddress: Postboks 340$7640 Skotthyll

and/or

postalAddress: Nordveien 5$7640 Skotthyll
Multivalued Yes
Note that line breaks within postal addresses are typically a $-sign (see example above). This is typically handled by the system importing the data to the catalogue. # Optional attributes - person and organization Here is an overview of attributes from norEdu\*-specification that is not mandatory or recommended in Feide. For more information about each attribute, see [«norEdu\* Object Class Specification»](../noredu/index.html.md). It is up to each organization to take into consideration if this information shall be added to the Feide catalogue, but it is advantageous to add what information one have available. ## norEduOrgAcronym
Attribute name norEduOrgAcronym
Short description Acronym for organization or organizational unit.
Example norEduOrgAcronym: USIT
Multivalued Yes
## norEduPersonBirthDate
Attribute name norEduPersonBirthDate
Short description Person's birthdate
Example norEduPersonBirthDate: 280889
Multivalued No
## norEduPersonLIN
Attribute name norEduPersonLIN
Short description Local ID-number, for example student-, employee number, local replacement for national identity number.
Example norEduPersonLIN: uninett.no:employee:035016
norEduPersonLIN: feide.trondelagfylke.no:fin:51030299250
Multivalued Yes
A few persons does not have any national ID-numbers and thus have no value in `norEduPersonNIN`. norEduPersonLin can be used to exchange locally issued ID-numbers that services can use. These ID-numbers are **not** unique within Feide, just within the organization. Some of these are coordinated within the specific educational segment so they can be used across the organizations. **County municipality ID-numbers** ID-number issued by the county municipalities described in [fellesrutinene](http://regbok.udir.no/35004/3344/35042-1014306.html) can be expressed as: `norEduPersonLIN: :fin:` ex: `norEduPersonLIN: feide.trondelagfylke.no:fin:51030299250` **False national identity numbers** ID-number constructed as national identity number, TF-number and similar, but issued locally where no national coordination is available can be expressed as: `norEduPersonLIN: :localnin:` ex: `norEduPersonLIN: hamar.kommune.no:localnin:21030212345` `norEduPersonLIN: selbu.kommune.no:localnin:210302545TF` ## eduOrgIdentityAuthNPolicyURI
Attribute name eduOrgIdentityAuthNPolicyURI
Short description URI that points to the organization's policy for handling identities
Example eduOrgIdentityAuthNPolicyURI: https://www.universitetet.no/security/IApolicy.html
Multivalued Yes
## eduOrgHomePageURI
Attribute name eduOrgHomePageURI
Short description URL to the organization's toplevel website.
Example eduOrgHomePageURI: https://www.universitetet.no
Multivalued Yes
## eduOrgWhitePagesURI
Attribute name eduOrgWhitePagesURI
Short description URL to the organization's open catalogue service.
Example eduOrgWhitePagesURI: ldap://wpage.universitetet.no
Multivalued Yes
## eduPersonAssurance
Attribute name eduPersonAssurance
Short description URI providing information for which trust levels for identity handling and authentication the organization supports.
Example eduPersonAssurance: urn:mace:incommon:IAQ:sample
Multivalued Yes
## eduPersonNickname
Attribute name eduPersonNickname
Short description The name the person is referred to on a daily basis.
Example eduPersonNickname: Ola
Multivalued Yes
## eduPersonPrincipalNamePrior
Attribute name eduPersonPrincipalNamePrior
Short description Former eduPersonPrincipalName at the same legal organization.
Example eduPersonPrincipalNamePrior: olno@skotthyll.kommune.no
eduPersonPrincipalNamePrior: olenor@varpa.kommune.no
Multivalued Yes
All values within the attribute must have been owned by the same legal organization as the current `eduPersonPrincipalName`. In practise the values must have Feide-names with: * organization’s present realm * organization’s former used realm if this has been changed * realm from merged organizations Feide-name used at other organizations is not allowed due to security concerns. It is the responsibility of the host organization to make sure that the fields value used does not enable persons at the organization to impersonate someone else at the organization or other organizations. The attribute shall **not** contain the person’s current `eduPersonPrincipalName`. The attribute might be used as a signal to services that this person has had another `eduPersonPrincipalName` in the past. This can be used for internal logic, for instance connecting accounts within the service and similar. ## eduPersonOrcid
Attribute name eduPersonOrcid
Short description ORCID ids are identifiers for scientists and connects them to their publications.
Example eduPersonOrcid: https://orcid.org/0000-0002-1825-0097
Multivalued Yes
## facsimileTelephoneNumber
Attribute name facsimileTelephoneNumber
Short description Fax number.
Example facsimileTelephoneNumber: +47 73557901
Multivalued Yes
## homePhone
Attribute name homePhone
Short description Person's home number.
Example homePhone: +47 23456789
Multivalued Yes
## homePostalAddress
Attribute name homePostalAddress
Short description Postal address for the person's home.
Example homePostalAddress: Jordbærgata 14c$0234 Ski
Multivalued Yes
## jpegPhoto
Attribute name jpegPhoto
Short description A picture of the person in jpeg-format (up to 250\*250 px, approximately 30kB)
Example (attribute value is in binary format)
Multivalued Yes
## l (localityName)
Attribute name l (localityName)
Short description Name for location. Example could be city or county.
Example l: Oslo
Multivalued Yes
## labeledURI
Attribute name labeledURI
Short description A URI with description (label).
Example labeledURI: https://www.universitetet.no/itregl.html IT-rules
Multivalued Yes
## manager
Attribute name manager
Short description LDAP-pointer to person's manager.
Example manager:uid=ojohnsen,ou=people,dc=universitetet,dc=no
Multivalued Yes
## postalCode
Attribute name postalCode
Short description Postal number for the organization.
Example postalCode: NO-7465
Multivalued Yes
## postOfficeBox
Attribute name postOfficeBox
Short description Mailbox.
Example postOfficeBox: 109260
Multivalued Yes
## street
Attribute name street
Short description Street address.
Example street: Universitetsgata 3
Multivalued Yes
## title
Attribute name title
Short description Person's title.
Example title: Section manager for language studies
Multivalued Yes
## userCertificate
Attribute name userCertificate
Short description Person's X.509-certificate.
Example (attribute value is in binary-format)
Multivalued Yes
## userSMIMECertificate
Attribute name userSMIMECertificate
Short description A X.509-certificate meant for use in S/MIMEapplications, for example signing and encryption of email.
Example (attribute value is in binary-format)
Multivalued Yes
# Changelog ## From version 2012-02 to version 2013-10 - `norEduPersonNIN` is changed from “mandatory” to “mandatory if a valid value exists”. Guidelines for what types of numbers that can be added to `norEduPersonNIN` have been changed. - `eduPersonPrimaryAffiliation` is changed from mandatory to recommended. - Information about organizational unit is now only mandatory for persons affiliated with a school. - Two new attributes have been recommended: - `eduPersonScopedAffiliation` - `schacHomeOrganization` - Clarifying that `uid` shall equal the first part of `eduPersonPrincipalName` (before “@”) - Information about `eduPersonPrincipalName` and which realm that can be used has been changed. - Document is now referring to norEdu\*-specification version 1.5.1. - New chapter with more information about mandatory, recommended and optional attributes added (ch. 1.2). - Figure 1 has been updated, generalizing which attributes are mandatory, recommended and optional. - The language used throughout the document has updated phrasings, making it more suitable for private school owners. - New chapter with overview of optional attributes added to (ch. 5). - Changelog added to (ch. 6) ## From version 2014-01 to 2015-09 - It is not mandatory to register information about students and teachers affiliation to basis-groups/classes and teaching groups within `eduPersonEntitlement` - A new attribute is mandatory for persons that will use strong authentication: - `norEduPersonAuthnMethod` - A new attribute can be used to list which services a single person has to use strong authentication for (this is not mandatory): - `norEduPersonServiceAuthnLevel` - It is specified that private students shall have the value “affiliate” in the attribute `eduPersonAffiliation` to clarify the connection to the organization. ## From version 2015-09 to 2018-03 - The document now refers to norEdu\*-specification version 2.0. - It is not mandatory to register group-IDs in `eduPersonEntitlement`. These reflect the affiliation to basis-groups, teaching groups and other groups introduced in 1.6. - Updated tables and examples with group-IDs. - Updated optional attributes to be equal to UH. `l` (`localityName`) and `labeledURI` have been added. - Added optional attributes `eduPersonPrincipalNamePrior` and `eduPersonOrcid`. - Updated references that was previously pointing to RFC 2141 to the newer RFC 8141. - Clarifying that users without NIN can in fact have a Feide user. - Clarifying that group information that has been registered is the current and not historical groups. - Clarify the usage of notes on authentication methods. - Clarify that Grep-codes are only mandatory for students with teachings covered by the code definition. - Clarify that teaching groups must have Grep-codes, and that other groups can be used for groups without Grep-codes. - Clarify that information about educational year, educational area and program area is the sum of values that the person has with the school owner, while groups and group-IDs are connected to the school(s). - Clarify how `norEduPersonLin` can be used for county municipal ID-numbers and other local fictional national identity numbers. - Added section about data-processing contracts between host organizations and services. - Added section about services that incorrectly uses `eduPersonPrincipalName` as email under the `mail` attribute. - Reformatted from PDF to web-document - New appendix 4 added with descriptions of group-IDs. - Changed previously used “group identifiers” to “local group-ID” and added “group-ID” for Feide group-IDs. - Reformatted wide tables (collection) into one table per attribute. - Corrected error in example for `norEduPersonAuthnMethod`. Approval secret was shown unencrypted when it should be encrypted. Unencrypted values here have always been rejected by Feide. - Corrected error in examples for organizations and organizational units. These have the same organization number. - Corrected error in example for `eduPersonScopedAffiliation`. Added necessary variants. # Appendix 1 - LDIF-example Example on filled out LDAP-objects that satisfies Feide demands. ## Person ```default dn: uid=olanor123,cn=people,dc=Skotthyll,dc=kommune,dc=no objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top objectClass: eduPerson objectClass: schac objectClass: norEduPerson cn: Arnt Ola Nordmann cn: olanor123 displayName: Ola Nordmann eduPersonAffiliation: member eduPersonAffiliation: student eduPersonPrimaryAffiliation: student eduPersonOrgDN: dc=Skotthyll,dc=kommune,dc=no eduPersonOrgUnitDN: ou=Hylla skole,cn=organization,dc=Skotthyll,dc=kommune,dc=no eduPersonPrimaryOrgUnitDN: ou=Hylla skole,cn=organization,dc=Skotthyll,dc=kommune,dc=no eduPersonPrincipalName: olanor123@skotthyll.kommune.no eduPersonPrincipalNamePrior: olenor@varpa.kommune.no eduPersonScopedAffiliation: student@skotthyll.kommune.no eduPersonScopedAffiliation: member@skotthyll.kommune.no eduPersonScopedAffiliation: student@NO179530458.skotthyll.kommune.no eduPersonScopedAffiliation: member@NO179530458.skotthyll.kommune.no givenName: Ola norEduPersonLegalName: Arnt Ola Olsen Nordmann norEduPersonNIN: 28088933134 norEduPersonAuthnMethod: urn:mace:feide.no:auth:method:sms +4740404040 label=Work%20phone schacHomeOrganization: skotthyll.kommune.no sn: Nordmann sn: Olsen Nordmann uid: olanor123 userPassword: {CRYPT}$6$ufxrIZTs$hl3ocEOAb01o3HC1yk1DUTD6aaHnH7xD5ZDFCH9xnoNUWZky6lt0/ eduPersonEntitlement: urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn6 eduPersonEntitlement: urn:mace:feide.no:go:group:b::NO179530458:6A:2014-08-01:2015-06-15:student:Klasse%206A eduPersonEntitlement: urn:mace:feide.no:go:group:u:NOR0006:NO179530458:6A%2FNor:2014-08-01:2015-06-15:student:Norsk%206A eduPersonEntitlement: urn:mace:feide.no:go:group:u:NAT0006:NO179530458:6A%2FNat:2014-08-01:2015-06-15:student:Naturfag%206A eduPersonEntitlement: urn:mace:feide.no:go:group:a::NO179530458:6A%2FNat%2Flb3:2014-08-01:2014-12-31:student:Labgruppe%203%20Naturfag%206A eduPersonEntitlement: urn:mace:feide.no:go:groupid:b:NO179530458:6a:2014-08-01:2015-06-15 eduPersonEntitlement: urn:mace:feide.no:go:groupid:u:NO179530458:6a%2Fnor:2014-08-01:2015-06-15 eduPersonEntitlement: urn:mace:feide.no:go:groupid:u:NO179530458:6a%2Fnat:2014-08-01:2015-06-15 eduPersonEntitlement: urn:mace:feide.no:go:groupid:a:NO179530458:6a%2Fnat%2Flb3:2014-08-01:2014-12-31 mail: ola.nordmann@elev.skotthyll.kommune.no mobile: +47 40404040 preferredLanguage: nb ``` ## Organization (School owner) ```default dn: dc=Skotthyll,dc=kommune,dc=no objectClass: eduOrg objectClass: norEduOrg objectClass: organization objectClass: top dc: Skotthyll kommune eduOrgLegalName: Skotthyll kommune norEduOrgNIN: NO179530459 norEduOrgSchemaVersion: 2.0 o: Skotthyll kommune mail: info@skotthyll.kommune.no telephoneNumber: +47 73557900 postalAddress: Postboks 340$NO-7640 Skotthyll ``` ## Organizational unit (School) ```default dn: ou=Hylla skole,cn=organization,dc=Skotthyll,dc=kommune,dc=no objectClass: norEduOrgUnit objectClass: organizationalUnit objectClass: top norEduOrgUnitUniqueIdentifier: NO179530458 ou: Hylla skole mail: hylla@skotthyll.kommune.no telephoneNumber: +47 73557900 postalAddress: Postboks 340$NO-7640 Skotthyll postalAddress: Nordveien 5$NO-7640 Skotthyll ``` # Appendix 2 - Registration of Grep-codes within eduPersonEntitlement ## Terminology Årstrinn : Students grouped in what year of the education they are attending. Example is after kindergarten the persons starts in årstrinn 1. Then proceeds to årstrinn 2 the next year. Services are facing an increasing demand for information about users educational year, subject and more. On this basis the GREP-codes shall be registered for users in lower education. In Feide the field `eduPersonEntitlement` will be used for GREP-codes. The person’s Grep-values are not connected to each school, but is the sum of the person’s values at all the schools he/she is affiliated with. See information from Utdanningsdirektoratet for more about [Grep-codes](http://grepwiki.udir.no/index.php?title=Om_Grep). ## Teachers It is not mandatory to register Grep-codes for teachers and other employees, only for students attending education covered by grep code collection. Teachers can register Grep-codes for courses they teach in and also groupings(semester, educational programs, program areas and fields) they are responsible for. Other employees shall not have Grep-codes registered. ## Students in 1.-10.grade For students in lower education (1.-10. grade), only grade will be registered. This table show which values grade shall have registered for lower education:
Grade Grep-code
1. grade urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn1
2. grade urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn2
3. grade urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn3
4. grade urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn4
5. grade urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn5
6. grade urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn6
7. grade urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn7
8. grade urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn8
9. grade urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn9
10. grade urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn10
## Students in videregående For students in videregående the following shall be registered - årstrinn - educational program - program area This table shows which values grade shall have in videregående:
årstrinn Grep-code
1. årstrinn urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/vg1
2. årstrinn urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/vg2
3. årstrinn urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/vg3
For educational programs and program areas, the number of Grep-codes are both numerous and dynamic, and it will be out of scope to list everything within tables. We recommend therefore that these Grep-codes are retrieved from the school-administrative systems and prefixed with `urn:mace:feide.no:go:grep:`. ## Grep-codes registered in school-administrative systems Multiple school-administrative systems have Grep code collection implemented within their solutions. At the same time, these systems also contains other codes that provides information about grade, field and more. Bee advised that the Grep-codes that are registered within the Feide catalogue have to be the unique identifier of the grade, educational program, program area or the field itself. Below are some examples that shows the difference between Grep-codes and other codes. Example of grade: - “8. årstrinn” is a name (short form) and shall not be used as an identifier within Feide. - `http://psi.udir.no/laereplan/aarstrinn/aarstrinn8` is the grade’s identification and shall be used within Feide. Example of educational program: - “ST” is the code to course-specialization, but this is not the identifier. - `http://psi.udir.no/ontologi/utdanningsprogram/studiespesialisering` is the program’s identifier and shall be used within Feide. Example of program area: - “STREA2—-” is the area’s code. - `uuid:81d3b889-16c8-4b0a-81af-d0832fbcb219` is the area’s identifier in the code collection and shall be used within Feide. Example of field: - “REA3005” is the code to the field Fysikk 2. - `uuid:7a0fa1f7-f6f9-4a5e-93a4-78f59ad57166` is the field’s identifier in the code collection and shall be used within Feide. # Appendix 3 - Registration of group information within eduPersonEntitlement Services are facing an increasing demand for information about users basis-groups/classes, teaching groups and other groups. Based on this, students and teachers group information shall be registered. In Feide `eduPersonEntitlement` is the chosen field for group information. The person’s information about groups is constructed in such a way that it is connected to each school the person is affiliated to. ## Everyone that is connected to the group shall have the information registered All persons connected to a group shall have the information registered on their person object. This will usually be students and teachers, but might also be other persons that have a format connection to the day to day work performed within the group. Group information shall contain the groups a person affiliates to. It is not expected that information about historical groups is kept. ## Group types It is defined three group types which can be expressed as: - Basis-group/class - Teaching group - for course/fields within the Grep code collection - Other groups - project groups, teaching groups outside Grep and more. Basis-group/class and teaching groups are mandatory to register for a person affiliated to some of these, while other groupings may be registered. ## Information elements about group and the person’s relation to the group Each group affiliation that is registered for a person contains 8 information elements:
Information element Description
Group type Shows which type of group this is. Valid values are 'b', 'u' and 'a' for respectively basis-groups/class, teaching group and other group.
Grep-code For teaching groups, it will be the code to the field that the teaching group belongs to in the Grep code collection. For basis-groups and other groups it shall be an empty value
Organization number/
business number		 Organization number/business number to the school/school-owner the group belongs to. For most groups it will be connected to the school, but there might be groups that are directly connected to the school-owner
Local group-ID An identifier of the group where name standards are defined by school/school-owner. Shall be unique within the group that the school/school-owner belongs to.
Start time The first day the group is active/valid. ISO 8601 extended format for date, YYYY-MM-DD.
End time The last day the group is active/valid. ISO 8601 extended format for date, YYYY-MM-DD.
Role The person's role within the group. Valid values are the same as for eduPersonAffiliation. A person shall only inhibit one entry for role within the group, for instance faculty, and not the whole hierarchy as seen in eduPersonAffiliation.
Description
group name		 The group's human readable name that will be presented in the services.
Grep codes, roles and descriptive name are registered for group affiliation, but not for [group identifiers](go_attributter_chA4.html.md). These three fields can change, even though identifying the same group. ## Formatting of group information Each group affiliations are registered as its own line within `eduPersonEntitlement`. The line shall start with the prefix `urn:mace:feide.no:go:group:` followed by each information element in the same order as in the table above. Each information element is separated from each other with a colon, `:`. To be able to transfer values from one system to another, [RFC 8141](https://datatracker.ietf.org/doc/html/rfc8141) and [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986) defines which values that are valid, which values are used directly and which ones that have to be percent-encoded. URNs are limited to ASCII so most special characters and norwegian characters must be percent-encoded in the transfer. One will use UTF-8 translation first and then used US-ASCII ([RFC 8141](https://datatracker.ietf.org/doc/html/rfc8141) 2. Syntax). This is performed by translating these characters to %. For instance the norwegian character ‘å’ will be translated from UTF-8 into two octets, which will then be encoded and become %C3%A5. is a special case. Many functions for percent-coding codes this into + which deviates with [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986). The correct case for URNs are %20. Host organizations should make sure that this is correct, while service providers should take into account both formatting’s of . For group information, `:` will be used as separator between information elements. If this character is used inside information elements, for instance in the descriptive name or the local group-ID, this has to be encoded as %3A. ## Case-sensitivity Information elements for group information shall be treated case-insensitive, see [RFC 8141](https://datatracker.ietf.org/doc/html/rfc8141) opening for functional comparison of the values ## Examples for group information in eduPersonEntitlement ### Student in basis-group/class 6A at Berg school (Trondheim kommune) ```default Group type: b Grep-code: Organization number: NO975278964 Local group-ID: 6A Role: Student – ’student’ in Feide. Start time: 1. aug 2014 End time: 15. jun 2015 Descriptive name: Klasse 6A eduPersonEntitlement: urn:mace:feide.no:go:group:b::NO975278964:6A:2014-08-01:2015-06-15:student:Klasse%206A ``` ### Teacher in teaching group 2kja at Tiller VGS ```default Group type: u Grep-code: REA3012 Organization number: NO974558386 Local group-ID: 2kja – Lower case is used in this example, but the value is case-insensitive. Role: Teacher – ’faculty’ in Feide Start time: 1. aug 2014 End time: 15. jun 2015 Descriptive name: Kjemi 2A eduPersonEntitlement: urn:mace:feide.no:go:group:u:REA3012:NO974558386:3kja:2014-08-01:2015-06-15:faculty:Kjemi%202A ``` ### Student in teaching group Norsk VG3 at Tiller VGS ```default Group type: u Grep-code: NOR1211 Organization number: NO974558386 Local group-ID: 3aaa/3nh Role: Student Start time: 1. aug 2014 End time: 15. jun 2015 Descriptive name: Norsk hovedmål VG3 eduPersonEntitlement: urn:mace:feide.no:go:group:u:NOR1211:NO974558386:3aaa%2F3nh:2014-08-01:2015-06-15:student:Norsk%20hovedm%C3%A5l%20VG3 ``` ### Student in lab-group 3 Fysikk VG3 at Tiller VGS ```default Group type: a – andre grupper Grep-code: Organization number: NO974558386 Local group-ID: 3fysa/lb3 Role: Student Start time: 1. aug 2014 End time: 31. des 2014 Descriptive name: Labgruppe 3 Fysikk VG3 eduPersonEntitlement: urn:mace:feide.no:go:group:a::NO974558386:3fysa%2Flb3:2014-08-01:2014-12-31:student:Labgruppe%203%20Fysikk%20VG3 ``` # Appendix 4 - Registration of group-IDs in eduPersonEntitlement To be able to retrieve all members within a group, group-IDs have to be registered on person objects to all that are members of the group. In Feide, the field `eduPersonEntitlement` is chosen for group-IDs. Group-IDs are quite similar when compared to the groups a person is member of, but they will be equal for all members regardless of the role within the group. They have a much higher demand to design which makes it possible to use them as unique identifiers. The person’s information about group-IDs is constructed in such a manner that it will be connected to each school the person is affiliated to. ## Everyone affiliated with the group shall have the identifier registered All person’s affiliated with a group shall the the equivalent group-ID registered on their person object. This will in most cases be students and teachers, but can also be other persons with a formal connection to the daily work within the group. Group identifiers shall contain the groups a person is currently affiliated to. It is not expected that information regarding historical group-IDs is kept. ## Relation to group information There should be a direct correlation between the list of groups registered on a person and the list of group-IDs. A person object shall not have registered a group without a correlating group-ID, and similarly should not have any group-ID without a correlating group. ## Construction of group-IDs Group-ids in Feide are global in scope and unique over time. They will therefore contain more information than what is normally necessary for internal use at a school-owner. Each group-ID which is registered for a person contains 5 information elements:
Information element Description
Group type Shows which type of group this is. Valid values are 'b', 'u' and 'a' for respectively basis-group, teaching group and other group.
Organization number/
business number		 Organization number/business number to the school/school-owner the group belongs to. For most groups, this will be connected to the school, but there might be groups connected directly to the school-owner.
Local group-ID An identifier of the group where name standards are defined by the school/school-owner. Shall be unique within the school/school-owner the group belongs to.
Start time The first day the group is active/valid. ISO 8601 extended format for date, YYYY-MM-DD.
End time The last day the group is active/valid. ISO 8601 extended format for date, YYYY-MM-DD.
## Formatting of group-IDs Each group identifier is registered as a new line within `eduPersonEntitlement`. The format for the identifiers is stricter than group affiliation described in [Appendix 3](go_attributter_chA3.html.md) for uniquely identification of groups. The line shall start with the prefix ’[urn:mace:feide.no:go:groupid](urn:mace:feide.no:go:groupid):’ followed by each of the information elements in the same order as the table above. The information elements uses ‘:’ as separator. To be able to transfer values from one system to another, [RFC 8141](https://datatracker.ietf.org/doc/html/rfc8141) and [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986) defines which values are valid, which values that are used directly and which values have to be percent-encoded. URNs are limited to ASCII so the main part of special characters and norwegian characters have to be percent-encoded in the transfer. First it will be translated to UTF-8, then over to US-ASCII ([RFC 8141](https://datatracker.ietf.org/doc/html/rfc8141) 2. Syntax). This is performed by translating these characters to %. The hexadecimal letters A-F **\*shall\*** be written in capital letters. For instance the norwegian character ‘å’ will be translated from UTF-8 into two octets that will then be encoded and become %C3%A5. All characters which are “unreserved” in 2.3 within [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986) shall be written directly, while all other characters shall be percent-encoded. The characters that will be written directly are: - a-zA-Z (ALPHA) - 0-9 (DIGIT) - - (minus) - . (period) - \_ (underline) - ~ (tilde) /space is a special case which has to be thoroughly controlled. Quite a few functions for percent-encoding codes this into a + which deviates from [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986). The correct value for URNs are %20. Host organizations have to verify that this is correct. For group-IDs `;` is used as separator between information elements. If this character is used inside the information elements, for instance in the local group-ID, this has to be encoded as %3A. Information elements in the group-ID have different demands for the use of uppercase and lowercase letters: - Group type: Shall only contain one lowercase letter. Example: `b` - Organization number/business number: Shall only contain uppercase letters and numbers. Example: `NO975278964` - Local group-ID: Shall be written in lowercase letters before percent-encoding. All hexadecimal letters within percent-encoded values shall be uppercase, A-F. Example: `6a-kr%C3%B8` (6a-krø) - Start time: Shall only contain numbers and -. Example: `2014-08-01` - End time: Shall only contain numbers and -. Example: `2015-06-15` ## Examples with group-IDs in eduPersonEntitlement These examples correlate with examples for group information in [Appendix 3](go_attributter_chA3.html.md). ### Student in basis-group/class 6A at Berg skole (Trondheim kommune) ```default Group type: b Organization number: NO975278964 Local group-ID: 6A Start time: 1. aug 2014 End time: 15. juni 2015 eduPersonEntitlement: urn:mace:feide.no:go:groupid:b:NO975278964:6a:2014-08-01:2015-06-15 ``` ### Teacher in teaching group 2kja at Tiller vgs ```default Group type: u Organization number: NO974558386 Local group-ID: 2kja Start time: 1. aug 2014 End time: 15. juni 2015 eduPersonEntitlement: urn:mace:feide.no:go:groupid:u:NO974558386:3kja:2014-08-01:2015-06-15 ``` ### Student in teaching group Norsk VG3 at Tiller vgs ```default Group type: u Organization number: NO974558386 Local group-ID: 3aaa/3nh Start time: 1. aug 2014 End time: 15. juni 2015 eduPersonEntitlement: urn:mace:feide.no:go:groupid:u:NO974558386:3aaa%2F3nh:2014-08-01:2015-06-15 ``` ### Student in lab-group 3 Fysikk VG3 at Tiller vgs ```default Group type: a Organization number: NO974558386 Gruppe-ID: 3fysa/lb3 Start time: 1. aug 2014 End time: 31. des 2014 eduPersonEntitlement: urn:mace:feide.no:go:groupid:a:NO974558386:3fysa%2Flb3:2014-08-01:2014-12-31 ``` # Feides information model for higher education **The usage of norEdu\* Object class Specification v.2.0 for higher education** **Attribute document**
Version Date Initials Comments
2018-03 Mars 2018 SL New version based on norEdu\*-specification version 2.0. See changelog for more details.
2015-09 September 2015 HV, JPC New version based on norEdu\*-specification. See changelog for more information.
* [Overview of the Feide LDAP structure](uh_attributter_ch01.html.md) * [Terminology](uh_attributter_ch01.html.md#terminology) * [Object classes](uh_attributter_ch01.html.md#object-classes) * [Attributes](uh_attributter_ch01.html.md#attributes) * [Person](uh_attributter_ch02.html.md) * [Mandatory - person](uh_attributter_ch02.html.md#mandatory-person) * [cn](uh_attributter_ch02.html.md#cn) * [displayName](uh_attributter_ch02.html.md#displayname) * [norEduPersonLegalName](uh_attributter_ch02.html.md#noredupersonlegalname) * [givenName](uh_attributter_ch02.html.md#givenname) * [sn](uh_attributter_ch02.html.md#sn) * [eduPersonPrincipalName](uh_attributter_ch02.html.md#edupersonprincipalname) * [uid](uh_attributter_ch02.html.md#uid) * [norEduPersonNIN](uh_attributter_ch02.html.md#noredupersonnin) * [mail](uh_attributter_ch02.html.md#mail) * [userPassword](uh_attributter_ch02.html.md#userpassword) * [eduPersonAffiliation](uh_attributter_ch02.html.md#edupersonaffiliation) * [eduPersonOrgDN](uh_attributter_ch02.html.md#edupersonorgdn) * [schacHomeOrganization](uh_attributter_ch02.html.md#schachomeorganization) * [norEduPersonAuthnMethod](uh_attributter_ch02.html.md#noredupersonauthnmethod) * [norEduPersonServiceAuthnLevel](uh_attributter_ch02.html.md#noredupersonserviceauthnlevel) * [Recommended - person](uh_attributter_ch02.html.md#recommended-person) * [eduPersonEntitlement](uh_attributter_ch02.html.md#edupersonentitlement) * [eduPersonOrgUnitDN](uh_attributter_ch02.html.md#edupersonorgunitdn) * [eduPersonPrimaryAffiliation](uh_attributter_ch02.html.md#edupersonprimaryaffiliation) * [eduPersonPrimaryOrgUnitDN](uh_attributter_ch02.html.md#edupersonprimaryorgunitdn) * [eduPersonScopedAffiliation](uh_attributter_ch02.html.md#edupersonscopedaffiliation) * [eduPersonOrcid](uh_attributter_ch02.html.md#edupersonorcid) * [mobile](uh_attributter_ch02.html.md#mobile) * [preferredLanguage](uh_attributter_ch02.html.md#preferredlanguage) * [Organization](uh_attributter_ch03.html.md) * [Mandatory - organization](uh_attributter_ch03.html.md#mandatory-organization) * [eduOrgLegalName](uh_attributter_ch03.html.md#eduorglegalname) * [norEduOrgNIN](uh_attributter_ch03.html.md#noreduorgnin) * [norEduOrgSchemaVersion](uh_attributter_ch03.html.md#noreduorgschemaversion) * [o](uh_attributter_ch03.html.md#o) * [mail](uh_attributter_ch03.html.md#mail) * [Recommended - organization](uh_attributter_ch03.html.md#recommended-organization) * [norEduOrgUniqueIdentifier](uh_attributter_ch03.html.md#noreduorguniqueidentifier) * [telephoneNumber](uh_attributter_ch03.html.md#telephonenumber) * [postalAddress](uh_attributter_ch03.html.md#postaladdress) * [Organizational unit](uh_attributter_ch04.html.md) * [Mandatory - organizational unit](uh_attributter_ch04.html.md#mandatory-organizational-unit) * [Recommended - organizational unit](uh_attributter_ch04.html.md#recommended-organizational-unit) * [mail](uh_attributter_ch04.html.md#mail) * [norEduOrgUnitUniqueIdentifier](uh_attributter_ch04.html.md#noreduorgunituniqueidentifier) * [ou](uh_attributter_ch04.html.md#ou) * [Optional attributes - person and organization](uh_attributter_ch05.html.md) * [norEduOrgAcronym](uh_attributter_ch05.html.md#noreduorgacronym) * [norEduPersonBirthDate](uh_attributter_ch05.html.md#noredupersonbirthdate) * [norEduPersonLIN](uh_attributter_ch05.html.md#noredupersonlin) * [eduOrgIdentityAuthNPolicyURI](uh_attributter_ch05.html.md#eduorgidentityauthnpolicyuri) * [eduOrgHomePageURI](uh_attributter_ch05.html.md#eduorghomepageuri) * [eduOrgWhitePagesURI](uh_attributter_ch05.html.md#eduorgwhitepagesuri) * [eduPersonAssurance](uh_attributter_ch05.html.md#edupersonassurance) * [eduPersonNickname](uh_attributter_ch05.html.md#edupersonnickname) * [eduPersonPrincipalNamePrior](uh_attributter_ch05.html.md#edupersonprincipalnameprior) * [facsimileTelephoneNumber](uh_attributter_ch05.html.md#facsimiletelephonenumber) * [homePhone](uh_attributter_ch05.html.md#homephone) * [homePostalAddress](uh_attributter_ch05.html.md#homepostaladdress) * [jpegPhoto](uh_attributter_ch05.html.md#jpegphoto) * [l (localityName)](uh_attributter_ch05.html.md#l-localityname) * [labeledURI](uh_attributter_ch05.html.md#labeleduri) * [manager](uh_attributter_ch05.html.md#manager) * [postalCode](uh_attributter_ch05.html.md#postalcode) * [postOfficeBox](uh_attributter_ch05.html.md#postofficebox) * [street](uh_attributter_ch05.html.md#street) * [title](uh_attributter_ch05.html.md#title) * [userCertificate](uh_attributter_ch05.html.md#usercertificate) * [userSMIMECertificate](uh_attributter_ch05.html.md#usersmimecertificate) * [Changelog](uh_attributter_ch06.html.md) * [From version 2012-02 to version 2013-10](uh_attributter_ch06.html.md#from-version-2012-02-to-version-2013-10) * [From version 2014-01 to 2015-06](uh_attributter_ch06.html.md#from-version-2014-01-to-2015-06) * [From version 2015-06 to 2018-03](uh_attributter_ch06.html.md#from-version-2015-06-to-2018-03) * [Appendix 1 - LDIF-example](uh_attributter_chA1.html.md) * [Person](uh_attributter_chA1.html.md#person) * [Organization](uh_attributter_chA1.html.md#organization) * [Organizational unit](uh_attributter_chA1.html.md#organizational-unit) # Overview of the Feide LDAP structure ## Terminology UH-sektoren : Sector covering higher education such as universities. ## Object classes The demands that Feide puts on the structure on data within the organization’s LDAP-catalogue are based on [«norEdu\* Object Class Specification»](../noredu/index.html.md). In addition to the specification, this document defines which attributes from norEdu\*-specification are mandatory or recommended for organizations within UH-sektoren. The LDAP-catalogues with the userdata located at each organization are organized into a tree-structure. In this structure lies nodes, which are a collection of attributes and affiliated values about: - persons - organizations - organizational units norEdu\*-specification defined three important object classes: - norEduPerson - norEduOrg - norEduOrgUnit Each object class defines a set of attributes. Multiple object classes used together can yield a greater set of attributes which comprises all information about a person, organization or organizational unit. One example for this is that a node with person-information will have attributes from the object classes `norEduPerson`, `schac`, `eduPerson` and `inetOrgPerson`. `inetOrgPerson` will use attributes from the object classes `person`, `organizationalPerson` and `top`. Read more about object classes in [«norEdu\* Object Class Specification»](../noredu/index.html.md). The two attributes (`eduPersonOrgDN` and `eduPersonOrgUnitDN`) explains which organization and possible organizational units a person is affiliated to. These contains a unique pointer to the nodes within the catalogue-tree that contains information about the organization and organizational units. ``eduPersonPrimaryOrgUnitDN` explains which organizational unit the person affiliates to. The unique notes for a person, organization and organizational units, and the interconnections between these are depicted in Figure 1 below. ## Attributes When a user logs into a service through Feide, the service receives message that the user is authenticated along with a selection of information elements which belongs to this user. The information elements that the service receives are limited through an agreement between Feide and the service. In Feide we use the term *attributes* about the different information elements. In general it is recommended to place as much information as possible into the Feide catalogue, and within norEdu\*-specification there are attributes for many different types of information elements. Quite a few services requests more and more types of information elements, and the organizations that puts large amounts of information into the Feide-catalogue will more effectively utilize the different services connected to Feide. In the customer portal the host organizations can view which attributes a service, at any given time, is exposed for. The host organizations have to make sure that a data processing agreement, which regulates the services usage of organizational data, exists between organizations and the service. To make it easier for the host organizations and the services, Feide has chosen to classify attributes into three categories: - **Mandatory** – Shall be placed within the Feide-catalogue - **Recommended** – Recommended to be placed within the Feide-catalogue - **Optional** – It is up to the organizations itself to evaluate if these should should be placed within the Feide-catalogue. Mandatory and recommended attributes are often those that the service expects to receive today. In spite of this classification, Feide strongly encourages host organizations to place as much information as possible within the Feide-catalogue. In this document you will find a brief overview of mandatory, recommended and optional attributes. ![Figure showing person, organization and organizational unit within the Feide catalogue](reference/schema/info_uh/uh_attributter_figur01.jpg) # Person ## Mandatory - person ### cn
Attribute name cn
Short description General node-name with person's information.
Example cn: Arnt Ola Nordmann

and/or

cn: olanor123
Multivalued Yes
### displayName
Attribute name displayName
Short description Person's preferred name.
Example displayName: Ola Nordmann
Multivalued No
### norEduPersonLegalName
Attribute name norEduPersonLegalName
Short description Person's legal name. Example can be person's name registered within Folkeregisteret.
Example norEduPersonLegalName: Arnt Ola Olsen Nordmann
Multivalued No
### givenName
Attribute name givenName
Short description Person's first name.
Example givenName: Ola
Multivalued Yes
### sn
Attribute name sn
Short description Person's surname.
Example sn: Nordmann

and/or

sn: Olsen Nordmann
Multivalued Yes
### eduPersonPrincipalName
Attribute name eduPersonPrincipalName
Short description Full Feide-name.
Example eduPersonPrincipalName: olanor123@universitetet.no
Multivalued No
`eduPersonPrincipalName` Is per definition non case sensitive. [OlaNor123@uin.no](mailto:OlaNor123@uin.no) is the same Feide name as [olanor123@uin.no](mailto:olanor123@uin.no). Even though the `eduPersonPrincipalName` is per definition non case sensitive, it will be added to the Feide catalogue in lower case for the sake of compatibility with other systems. `eduPersonPrincipalName` should never be reused by a new person. The organization has to ensure that `eduPersonPrincipalName` is unique. If the organization chooses to reuse a `eduPersonPrincipalName` which is not in active use, the organization itself is responsible to make sure that this does not lead to any issues. For instance, `eduPersonPrincipalName` might have been used as identifier in external systems/services, and this is something the organization has to take into consideration. `eduPersonPrincipalName` is comprised of two parts: @. Note that when the domain name is used as realm, this should be subject to a domain that the host organization is the registered owner for. The first part of `eduPersonPrincipalName` (before “@”) should equal `uid`. ### uid
Attribute name uid
Short description The person's local username at the school owner.
Example uid: olanor123
Multivalued No
Even though `uid` is multivalued in the first place, one should only register one value for this field. `uid` is non case sensitive, but should be entered into the catalogue in the same manner as `eduPersonPrincipalName`, alas in lower case. The first part of `eduPersonPrincipalName` shall be comprised of `uid`, before “@”. ### norEduPersonNIN
Attribute name norEduPersonNIN
Short description National identity number.
Example norEduPersonNIN: 28088933134
Multivalued No
`norEduPersonNIN` Shall be a unique identification number issued by Folkeregisteret or Utlendingsdirektoratet (UDI) or Samordna Opptak: - National identity number - D-number - DUF-number - S-number/So-number (student-number issued by Samordna Opptak) If a person does not have any of these numbers, no value should be registered within `norEduPersonNIN` for this person A person can have a user in Feide without a value in `norEduPersonNIN`. This will not be an issue for most services, but for services which depends on `norEduPersonNIN`, the school owner will have to find other solutions to grant access to the service for the user. ### mail
Attribute name mail
Short description The person's email. Shall be a personal address.
Example mail: ola.nordmann@universitetet.no'

and/or

mail: olanor123@stud.universitetet.no
Multivalued Yes
`mail` Shall be a personal email that the user alone has access to. Some services treats `eduPersonPrincipalName` as an email. They are not supposed to, but some uses the value to send the user invitations to resources, messages from other users and more. If the user’s email is different from the value in `eduPersonPrincipalName`, the host organization should consider if they will place this value as an email alias for the user in the email system. Depending on how visible the organization want this alias to be, it can also be added as a value to the `mail` attribute in Feide. ### userPassword
Attribute name userPassword
Short description Person's password for Feide login.
Example userPassword: {CRYPT}$6$ufxrIZTs$hl3ocEOAb01o3HC1yk1DUTD6aaHnH7xD5ZDFCH9xnoNUWZky6lt0/
Multivalued Yes
Even though `userPassword` is multivalued in the first place, it is common to register only one password in this field. In this document, `userPassword` is set as a mandatory attribute because all users have to have one password at login. It’s worth mentioning that a password can be handled automatically by the catalogue system, and the need to handle this directly might not be needed. As long as each person can perform authentication towards the catalogue system, and thus Feide, with a concrete password. ### eduPersonAffiliation
Attribute name eduPersonAffiliation
Short description Roles at organization.
Example eduPersonAffiliation: member
eduPersonAffiliation: student

or

eduPersonAffiliation: faculty
eduPersonAffiliation: employee
eduPersonAffiliation: member
Multivalued Yes
`eduPersonAffiliation` contains information about the person’s general roles at the organization. Within figure 2 a small set of general roles have been presented as a hierarchy. A student will have all of these values: - `eduPersonAffiliation: student` - `eduPersonAffiliation: member` A pedagogical employee will have all these values: - `eduPersonAffiliation: faculty` - `eduPersonAffiliation: employee` - `eduPersonAffiliation: member` A non pedagogical employee will have all these values: - `eduPersonAffiliation: staff` - `eduPersonAffiliation: employee` - `eduPersonAffiliation: member` The value “affiliate” is used to express that a person is affiliated to the organization, but without any formal contracts related to employment or a position as student(for example students attending a private school) - `eduPersonAffiliation: affiliate` A person can have multiple roles, for instance both be an employee and a student: - `eduPersonAffiliation: student` - `eduPersonAffiliation: staff` - `eduPersonAffiliation: employee` - `eduPersonAffiliation: member` Another example of multiple roles is when a person serves as both a principal and a teacher. In this case, the person holds the values of both staff and faculty. - `eduPersonAffiliation: staff` - `eduPersonAffiliation: faculty` - `eduPersonAffiliation: employee` - `eduPersonAffiliation: member` ![Figure showing the role hierarchy for eduPersonAffiliation values. Shows a tree structure with different branches for affiliation values. There are four branches off the root - "member", "affiliate", "alum" and "library-walk-in". The branches for "affiliate", "alum" and "library-walk-in" have no additional affiliations. The "member" affiliation has two child branches - "student" and "employee". The "employee" branch has two additional child branches - "faculty" and "staff". The "student" branch does not have any additional branches.](reference/schema/info_uh/uh_attributter_figur02.jpg) ### eduPersonOrgDN
Attribute name eduPersonOrgDN
Short description Pointer to the LDAP node that contains information about the organization affiliated with the person.
Example eduPersonOrgDN: o=universitetet, dc=no
Multivalued No
### schacHomeOrganization
Attribute name schacHomeOrganization
Short description Realm (last part of eduPersonPrincipalName) to the organization that the person is affiliated to.
Example schacHomeOrganization: universitetet.no
Multivalued No
### norEduPersonAuthnMethod
Attribute name norEduPersonAuthnMethod
(Only mandatory when used with strong authentication)
Short description List over methods for strong authentication which are available for the person.
Example norEduPersonAuthnMethod:
urn:mace:feide.no:auth:method:sms +4712345678 label=Work%20phone
Multivalued Yes
This attribute is mandatory for persons logging into services with strong authentication. Valid values are constructed in this manner: ` ` Identifier for SMS: `urn:mace:feide.no:auth:method:sms` Identifier for Approver/Authenticator: `urn:mace:feide.no:auth:method:ga` Method for authentication can be marked with an optional note to show a user friendly text, and provide separation for the different methods. The marking `label=` shall only be present when there is a note, and it shall not be empty. Examples: When using one time password for sms: - `norEduPersonAuthnMethod: urn:mace:feide.no:auth:method:sms +4712345678 label=Work%20phone` When using the method one time password on sms, without note: - `norEduPersonAuthnMethod: urn:mace:feide.no:auth:method:sms +4712345678` When using the method Approver/Authenticator: - `urn:mace:feide.no:auth:method:ga eyEUJfe...WERIW label=Authenticator%20(Feide)` ### norEduPersonServiceAuthnLevel
Attribute name norEduPersonServiceAuthnLevel
(Can be used with strong authentication, and is not mandatory)
Short description Specifies for which services that requires strong authentication
Example norEduPersonServiceAuthnLevel:
urn:mace:feide.no:spid:12345 urn:mace:feide.no:auth:level:fad08:3

and/or

norEduPersonServiceAuthnLevel:
urn:mace:feide.no:spid:all urn:mace:feide.no:auth:level:fad08:3
Multivalued Yes
This attribute provides the possibility to list which services a single person can utilize strong authentication for. This can for instance be useful for persons that have extended rights to one or more services. Valid values are: - `urn:mace:feide.no:spid:`: Is set for a single service that the person will log in to using strong authentication. Feide-id for service is provided by contacting [support@feide.no](mailto:support@feide.no). - `urn:mace:feide.no:spid:all `: Is set if the person shall log in to all services using strong authentication. For strong authentication through Feide, the uri for authentication level is: `urn:mace:feide.no:auth:level:fad08:3` ## Recommended - person ### eduPersonEntitlement
Attribute name eduPersonEntitlement
Short description Information about rights, roles and groups that this person has.
Example eduPersonEntitlement: urn:mace:feide.no:sigma:confusa:admin

and/or

eduPersonEntitlement: urn:mace:feide.no:stillingskode:stat:1011

and/or

eduPersonEntitlement: http://example.org/contracts/HEd123
Multivalued Yes
`eduPersonEntitlement` contains specific rights or roles that the person has. This can be expressed as a job code or specific rights related to a specific service. As long as any such information is present for a person, the general recommendation is that this is registered within `eduPersonEntitlement` Values used in the field for eduPersonEntitlement shall be valid URIs(Uniform Resource Identifier). We recommend the use of URNs(Uniform Resource Name). If new URN values for `eduPersonEntitlement` are created, these shall be registered within a [register that is administered by Feide](https://www.feide.no/urn). Requests for issuing namespace are sent to email: [support@feide.no](mailto:support@feide.no) ### eduPersonOrgUnitDN
Attribute name eduPersonOrgUnitDN
Short description Pointer to the LDAP node that contains information about the organizational unit(s) affiliated with the person.
Example eduPersonOrgUnitDN: ou=IHK,cn=organization,dc=universitetet, dc=no
Multivalued Yes
### eduPersonPrimaryAffiliation
Attribute name eduPersonPrimaryAffiliation
Short description Primary role at the organization.
Example eduPersonPrimaryAffiliation: student

or

eduPersonPrimaryAffiliation: employee
Multivalued No
`eduPersonPrimaryAffiliation` Defines the person’s primary role at the organization. For instance this can be valuable if a person acts as both student and employee at the organization. For valid values, see more information above `eduPersonAffiliation`. It should be noted that the value used, also has to be set within `eduPersonAffiliation`. ### eduPersonPrimaryOrgUnitDN
Attribute name eduPersonPrimaryOrgUnitDN
Short description Pointer to the LDAP node that contains information about the organizational unit that the person has its main affiliation to.
Example eduPersonPrimaryOrgUnitDN: ou=IHK,cn=organization,dc=universitetet, dc=no
Multivalued No
### eduPersonScopedAffiliation
Attribute name eduPersonScopedAffiliation
Short description Person's role and institution.
Example eduPersonScopedAffiliation: employee@universitetet.no

and/or

eduPersonScopedAffiliation: employee@332244.universitetet.no

and/or

eduPersonScopedAffiliation: student@123321.universitetet.no
Multivalued Yes
### eduPersonOrcid
Attribute name eduPersonOrcid
Short description ORCIDs are identifiers for researchers and connects them to their publications.
Example eduPersonOrcid: https://orcid.org/0000-0002-1825-0097
Multivalued Yes
### mobile
Attribute name mobile
Short description Mobile number connected to this person.
Example mobile: +47 40404040
Multivalued Yes
`mobile` shall be a personal mobile-number only used by the person itself. ### preferredLanguage
Attribute name preferredLanguage
Short description The person's preferred language, defined by ISO 639-3 og BCP 47.
Example preferredLanguage: nn

or

preferredLanguage: nb
Multivalued No
# Organization ## Mandatory - organization ### eduOrgLegalName
Attribute name eduOrgLegalName
Short description The official name of the organization.
Example eduOrgLegalName: Universitetet i Norge
Multivalued Yes
### norEduOrgNIN
Attribute name norEduOrgNIN
Short description Organization's number from Brønnøysundregistrene
Example norEduOrgNIN: NO179530458
Multivalued No
Note that norEduOrgNIN shall be the organization number from Brønnøysundregisteret It shall be comprised of nine digits that are prefixed with NO, and it shall not contain hyphens or spaces. ### norEduOrgSchemaVersion
Attribute name norEduOrgSchemaVersion
Short description Which version of norEdu\* object Class specification the organization is using.
Example norEduOrgSchemaVersion: 2.0
Multivalued No
### o
Attribute name o
Short description Organization's name.
Example o: Universitetet i Norge
Multivalued Yes
### mail
Attribute name mail
Short description Email to organization.
Example mail: kontakt@universitetet.no
Multivalued Yes
## Recommended - organization ### norEduOrgUniqueIdentifier
Attribute name norEduOrgUniqueIdentifier
Short description Number assigned to the organization by Samordna Opptak (SO).
Example norEduOrgUniqueIdentifier: 185
Multivalued No
### telephoneNumber
Attribute name telephoneNumber
Short description Telephone number to the organization.
Example telephoneNumber: +47 73557900
Multivalued Yes
### postalAddress
Attribute name postalAddress
Short description The postal address to the organization.
Example postalAddress: Postboks 340$0100 Oslo
Multivalued Yes
Note that line breaks within postal addresses are typically a $-sign (See example above). This is typically handled by the system that imports the data to the catalogue. # Organizational unit Feide does not demand that organizational units within higher education are registered. It will still be allowed to register information about affiliations within the organization as organizational units(for instance to faculties, institutions and other organization groups). ## Mandatory - organizational unit Feide has per now no demands to attributes that have to be registered for organizational units within higher education. ## Recommended - organizational unit If there is registered information in `eduPersonOrgUnitDN` at one or more persons, we highly recommend that this information is also registered within the nodes that `eduPersonOrgUnitDN` points to. The following information is recommended registered for the organizational units: ### mail
Attribute name mail
Short description Email to the organizational unit
Example mail: post@ihk.hf.uin.no
Multivalued Yes
### norEduOrgUnitUniqueIdentifier
Attribute name norEduOrgUnitUniqueIdentifier
Short description A unique identifier for the organizational unit (location-code)
Example norEduOrgUnitUniqueIdentifier: 223344
Multivalued No
### ou
Attribute name ou
Short description Organization's name.
Example ou: Institutt for historie og klassiske fag
Multivalued Yes
# Optional attributes - person and organization Here is an overview of attributes from norEdu\*-specification that are not mandatory or recommended in Feide. For more information about each attribute, see [«norEdu\* Object Class Specification»](../noredu/index.html.md). It is up to each organization to take into consideration if this information shall be added to the Feide catalogue, but it is advantageous to add what information one has available. ## norEduOrgAcronym
Attribute name norEduOrgAcronym
Short description Acronym for organization or organizational unit.
Example norEduOrgAcronym: USIT
Multivalued Yes
## norEduPersonBirthDate
Attribute name norEduPersonBirthDate
Short description Person's birthdate
Example norEduPersonBirthDate: 280889
Multivalued No
## norEduPersonLIN
Attribute name norEduPersonLIN
Short description Local ID-number, for example student- or employee number
Example norEduPersonLIN: uninett.no:employee:035016
Multivalued Yes
## eduOrgIdentityAuthNPolicyURI
Attribute name eduOrgIdentityAuthNPolicyURI
Short description URI that points to the organization's policy for handling identities
Example eduOrgIdentityAuthNPolicyURI: https://www.universitetet.no/security/IApolicy.html
Multivalued Yes
## eduOrgHomePageURI
Attribute name eduOrgHomePageURI
Short description URL to the organization's toplevel website.
Example eduOrgHomePageURI: https://www.universitetet.no
Multivalued Yes
## eduOrgWhitePagesURI
Attribute name eduOrgWhitePagesURI
Short description URL to the organization's open catalogue service.
Example eduOrgWhitePagesURI: ldap://wpage.universitetet.no
Multivalued Yes
## eduPersonAssurance
Attribute name eduPersonAssurance
Short description URI providing information about which trust levels for identity handling and authentication the organization supports.
Example eduPersonAssurance: urn:mace:incommon:IAQ:sample
Multivalued Yes
## eduPersonNickname
Attribute name eduPersonNickname
Short description The name the person is referred to on a daily basis.
Example eduPersonNickname: Ola
Multivalued Yes
## eduPersonPrincipalNamePrior
Attribute name eduPersonPrincipalNamePrior
Short description Former eduPersonPrincipalName at the same legal organization.
Example eduPersonPrincipalNamePrior: olno@gammeltuniversitetsnavn.no
eduPersonPrincipalNamePrior: olenor@fusjonerthoyskole.no
Multivalued Yes
All values within the attribute must have been owned by the same legal organization as the current `eduPersonPrincipalName`. In practice the values must have Feide-names with: * organization’s present realm * organization’s former used realm of this has been changed * realm from merged organizations Feide-name used at other organizations is not allowed due to security concerns. It is the responsibility of the host organization to make sure that the fields value used does not enable persons at the organization to impersonate someone else at the organization or other organizations. The attribute shall **not** contains the person’s current `eduPersonPrincipalName`. The attribute might be used as a signal to services that this person has had other `eduPersonPrincipalName` in the past. This can be used for internal logic, for instance connecting accounts within the service and similar. ## facsimileTelephoneNumber
Attribute name facsimileTelephoneNumber
Short description Fax number.
Example facsimileTelephoneNumber: +47 73557901
Multivalued Yes
## homePhone
Attribute name homePhone
Short description Person's home number.
Example homePhone: +47 23456789
Multivalued Yes
## homePostalAddress
Attribute name homePostalAddress
Short description Postal address for the person's home.
Example homePostalAddress: Jordbærgata 14c$0234 Ski
Multivalued Yes
## jpegPhoto
Attribute name jpegPhoto
Short description A picture of the person in jpeg-format (up to 250\*250 px, approximately 30kB)
Example (attribute value is in binary format)
Multivalued Yes
## l (localityName)
Attribute name l (localityName)
Short description Name for location. Example could be city or county.
Example l: Oslo
Multivalued Yes
## labeledURI
Attribute name labeledURI
Short description An URI with description (label).
Example labeledURI: https://www.universitetet.no/itregl.html IT-reglement
Multivalued Yes
## manager
Attribute name manager
Short description LDAP-pointer to person's manager.
Example manager:uid=ojohnsen,ou=people,dc=universitetet,dc=no
Multivalued Yes
## postalCode
Attribute name postalCode
Short description Postal number for the organization.
Example postalCode: NO-7465
Multivalued Yes
## postOfficeBox
Attribute name postOfficeBox
Short description Mailbox.
Example postOfficeBox: 109260
Multivalued Yes
## street
Attribute name street
Short description Street address.
Example street: Universitetsgata 3
Multivalued Yes
## title
Attribute name title
Short description Person's title.
Example title: Section manager for language studies
Multivalued Yes
## userCertificate
Attribute name userCertificate
Short description Person's X.509-certificate.
Example (attribute value is in binary-format)
Multivalued Yes
## userSMIMECertificate
Attribute name userSMIMECertificate
Short description A X.509-certificate meant for use in S/MIMEapplications, for example signing and encryption of email.
Example (attribute value is in binary-format)
Multivalued Yes
# Changelog ## From version 2012-02 to version 2013-10 - `norEduPersonNIN` is changed from “mandatory” to “mandatory if a valid value exists”. Guidelines for what types of numbers that can be added to `norEduPersonNIN` have been changed. - `eduPersonPrimaryAffiliation` is changed from mandatory to recommended. - Two new attributes have been recommended: - `eduPersonScopedAffiliation` - `schacHomeOrganization` - Clarifying that `uid` shall equal the first part of `eduPersonPrincipalName` (before “@”) - Information about `eduPersonPrincipalName` and which realm that can be used has been changed. - Document is now referring to norEdu\*-specification version 1.5.1. - New chapter with more information about mandatory, recommended and optional attributes added (ch. 1.2). - Figure 1 has been updated, generalizing which attributes are mandatory, recommended and optional. - New chapter with overview of optional attributes added to (ch. 5). - Changelog added to (ch. 6) ## From version 2014-01 to 2015-06 - A new attribute is mandatory for persons that will use strong authentication: - `norEduPersonAuthnMethod` - A new attribute that can be used to list up which services a single person shall use strong authentication for. (This is not mandatory): - `norEduPersonServiceAuthnLevel` - `schacHomeOrganization` is changed from recommended to mandatory. - It is specified that students attending private schools shall have the value “affiliate” in the attribute `eduPersonAffiliation` to clarify affiliation to the organization. ## From version 2015-06 to 2018-03 - The document now refers to norEdu\*-specification version 2.0. - Added recommended attribute `eduPersonOrcid`. - Added optional attribute `eduPersonPrincipalNamePrior`. - Clarifying that users without NIN can in fact have a Feide user. - Clarify the usage of notes on authentication methods. - Added section about data-processing contracts between host organizations and services. - Added section about services that incorrectly uses `eduPersonPrincipalName` as email under the `mail` attribute. - Reformatted from PDF to web-document - Reformatted wide tables (collection) into one table per attribute. - Corrected error in example for `norEduPersonAuthnMethod`. Approval secret was shown unencrypted when it should be encrypted. Unencrypted values here have always been rejected by Feide. - Corrected error in example for `eduPersonAffiliation` and `eduPersonScopedAffiliation`. Added necessary variants. # Appendix 1 - LDIF-example Example of populated LDAP-objects that satisfies Feide demands. ## Person ```default dn: uid=olanor123,cn=people,dc=universitet,dc=no objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top objectClass: eduPerson objectClass: schac objectClass: norEduPerson cn: Ola Olsen Nordmann cn: olanor123 displayName: Ola Nordmann eduPersonAffiliation: member eduPersonAffiliation: student eduPersonAffiliation: employee eduPersonPrimaryAffiliation: student eduPersonOrcid: https://orcid.org/0000-0002-1825-0097 eduPersonOrgDN: dc=universitetet,dc=no eduPersonPrincipalName: olanor123@universitetet.no eduPersonPrincipalNamePrior: olno@gammeltuniversitetsnavn.no eduPersonPrincipalNamePrior: olenor@fusjonerthoyskole.no eduPersonScopedAffiliation: employee@universitetet.no eduPersonScopedAffiliation: member@universitetet.no eduPersonScopedAffiliation: employee@223344.universitetet.no eduPersonScopedAffiliation: member@223344.universitetet. eduPersonScopedAffiliation: student@123321.universitetet.no eduPersonScopedAffiliation: member@123321.universitetet.no givenName: Ola mail: ola.nordmann@universitetet.no mail: olanor123@stud.universitetet.no norEduPersonLegalName: Arnt Ola Olsen Nordmann norEduPersonNIN: 28088933134 norEduPersonAuthnMethod: urn:mace:feide.no:auth:method:sms +4740404040 label=Work%20phone schacHomeOrganization: universitetet.no sn: Nordmann sn: Olsen Nordmann uid: olanor123 userPassword: {CRYPT}$6$ufxrIZTs$hl3ocEOAb01o3HC1yk1DUTD6aaHnH7xD5ZDFCH9xnoNUWZky6lt0/ mobile: +47 40404040 preferredLanguage: nb eduPersonEntitlement: urn:mace:feide.no:stillingskode:stat:1011 eduPersonOrgUnitDN: ou=IHK,cn=organization,dc=universitetet,dc=no eduPersonPrimaryOrgUnitDN: ou=IHK,cn=organization,dc=universitetet,dc=no ``` ## Organization ```default dn: dc=universitetet,dc=no objectClass: eduOrg objectClass: norEduOrg objectClass: organization objectClass: top dc: universitetet eduOrgLegalName: Universitetet i Norge norEduOrgNIN: NO179530458 norEduOrgSchemaVersion: 2.0 o: Universitetet i Norge mail: info@universitetet.no cn: Universitetet i Norge norEduOrgUniqueIdentifier: 185 telephoneNumber: +47 73557900 postalAddress: Postboks 340$NO-0100 Oslo ``` ## Organizational unit ```default dn: ou=Institutt for historie og klassiske fag,cn=organization,dc=universitetet,dc=no objectClass: norEduOrgUnit objectClass: organizationalUnit objectClass: top cn: Institutt for historie og klassiske fag mail: ihk@hf.universitetet.no norEduOrgUnitUniqueIdentifier: 223344 ou: Institutt for historie og klassiske fag ``` # norEdu\* Object Class Specification **Version 2.0, March 2018**
Version Date Initials Comments
2.0 March 2018 SL Update to eduPerson 201602, schac 1.5 and editorial changes
1.6 September 2015 JPC, HV Added the norEduPersonServiceAuthnLevel and norEduPersonAuthnMethod attributes.
* [Status of this document](noredu_ch01.html.md) * [Introduction](noredu_ch02.html.md) * [Relationship to other LDAP schemas](noredu_ch02.html.md#relationship-to-other-ldap-schemas) * [Privacy concerns and security measures](noredu_ch02.html.md#privacy-concerns-and-security-measures) * [Variations in use of norEdu\*](noredu_ch02.html.md#variations-in-use-of-noredu) * [Attribute specifications (normative)](noredu_ch03.html.md) * [Attribute survey](noredu_ch03.html.md#attribute-survey) * [Attribute list](noredu_ch03.html.md#attribute-list) * [norEduPerson, norEduOrg and norEduOrgUnit attributes](noredu_ch03.html.md#noreduperson-noreduorg-and-noreduorgunit-attributes) * [norEduOrgAcronym](noredu_ch03.html.md#noreduorgacronym) * [norEduOrgNIN](noredu_ch03.html.md#noreduorgnin) * [norEduOrgSchemaVersion](noredu_ch03.html.md#noreduorgschemaversion) * [norEduOrgUniqueIdentifier](noredu_ch03.html.md#noreduorguniqueidentifier) * [norEduOrgUnitUniqueIdentifier](noredu_ch03.html.md#noreduorgunituniqueidentifier) * [norEduPersonBirthDate](noredu_ch03.html.md#noredupersonbirthdate) * [norEduPersonLegalName](noredu_ch03.html.md#noredupersonlegalname) * [norEduPersonLIN](noredu_ch03.html.md#noredupersonlin) * [norEduPersonNIN](noredu_ch03.html.md#noredupersonnin) * [norEduPersonServiceAuthnLevel](noredu_ch03.html.md#noredupersonserviceauthnlevel) * [norEduPersonAuthnMethod](noredu_ch03.html.md#noredupersonauthnmethod) * [Attributes from schac](noredu_ch03.html.md#attributes-from-schac) * [schacHomeOrganization](noredu_ch03.html.md#schachomeorganization) * [Attributes from eduPerson](noredu_ch03.html.md#attributes-from-eduperson) * [eduPersonAffiliation](noredu_ch03.html.md#edupersonaffiliation) * [eduPersonEntitlement](noredu_ch03.html.md#edupersonentitlement) * [eduPersonNickname](noredu_ch03.html.md#edupersonnickname) * [eduPersonOrgDN](noredu_ch03.html.md#edupersonorgdn) * [eduPersonOrgUnitDN](noredu_ch03.html.md#edupersonorgunitdn) * [eduPersonPrimaryAffiliation](noredu_ch03.html.md#edupersonprimaryaffiliation) * [eduPersonPrimaryOrgUnitDN](noredu_ch03.html.md#edupersonprimaryorgunitdn) * [eduPersonPrincipalName](noredu_ch03.html.md#edupersonprincipalname) * [eduPersonPrincipalNamePrior](noredu_ch03.html.md#edupersonprincipalnameprior) * [eduPersonScopedAffiliation](noredu_ch03.html.md#edupersonscopedaffiliation) * [eduPersonTargetedID](noredu_ch03.html.md#edupersontargetedid) * [eduPersonAssurance](noredu_ch03.html.md#edupersonassurance) * [eduPersonUniqueId](noredu_ch03.html.md#edupersonuniqueid) * [eduPersonOrcid](noredu_ch03.html.md#edupersonorcid) * [Attributes from eduOrg](noredu_ch03.html.md#attributes-from-eduorg) * [eduOrgHomePageURI](noredu_ch03.html.md#eduorghomepageuri) * [eduOrgIdentityAuthNPolicyURI](noredu_ch03.html.md#eduorgidentityauthnpolicyuri) * [eduOrgLegalName](noredu_ch03.html.md#eduorglegalname) * [eduOrgWhitePagesURI](noredu_ch03.html.md#eduorgwhitepagesuri) * [Common attributes](noredu_ch03.html.md#common-attributes) * [cn](noredu_ch03.html.md#cn) * [dc](noredu_ch03.html.md#dc) * [displayName](noredu_ch03.html.md#displayname) * [facsimileTelephoneNumber](noredu_ch03.html.md#facsimiletelephonenumber) * [givenName](noredu_ch03.html.md#givenname) * [homePhone](noredu_ch03.html.md#homephone) * [homePostalAddress](noredu_ch03.html.md#homepostaladdress) * [jpegPhoto](noredu_ch03.html.md#jpegphoto) * [l (localityName)](noredu_ch03.html.md#l-localityname) * [labeledURI](noredu_ch03.html.md#labeleduri) * [mail](noredu_ch03.html.md#mail) * [manager](noredu_ch03.html.md#manager) * [mobile](noredu_ch03.html.md#mobile) * [o](noredu_ch03.html.md#o) * [ou](noredu_ch03.html.md#ou) * [postalAddress](noredu_ch03.html.md#postaladdress) * [postalCode](noredu_ch03.html.md#postalcode) * [postOfficeBox](noredu_ch03.html.md#postofficebox) * [preferredLanguage](noredu_ch03.html.md#preferredlanguage) * [sn](noredu_ch03.html.md#sn) * [street](noredu_ch03.html.md#street) * [telephoneNumber](noredu_ch03.html.md#telephonenumber) * [title](noredu_ch03.html.md#title) * [uid](noredu_ch03.html.md#uid) * [userCertificate](noredu_ch03.html.md#usercertificate) * [userPassword](noredu_ch03.html.md#userpassword) * [userSMIMECertificate](noredu_ch03.html.md#usersmimecertificate) * [Document information](noredu_ch04.html.md) * [Acknowledgments](noredu_ch04.html.md#acknowledgments) * [Change log](noredu_ch04.html.md#change-log) * [From version 1.0 to 1.1](noredu_ch04.html.md#from-version-1-0-to-1-1) * [From version 1.1 to 1.2](noredu_ch04.html.md#from-version-1-1-to-1-2) * [From version 1.2 to 1.3](noredu_ch04.html.md#from-version-1-2-to-1-3) * [From version 1.3 to 1.4](noredu_ch04.html.md#from-version-1-3-to-1-4) * [From version 1.4 to 1.4.1](noredu_ch04.html.md#from-version-1-4-to-1-4-1) * [From version 1.4.1 to 1.5](noredu_ch04.html.md#from-version-1-4-1-to-1-5) * [From version 1.5 to 1.5.1](noredu_ch04.html.md#from-version-1-5-to-1-5-1) * [From version 1.5.1 to 1.6](noredu_ch04.html.md#from-version-1-5-1-to-1-6) * [From version 1.6 to 2.0](noredu_ch04.html.md#from-version-1-6-to-2-0) * [Appendix A: Object classes (normative)](noredu_chAA.html.md) * [norEdu](noredu_chAA.html.md#noredu) * [norEduOrg](noredu_chAA.html.md#noreduorg) * [norEduOrgUnit](noredu_chAA.html.md#noreduorgunit) * [norEduPerson](noredu_chAA.html.md#noreduperson) * [norEduObsolete](noredu_chAA.html.md#noreduobsolete) * [eduPerson](noredu_chAA.html.md#eduperson) * [eduOrg](noredu_chAA.html.md#eduorg) * [Appendix B: Attribute definitions (normative)](noredu_chAB.html.md) * [Attributes defined by norEdu\*](noredu_chAB.html.md#attributes-defined-by-noredu) * [norEduPersonNIN](noredu_chAB.html.md#noredupersonnin) * [norEduPersonLegalName](noredu_chAB.html.md#noredupersonlegalname) * [norEduPersonLIN](noredu_chAB.html.md#noredupersonlin) * [norEduOrgAcronym](noredu_chAB.html.md#noreduorgacronym) * [norEduPersonBirthDate](noredu_chAB.html.md#noredupersonbirthdate) * [norEduOrgSchemaVersion](noredu_chAB.html.md#noreduorgschemaversion) * [norEduOrgUniqueIdentifier](noredu_chAB.html.md#noreduorguniqueidentifier) * [norEduOrgUnitUniqueIdentifier](noredu_chAB.html.md#noreduorgunituniqueidentifier) * [norEduOrgNIN](noredu_chAB.html.md#noreduorgnin) * [norEduPersonServiceAuthnLevel](noredu_chAB.html.md#noredupersonserviceauthnlevel) * [norEduPersonAuthnMethod](noredu_chAB.html.md#noredupersonauthnmethod) * [Obsolete norEdu\* attributes](noredu_chAB.html.md#obsolete-noredu-attributes) * [norEduOrgUniqueNumber](noredu_chAB.html.md#noreduorguniquenumber) * [norEduOrgUnitUniqueNumber](noredu_chAB.html.md#noreduorgunituniquenumber) * [federationFeideSchemaVersion](noredu_chAB.html.md#federationfeideschemaversion) * [Attributes from schac](noredu_chAB.html.md#attributes-from-schac) * [schacHomeOrganization](noredu_chAB.html.md#schachomeorganization) * [Attributes from eduPerson](noredu_chAB.html.md#attributes-from-eduperson) * [eduPersonAffiliation](noredu_chAB.html.md#edupersonaffiliation) * [eduPersonEntitlement](noredu_chAB.html.md#edupersonentitlement) * [eduPersonNickname](noredu_chAB.html.md#edupersonnickname) * [eduPersonOrgDN](noredu_chAB.html.md#edupersonorgdn) * [eduPersonOrgUnitDN](noredu_chAB.html.md#edupersonorgunitdn) * [eduPersonPrimaryAffiliation](noredu_chAB.html.md#edupersonprimaryaffiliation) * [eduPersonPrimaryOrgUnitDN](noredu_chAB.html.md#edupersonprimaryorgunitdn) * [eduPersonPrincipalName](noredu_chAB.html.md#edupersonprincipalname) * [eduPersonScopedAffiliation](noredu_chAB.html.md#edupersonscopedaffiliation) * [eduPersonTargetedID](noredu_chAB.html.md#edupersontargetedid) * [eduPersonAssurance](noredu_chAB.html.md#edupersonassurance) * [eduPersonPrincipalNamePrior](noredu_chAB.html.md#edupersonprincipalnameprior) * [eduPersonUniqueId](noredu_chAB.html.md#edupersonuniqueid) * [eduPersonOrcid](noredu_chAB.html.md#edupersonorcid) * [Attributes from eduOrg](noredu_chAB.html.md#attributes-from-eduorg) * [eduOrgHomePageURI](noredu_chAB.html.md#eduorghomepageuri) * [eduOrgIdentityAuthNPolicyURI](noredu_chAB.html.md#eduorgidentityauthnpolicyuri) * [eduOrgLegalName](noredu_chAB.html.md#eduorglegalname) * [eduOrgWhitePagesURI](noredu_chAB.html.md#eduorgwhitepagesuri) * [Appendix C: Obsolete attributes](noredu_chAC.html.md) * [Attributes obsoleted from norEdu\*1.3 to norEdu\*1.4](noredu_chAC.html.md#attributes-obsoleted-from-noredu-1-3-to-noredu-1-4) # Status of this document This document is the updated version of the norEdu\* object class specification. The specification is appropriate for use in enterprise directory service environments in the education sector. Please monitor [www.feide.no](https://www.feide.no) if you are using this document. The norEdu\* specification consists of Chapters 2, 3 and Appendix A, B of this document. Chapter 1 (this chapter), Chapter 4 and Appendix C are informative only, and are not parts of the norEdu\* specification. New versions of the norEdu\* specification will be announced on [www.feide.no](https://www.feide.no). # Introduction ## Relationship to other LDAP schemas [RFC 4519](https://datatracker.ietf.org/doc/html/rfc4519) “Lightweight Directory Access Protocol (LDAP): Schema for User Applications” adopts a selection of X.520 attributes for use in LDAP. The schema defines several object classes, most of them structural, with an extensive set of general attributes. Furthermore, [RFC 4524](https://datatracker.ietf.org/doc/html/rfc4524), [RFC 2798](https://datatracker.ietf.org/doc/html/rfc2798) and [RFC 2079](https://datatracker.ietf.org/doc/html/rfc2079) define attributes that are not particularly aimed at a specific application area. These attributes are customarily referred to as “common attributes”. [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html) is defined by the Object Class Specifications by UCAID’s Internet2 Middleware Architecture Committee Directory Working Group (MACE-Dir). It is designed for campus directories to facilitate communication among higher education institutions. eduPerson consists of a set of data elements or attributes about individuals within higher education, along with recommendations on the syntax and semantics of the data that may be assigned to those attributes. [eduOrg](https://spaces.at.internet2.edu/download/attachments/110336044/00003-EduOrgObjectClassSpecification200210.pdf) describes attributes applicable to higher education organizations. [schac](https://wiki.refeds.org/display/STAN/SCHAC) is developed and maintained by a working group in [REFEDS](https://refeds.org/), supported by the [Trans-European Research and Education Networking Association](https://www.terena.org/), to supplement eduPerson/eduOrg in areas where eduPerson/eduOrg definitions are considered insufficient. It is assumed that the eduPerson/eduOrg classes are used together with schac. The norEdu\* classes add further attributes supplementing eduPerson/eduOrg in order to satisfy the requirements of the environment of the Nordic educational community, such as support for National Identity Numbers (norEduPersonNIN) and for the educational numbering and identifier schemes. The eduPerson, eduOrg, schac and norEdu object classes are all defined as auxiliary, because they will be used in conjunction with existing structural object classes, such as the “person” class of RFC 4519 (eduPerson, eduOrg and schac make references to the equivalent X.521 definitions). schac also references the [RFC 2798](https://datatracker.ietf.org/doc/html/rfc2798) “inetOrgPerson” class. It is assumed that norEdu\* is used together with eduPerson/eduOrg, and consequently with the structural classes of [RFC 4519](https://datatracker.ietf.org/doc/html/rfc4519). This specification cites eduPerson/eduOrg attribute descriptions, a selection of schac attribute descriptions and relevant common attributes from [RFC 4519](https://datatracker.ietf.org/doc/html/rfc4519). Although the attribute definitions are not formally part of norEdu\*, norEdu\* usage rules apply directly to these attributes. So as a matter of convenience, attribute descriptions are included here together with the usage rules. To some degree, the eduPerson/eduOrg attributes have a wider scope than requested by the norEdu\* community. When used with norEdu\*, this document makes certain restrictions/requirements specified in “usage rules”. To cover national or regional needs, other educational communities have developed LDAP schemes similar to norEdu\* and schac; examples are [auEduPerson](https://aaf.edu.au/media/2016/04/auEduPerson_attribute_vocabulary_v02-1-0.pdf) and [funetEduPerson](https://wiki.eduuni.fi/download/attachments/27297818/HAKA-funetEduPersonSchema2dot2-271015-1400-6396.pdf). Various supplements to eduPerson/eduOrg may be overlapping and possibly conflicting in rules of usage, syntax and semantics. It is a long-term goal to unify the various schemas used by educational institutions worldwide. The norEdu\* references to schac attributes, and the Nordic cooperation for maintaining norEdu\* is part of this effort. ## Privacy concerns and security measures Information in norEduPerson, and to a certain degree norEduOrg/norEduOrgUnit, is or can be related to individuals. This means that the attribute, depending on context may be regarded as personal information. Given that something is regarded as personal information, its storage and use is regulated by national and international privacy legislation. As a part of the documentation of every attribute, there is an assessment of that attribute’s need for confidentiality and integrity; see the table in [Attribute survey](./noredu_ch03.html#attribute-survey) below. Some attributes contain individual comments in the usage notes. In addition to the assessments and comments for the individual attributes one should be aware that the need for e.g. confidentiality would rise when one puts several attributes together. Revealing a person’s home address is more sensitive when one at the same time reveals that persons sex, age, name and telephone number. Since there is an enormous amount of possible combinations of different attributes, it is not feasible to analyse each possible combination. The attributes norEduPersonNIN, norEduPersonAuthnMethod and all passwords should be protected by access controls to ensure that only authorized users or applications may access this information in the LDAP directory. ## Variations in use of norEdu\* Although norEdu\* represents a common Nordic effort, legal regulations, established conventions and external conditions may vary between national environments. Requirements may also vary among institutions of different educational levels. Attributes considered mandatory in one environment may be irrelevant in another. E.g. university students have individual email addresses, elementary school children don’t necessarily have one. Therefore, in the norEdu\* schema, no attributes are mandated by the schema definition. However, a given federation, such as Feide, may declare attributes as mandatory within this federation. Feide’s requirements regarding each attribute are described in the document as “Feide usage”. Mandatory and recommended attributes in Feide are described in the attribute documents [UH-attributter](../../../reference/schema/info_uh/index.html) and [GO-attributter](../../../reference/schema/info_go/index.html), intended for the primary and secondary education and higher education respectively. For users to be authenticated by Feide, and for the organizations these users belong to, the attributes mandated by Feide will always be present. If users are cross-federated, i.e. authentication is done based on information in another, trusted federation, attributes may be missing. Handling of this situation is left to the service making use of the authentication service: If missing attributes are considered essential e.g. for billing or authorization purposes, the service may reject the user, even when authentication succeeds. If missing attributes are considered non-essential by the service, the user may be accepted, possibly with functional restrictions (such as email related operations being unavailable to users without an email address). # Attribute specifications (normative) ## Attribute survey The table in this chapter summarizes all norEdu\* attributes as well as the attributes of other classes that are assumed to be available. The table also provides information regarding attribute usage, such as requirements for confidentiality, data integrity and availability. The attributes are described by the following attributes:
Application utility class:
Core: Attribute belongs to minimally useful attribute set.
Standard: Basic applications like white pages and some authorization data.
Extended: Of use to some set of more specialized applications.
Confidentiality:
None: No restrictions or requirements.
Low: Data well known from other sources.
Medium: Personal information.
High: Special rules apply.
Data integrity:
Low: Values cannot be guaranteed to be up to date.
Medium: Values should be up to date.
High: Values are required to be up to date, maximum 24 hours latency.
Attribute name Application utility class Confidentiality Data integrity
norEduOrgAcronym Standard Low Medium
norEduOrgNIN Standard None Medium
norEduOrgSchemaVersion Standard None Medium
norEduOrgUniqueIdentifier Standard None Medium
norEduOrgUnitUniqueIdentifier Standard None Medium
norEduPersonBirthDate Standard Low Low
norEduPersonLegalName Standard Low Medium
norEduPersonLIN Standard Medium High
norEduPersonNIN Core Medium High
norEduPersonServiceAuthnLevel Extended High/Medium High
norEduPersonAuthnMethod Extended High/Medium High
schacHomeOrganization Standard Low Medium
eduOrgIdentityAuthNPolicyURI Standard Low High
eduOrgLegalName Standard Low High
eduOrgHomePageURI Standard Low Low
eduOrgWhitePagesURI Standard Low Medium
eduPersonAffiliation Standard Low Medium
eduPersonAssurance Extended Low Medium
eduPersonEntitlement Extended Low Medium
eduPersonNickname Standard Low Medium
eduPersonOrcid Standard Low Medium
eduPersonOrgDN Core Low Medium
eduPersonOrgUnitDN Standard Low Medium
eduPersonPrimaryAffiliation Standard Low Medium
eduPersonPrimaryOrgUnitDN Extended Low Medium
eduPersonPrincipalName Standard Low High
eduPersonPrincipalNamePrior Standard Low Medium
eduPersonScopedAffiliation Standard Low Medium
eduPersonTargetedID Extended Low Medium
eduPersonUniqueId Standard Low Medium
cn Core Low Medium
dc Standard None Low
displayName Standard Low Medium
facsimileTelephoneNumber Extended Low Medium
givenName Standard Low Medium
homePhone Extended Medium Low
homePostalAddress Extended High Low
jpegPhoto Extended High Low
l (localityName) Extended Low Low
labeledURI Extended Low Medium
manager No recommendation Low Medium
mail Standard Medium High
mobile Extended Low Medium
o Standard Low High
ou Standard Low High
postalAddress Extended Low Medium
postalCode Extended Low Medium
postOfficeBox Extended Low Medium
preferredLanguage Extended Medium Medium
sn Core Medium High
street Extended Low Medium
telephoneNumber Standard Medium Medium
title Extended Low Medium
uid Standard Low High
userCertificate Extended Low High
userPassword Extended High High
userSMIMECertificate Extended Medium High
## Attribute list This section gives a detailed description of all norEdu\* attributes as well as the attributes of other classes that are assumed to be available. Attributes from the several non-educational object classes are listed. The purpose of listing them is primarily as a convenience to enterprise directory designers, but in some cases notes are added to clarify aspects of meaning or usage in the education community beyond what can be found in the original standards documents. The following format for attribute description is used:
Name <attribute name>
Description <short description of what the attribute describes>
Format <given in text, transcribing the RFC 4517 OID name for the attribute syntax rules>
# of values <single or multi>
References <reference to standard, RFC or similar>
OID <unique identification of the attribute>
Examples <one or more examples of attribute definition (LDIF fragment)>
## norEduPerson, norEduOrg and norEduOrgUnit attributes ### norEduOrgAcronym
Name norEduOrgAcronym
Description Acronym for the educational institution or similar object.
Format DirectoryString
# of values Multi
OID 1.3.6.1.4.1.2428.90.1.6
Examples norEduOrgAcronym: USIT
**Usage notes** To be used with the norEduOrg and norEduOrgUnit object classes. The system that is the source of the institutions’ organizational structure should also be the source of authoritative acronyms for the institution and its parts. ### norEduOrgNIN
Name norEduOrgNIN
Description The organization number assigned by the public authorities, prefixed with a country code.
Format DirectoryString
# of values Single
OID 1.3.6.1.4.1.2428.90.1.12
Examples norEduOrgNIN: NO987747323
**Usage notes** Not relevant for persons. In Norway, organization identifiers are assigned by the Norwegian Register of Business Enterprises (Brønnøysundregistrene, Foretaksregisteret). The identifier consists of an “NO” country code prefix, followed by 9 digits; the last one is a check digit. In Sweden, the VAT number is used, consisting of an “SE” country code prefix, followed by 12 digits; the last two are check digits. No hyphens are used. ### norEduOrgSchemaVersion
Name norEduOrgSchemaVersion
Description LDAP schema information for the federation. Version number of the norEdu\* specification in use.
Format DirectoryString
# of values Single
OID 1.3.6.1.4.1.2428.90.1.11
Examples norEduOrgSchemaVersion: 2.0
**Usage notes** Not relevant for persons, to be used at the organization directory server. This attribute obsoletes the federationFeideSchemaVersion introduced in norEdu\* 1.3. **Example applications for which this attribute would be useful:** Any application that needs to control which version of attribute definition is in use at the identity provider’s directory server. ### norEduOrgUniqueIdentifier
Name norEduOrgUniqueIdentifier
Description The number assigned the higher educational institution by Universities and Colleges Admission Service ("Samordna opptak", SO).
Format DirectoryString
# of values Single
OID 1.3.6.1.4.1.2428.90.1.7
Examples norEduOrgUniqueIdentifier: 00000185
**Usage notes** Not relevant for persons. Format is 3 digits country code (000 for Norway) and 5 digits institution number. Most Norwegian universities and colleges have 5 leading zeros in this number. See also [norEduOrgNIN](#noreduorgnin). **Feide usage note** Note that this is not the organization number assigned by the public authorities such as those assigned by the Norwegian Register of Business Enterprises (Brønnøysundregistrene). ### norEduOrgUnitUniqueIdentifier
Name norEduOrgUnitUniqueIdentifier
Description The identifier describing an organizational unit.
Format DirectoryString
# of values Single
OID 1.3.6.1.4.1.2428.90.1.8
Examples norEduOrgUnitUniqueIdentifier: 332244
**Usage notes** Not relevant for persons. For institutions in higher education, this is locally assigned. Local uniqueness should be assured. **Feide usage notes** For primary and secondary education, the organization number, or an underlying company number, assigned by the Norwegian Register of Business Enterprises (Brønnøysundregistrene) is used. The institutions in higher education establish their own organizational structure and describe it using location codes (“stedkoder”). This is done as an integral part of FS, but the institutions may make corresponding definitions relating to employee registries or accounting systems. One way to use this is to contain a six-digit number of the form XXYYZZ where XX is organizational unit (“enhet”), YY is section (“seksjon”) and ZZ is group (“gruppe”). **Example applications for which this attribute would be useful:** Door locks, physical access control, web portals. ### norEduPersonBirthDate
Name norEduPersonBirthDate
Description The date of birth for the subject it is associated with.
Format NumericString
# of values Single
OID 1.3.6.1.4.1.2428.90.1.3
Examples norEduPersonBirthDate: 19660412
**Usage notes:** The string has the format YYYYMMDD, using 4 digits for year, 2 digits for month and 2 digits for day as in the date representation in **basic format** in [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html). A person’s birth date is not sensitive data. There are few possibilities for misuse of this data without combining with several other data, and even then the damage that can be done with a person’s birth date it is very limited. **Feide usage notes:** The attribute is obtained from the institution’s employee, school or student registries. The first 6 digits of norEduPersonNIN and the birth date for a person may be different. This is more likely to occur with short-lived NINs. **Example applications for which this attribute would be useful:** Portals with age-relevant classes of content. ### norEduPersonLegalName
Name norEduPersonLegalName
Description The legal name for the subject it is associated with.
Format DirectoryString
# of values Single
OID 1.3.6.1.4.1.2428.90.1.10
Examples norEduPersonLegalName: Walter Martin Tveter
norEduPersonLegalName: Jack Peter Dougherty
**Usage notes** The person’s full formal name as registered by public authorities. **Feide usage notes** The person’s name as registered in “Det Sentrale Folkeregister” is used as norEduPersonLegalName. The attribute is obtained from the institution’s employee, school or student registries and possibly registries for non-employee affiliated persons. **Example applications for which this attribute would be useful:** For applications with high formal requirements the full formal name might be required. ### norEduPersonLIN
Name norEduPersonLIN
Description Local identity number, for instance student number or employee number.
Format DirectoryString
# of values Multiple
OID 1.3.6.1.4.1.2428.90.1.4
Examples norEduPersonLIN: uninett.no:employee:035016
**Usage notes** This identifier may also be used for scoped identity numbers, provided that the issuer prepends the identifier with a realm for the issuing authority. Another use is similar to the attribute [eduPersonTargetedID](#edupersontargetedid). A given value is intended only for consumption by a specific requester. When guaranteed global uniqueness is required, [eduPersonPrincipalName](#edupersonprincipalname) should be preferred over norEduPersonLIN. norEduPersonLIN is not guaranteed to be unique across several enterprise directory servers (the same locally assigned norEduPersonLIN may be issued to several persons), unless these are coordinated e.g. through use of a unique prefix. **Feide usage notes** The format consists of a prefix to ensure global uniqueness, and a string in a locally defined format. In Feide, the realm part of the eduPersonPrincipalName (i.e. the string to the right of the ‘@’) should be used as a prefix. The attribute is obtained from the institution’s employee, school or student registries. It is mostly added for backwards compatibility with legacy systems. **Example applications for which this attribute would be useful:** Library systems, legacy payroll systems, targets with need to maintain a persistent but opaque identifier for a given user for purposes of personalization or record-keeping. ### norEduPersonNIN
Name norEduPersonNIN
Description National Identity Number, a unique, officially assigned, personal identity number.
Format DirectoryString
# of values Single
OID 1.3.6.1.4.1.2428.90.1.5
Examples norEduPersonNIN: 16090211111
**Usage notes** In some countries, among them Norway, the national identity number is purely numeric. Other countries may include non-numeric characters in the identifier assigned by the official authorities, so string support is needed. **Feide usage notes** The Norwegian “fødselsnummer” is used as NIN. This is assigned by “folkeregisteret” in the local municipality and registered in the central “DSF” (“Det Sentrale Folkeregister”) for all individuals living more than 3 months in Norway. The format is ddmmyynnncc: The first six digits are the date, month and year of birth, the following three act as unique identifier-part including a gender indicator, and the two last digits form a checksum. However, short lived NINs (fake or real) are assigned internally in some systems, and these may indicate both wrong birth date and wrong gender. The institutions assigning NINs are responsible for ensuring uniqueness of NINs within the entire scope where these NINs are visible. The Norwegian Data Inspectorate (“Datatilsynet”) considers the “fødselsnummer” non-sensitive information. This is not in agreement with the views of the general public, to which we make some concessions. Accordingly, the attribute is not to be made available to parties other than those approved by the holder. Applications that need the attribute must log on to the LDAP server acting as the user. This should not be done without the user being informed. The attribute is obtained from the institution’s employee, school or student registries and possibly registries for non-employee affiliated persons. **Example applications for which this attribute would be useful:** All applications in which identification of the person is paramount: BIBSYS, Frida, StudWeb. ### norEduPersonServiceAuthnLevel
Name norEduPersonServiceAuthnLevel
Description Authentication level enforcement policies related to services the subject has access to.
Format DirectoryString
# of values Multiple
OID 1.3.6.1.4.1.2428.90.1.13
Examples norEduPersonServiceAuthnLevel:
urn:mace:feide.no:spid:12345 urn:mace:feide.no:auth:level:fad08:3
norEduPersonServiceAuthnLevel: urn:mace:feide.no:spid:all urn:mace:feide.no:auth:level:fad08:3
**Usage notes** To be used by authentication systems implementing more than one authentication level. This attribute defines the enforcement policies regarding authentication levels that should be applied to the subject. This attribute should be appropriately protected to avoid subjects being able to edit it themselves. No controlled vocabulary, may contain anything. Formatting and contents of this attribute are therefore left to each particular implementation making use of them. See also [norEduPersonAuthnMethod](#noredupersonauthnmethod). **Feide usage notes** The attribute can contain either an uri identifying the service for which a specific authentication level must be performed combined with an uri identifying the authentication level required, or the fixed string `urn:mace:feide.no:spid:all` combined with an uri identifying the authentication level required, indicating that the specific authentication level must be enforced regardless of the service asking for authentication. See also [UH-attributter](../../../reference/schema/info_uh/index.html), [GO-attributter](../../../reference/schema/info_go/index.html). ### norEduPersonAuthnMethod >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
NamenorEduPersonAuthnMethod
DescriptionAuthentication methods that can be used by the subject to enable > multi-factor authentication.
FormatDirectoryString
# of valuesMultiple
OID1.3.6.1.4.1.2428.90.1.14
ExamplesnorEduPersonAuthnMethod:
> urn:mace:wayf.dk:two-factor:method:yubikey 0123456789
> norEduPersonAuthnMethod:
> urn:mace:feide.no:auth:method:sms +4712345678 label=Work%20phone
>
**Usage notes** To be used by authentication systems implementing multiple authentication levels. This attribute defines the list of authentication methods available for the subject that can be used to perform multi-factor authentication, plus the information required for that purpose. Its value should be appropriately protected to avoid subjects being able to edit it themselves. This attribute contains three parts separated by a single space. The first part must contain a method identifier, which takes the form of a URN. Valid identifiers should be univocally linked to a particular implementation of the multi-factor method they refer to. The second part of the attribute contains a string of data whose semantics are specific to the indicated method, with all spaces as well as percent and equal signs being percent encoded according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986). Finally, an optional third part might be available, including parameters separated by single spaces, where the name and the value of each parameter are separated by an equal sign and any spaces, percent or equal signs are also percent encoded. See also [norEduPersonServiceAuthnLevel](#noredupersonserviceauthnlevel). **Feide usage notes** The attribute contains as many values as different authentication methods that can be used to authenticate the subject. Its values consist of the prefix `urn:mace:feide.no:auth:method:` concatenated with an identifier of the method, a method-specific value whose semantics depend on the method itself, and optional parameters also depending on the method. See also [UH-attributter](../../../reference/schema/info_uh/index.html), [GO-attributter](../../../reference/schema/info_go/index.html). ## Attributes from schac ### schacHomeOrganization
Name schacHomeOrganization
Description Specifies a person's home organization using the domain name of the organization.
Format Domain name according to RFC 1035
# of values Single
References RFC 1035 - Domain names - implementation and specification
OID 1.3.6.1.4.1.25178.1.2.9
Examples schacHomeOrganization: uio.no
**Definition** See definition and usage notes in SCHAC 1.5 at [SCHAC releases](https://wiki.refeds.org/display/STAN/SCHAC+Releases). **Feide usage notes** This attribute applies to the person entry. Other organization attributes are found in the organization entry. Attribute value must be the same as the person’s Feide realm in [eduPersonPrincipalName](#eduPersonPrincipalName). ## Attributes from eduPerson Description for eduPerson attributes are, for the most part, direct citation of text in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). Note that some usage restrictions may apply when eduPerson/eduOrg is used with norEdu\*, in particular when used in the Feide federation. Such restrictions are noted following the general Usage notes below. ### eduPersonAffiliation
Name eduPersonAffiliation
Description Specifies the person's relationship(s) to the institution in broad categories such as student, faculty, staff, alum, etc. (See controlled vocabulary).
Format DirectoryString
Permissible values faculty, student, staff, alum, member, affiliate, employee, library walk-in.
# of values Multi
OID 1.3.6.1.4.1.5923.1.1.1.1
Examples eduPersonAffiliation: faculty
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). **Feide usage notes** The following values are used for affiliation: - Student – The person is an active pupil or student. He or she is entitled to a school place or to participate in a study program in which he or she attends courses. All students have the additional value of member. - Faculty – The person is employed with a job code that belongs to the main category ‘Faculty’ (“Vitenskapelig”) (according to Norwegian legislation (“Universitetslovens elector gruppe vitenskapelig tilsatte”)). For primary and secondary education, this value should be used for all educational employees. All faculty has the additional values of employee and member. - Staff – The person is employed with a job code, which does not belong to the main category ‘Faculty’. All staff has the additional values of employee and member. - Employee – The union of ‘Faculty’, ‘Staff’ and other persons on the institution’s payroll. - Alum – Persons that are included in the organization’s alumni arrangements. Affiliation is extracted from information contained in the institution’s employee, school or student registries and access control system (where available). ### eduPersonEntitlement
Name eduPersonEntitlement
Description URI (either URN or URL) that indicates a set of rights to specific resources.
Format DirectoryString
# of values Multi
OID 1.3.6.1.4.1.5923.1.1.1.7
Examples eduPersonEntitlement:
http://example.org/contracts/HEd123
eduPersonEntitlement:
urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn6
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). **Feide usage notes** Trust between parties is established by contractual relationships. The name space [urn:mace:feide.no](urn:mace:feide.no) has been delegated to Feide, see [https://www.feide.no/urn/](https://www.feide.no/urn/). ### eduPersonNickname
Name eduPersonNickname
Description Person's nickname, or the informal name by which they are accustomed to be hailed.
Format DirectoryString
# of values Multi
OID 1.3.6.1.4.1.5923.1.1.1.2
Examples eduPersonNickname: Spike
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). ### eduPersonOrgDN
Name eduPersonOrgDN
Description The distinguished name (DN) of the directory entry representing the institution with which the person is associated.
Format DistinguishedName
# of values Single
OID 1.3.6.1.4.1.5923.1.1.1.3
Examples eduPersonOrgDN: o=Hogwarts, dc=hsww, dc=wiz
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). ### eduPersonOrgUnitDN
Name eduPersonOrgUnitDN
Description The distinguished name(s) (DN) of the directory entries representing the person's Organizational Unit(s).
Format DistinguishedName
# of values Multi
OID 1.3.6.1.4.1.5923.1.1.1.4
Examples eduPersonOrgUnitDN: ou=Potions, o=Hogwarts, dc=hsww, dc=wiz
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). **Feide usage notes** Source is the institution’s employee and student management systems. The attribute may contain a listing of DNs to the locations to which a person has some relation independent of “affiliation”. ### eduPersonPrimaryAffiliation
Name eduPersonPrimaryAffiliation
Description Specifies the person's primary relationship to the institution in broad categories such as student, faculty, staff, alum, etc. (See controlled vocabulary).
Format DirectoryString
Permissible values faculty, student, staff, alum, member, affiliate, employee, library walk-in
# of values Single
OID 1.3.6.1.4.1.5923.1.1.1.5
Examples eduPersonPrimaryAffiliation: student
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). **Feide usage notes** The source is the institution’s employee and student management systems. It is not readily apparent that it will be possible to agree on an algorithm to determine which of a person’s affiliations is the primary affiliation. This raises little or no dangers from a privacy viewpoint. ### eduPersonPrimaryOrgUnitDN
Name eduPersonPrimaryOrgUnitDN
Description The distinguished name (DN) of the directory entry representing the person's primary Organizational Unit.
Format DistinguishedName
# of values Single
OID 1.3.6.1.4.1.5923.1.1.1.8
Examples eduPersonPrimaryOrgUnitDN: ou=Music Department, o=Notre Dame, dc=nd, dc=edu
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). ### eduPersonPrincipalName
Name eduPersonPrincipalName
Description A scoped identifier for a person. It should be represented in the form "user@scope" where 'user' is a name-based identifier for the person and where the "scope" portion MUST be the administrative domain of the identity system where the identifier was created and assigned.

Each value of 'scope' defines a namespace within which the assigned identifiers MUST be unique. Given this rule, if two eduPersonPrincipalName (ePPN) values are the same at a given point in time, they refer to the same person. There must be one and only one "@" sign in valid values of eduPersonPrincipalName.
Format DirectoryString
# of values Single
OID 1.3.6.1.4.1.5923.1.1.1.6
Examples eduPersonPrincipalName: hputter@hsww.wiz
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). **Feide usage notes** An eduPersonPrincipalName should never be reassigned to another person; lifelong learning must be kept in mind. The organization assigning principal names must ensure uniqueness among active values. If the organization chooses to reassign a principal name, which is not in active use, it is responsible for doing this in a way that will not cause problems. E.g. it should be considered that when a principal name has been exposed externally, it might have been used as a database primary key by others. A person may be assigned a new principal name. It is worth noting that this id, being related to the national identity number (NIN), ought to have the same confidentiality as the NIN. This should be taken into consideration, however, eduPersonPrincipalName has to be accessible to applications that want to grant a person certain rights connected to the person. The values to the right of the “@” sign should be a dotted string which is the Feide realm of the organization with which the user is affiliated. The value to the left of the “@” sign should be identical to the “[uid](#uid)” value. By definition eduPersonPrincipalName is not case sensitive. Because of differences in LDAP implementations, it is still recommended to use only lower case letters in this attribute. ### eduPersonPrincipalNamePrior
Name eduPersonPrincipalNamePrior
Description Each value of this multivalued attribute represents an ePPN (eduPersonPrincipalName) value that was previously associated with the entry. The values MUST NOT include the currently valid ePPN value. There is no implied or assumed order to the values.

This attribute MUST NOT be populated if ePPN values are ever reassigned to a different entry (after, for example, a period of dormancy). That is, they MUST be unique in space and over time.
Format DirectoryString
# of values Multi
OID 1.3.6.1.4.1.5923.1.1.1.12
Examples eduPersonPrincipalName: baz@hsww.wiz
eduPersonPrincipalNamePrior: foo@hsww.wiz
eduPersonPrincipalNamePrior: bar@hsww.wiz
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). **Feide usage notes** All values in eduPersonPrincipalNamePrior must have been owned by the same legal organization as the current eduPersonPrincipalName. In essence, it must only contain principal names with the - realm of the organization - realm used previously by the organization - realms of merged organizations For security reasons principal names from other organizations are not permitted. It is the responsibility of the host organization to ensure no information is added to this field enabling users at their organization to impersonate other persons at their own or other organizations. ### eduPersonScopedAffiliation
Name eduPersonScopedAffiliation
Description Specifies the person's affiliation within a particular security domain in broad categories such as student, faculty, staff, alum, etc.
Format DirectoryString
Permissible values See controlled vocabulary for eduPersonAffiliation; only these values are allowed to the left of the @ sign.
# of values Multi
OID 1.3.6.1.4.1.5923.1.1.1.9
Examples eduPersonScopedAffiliation: member@uninett.no
eduPersonScopedAffiliation: employee@112233.ntnu.no
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). **Feide usage notes** The values to the right of the “@” should either be the realm part of the user’s [eduPersonPrincipalName](#edupersonprincipalname), or this value prefixed with the [norEduOrgUnitUniqueIdentifier](#noreduorgunituniqueidentifier) to which the affiliation applies, separated by a full stop. The second example above illustrates the use of a norEduOrgUnitUniqueIdentifier part for a Feide user at ntnu.no who is an employee in the unit with the (locally) unique identifier 112233. ### eduPersonTargetedID
Name eduPersonTargetedID
Description A persistent, non-reassigned, opaque identifier for a principal.
Format DirectoryString
# of values Multi
OID 1.3.6.1.4.1.5923.1.1.1.10
Examples eduPersonTargetedID: 24d66f51ac1c0b140e617af335b9abb4b8d88a5b
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). **Feide usage notes** This attribute is defined for use with Shibboleth, but may be used in other contexts as well. Note that **the attribute is not stored in the LDAPs of host organizations**, but in the login service. ### eduPersonAssurance
Name eduPersonAssurance
Description Set of URIs that asserts compliance with specific standards for identity assurance.
Format DirectoryString
# of values Multi
OID 1.3.6.1.4.1.5923.1.1.1.11
Examples eduPersonAssurance: urn:mace:incommon:IAQ:sample
eduPersonAssurance: http://idm.example.org/LOA#sample
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). ### eduPersonUniqueId
Name eduPersonUniqueId
Description A long-lived, non re-assignable, omnidirectional identifier suitable for use as a principal identifier by authentication providers or as a unique external key by applications.
Format DirectoryString
# of values Single
OID 1.3.6.1.4.1.5923.1.1.1.13
Examples eduPersonUniqueId: 28c5353b8bb34984a8bd4169ba94c606@foo.edu
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). **Feide usage notes** This attribute is only used for special purposes right now, but will be added to the next schema version. For more information about the identifier, see [Person and account identifiers in Feide](../identifiers/index.html.md) ### eduPersonOrcid
Name eduPersonOrcid
Description ORCID iDs are persistent digital identifiers for individual researchers. Their primary purpose is to unambiguously and definitively link them with their scholarly work products. ORCID iDs are assigned, managed and maintained by the ORCID organization.
Format DirectoryString
# of values Multi
OID 1.3.6.1.4.1.5923.1.1.1.16
Examples eduPersonOrcid: https://orcid.org/0000-0002-1825-0097
**Definition** See definition, notes and examples in [eduPerson](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html). ## Attributes from eduOrg The attributes in the following section are copied from eduOrg with minor compatibility changes. Description and Usage notes for eduOrg attributes are, for the most part, direct citation of text in [eduOrg](https://spaces.at.internet2.edu/download/attachments/110336044/00003-EduOrgObjectClassSpecification200210.pdf). Rather than rewriting the text to incorporate norEdu\*/Feide considerations, separate norEdu\*/Feide usage notes have been added as separate paragraphs. There may be some stylistic differences between the eduPerson and norEdu\* descriptions. ### eduOrgHomePageURI
Name eduOrgHomePageURI
Description The URL for the organization's top level home page.
Format DirectoryString
# of values Multi
OID 1.3.6.1.4.1.5923.1.2.1.2
Examples eduOrgHomePageURI: https://www.uio.edu
**Definition** See definition, notes and examples in [eduOrg](https://spaces.at.internet2.edu/download/attachments/110336044/00003-EduOrgObjectClassSpecification200210.pdf). ### eduOrgIdentityAuthNPolicyURI
Name eduOrgIdentityAuthNPolicyURI
Description A URI pointing to the location of the organization's policy regarding identification and authentication (the issuance and use of digital credentials). Most often a URL, but with appropriate resolution mechanisms in place, could be a URN.
Format DirectoryString
# of values Multi
OID 1.3.6.1.4.1.5923.1.2.1.3
Examples eduOrgIdentficationAuthNPolicyURI: http://www.uchicago.edu/security/IA-Policy.html
**Definition** See definition, notes and examples in [eduOrg](https://spaces.at.internet2.edu/download/attachments/110336044/00003-EduOrgObjectClassSpecification200210.pdf). ### eduOrgLegalName
Name eduOrgLegalName
Description The organization's legal corporate name.
Format DirectoryString
# of values Multi
OID 1.3.6.1.4.1.5923.1.2.1.4
Examples eduOrgLegalName: Georgia Institute of Technology
**Definition** See definition, notes and examples in [eduOrg](https://spaces.at.internet2.edu/download/attachments/110336044/00003-EduOrgObjectClassSpecification200210.pdf). ### eduOrgWhitePagesURI
Name eduOrgWhitePagesURI
Description The URL of the open white pages directory service for the university, predominantly LDAP these days.
Format DirectoryString
# of values Multi
OID 1.3.6.1.4.1.5923.1.2.1.6
Examples eduOrgWhitePagesURI: ldap://wpage1.uwrf.edu
**Definition** See definition, notes and examples in [eduOrg](https://spaces.at.internet2.edu/download/attachments/110336044/00003-EduOrgObjectClassSpecification200210.pdf). ## Common attributes The attributes in the following section are from other standard object classes or attribute definitions; most of them originated in the X.520 recommendation, later adopted by [RFC 4519](https://datatracker.ietf.org/doc/html/rfc4519), or from the [RFC 4524](https://datatracker.ietf.org/doc/html/rfc4524)-schema. This specification does not include descriptions of all [RFC 4519](https://datatracker.ietf.org/doc/html/rfc4519) or [RFC 4524](https://datatracker.ietf.org/doc/html/rfc4524)-attributes, but in any case where the eduPerson working group or norEdu\* editors considered that some comment was needed to clarify the meaning or utility of an attribute, it can be found here. For details on the syntax and other aspects of these attributes, see the appropriate standards documents. Note that for several attributes adopted from X.520, the attribute syntax is described using the same name as in X.520, but the formal [RFC 4519](https://datatracker.ietf.org/doc/html/rfc4519) grammar specifies an OID defined by [RFC 4517](https://datatracker.ietf.org/doc/html/rfc4517). In most cases, this will be of minor concern except possibly if schema definitions are ported between X.500 (DAP) and LDAP directories, if the software involved makes consistency checks based on OIDs. ### cn
Name Cn
Description Common name.
Format DirectoryString
# of values Multi
References X.520, RFC 4519
OID 2.5.4.3
Examples cn: Universitetet i Oslo
cn: Universitas Osloensis
cn: University of Oslo
cn: UiO
cn: Walter Martin Tveter
cn: Walter M. Tveter
cn: Walter Tveter
**Usage notes** The ‘cn’ (‘commonName’ in X.500) attribute type contains names of an object. Each name is one value of this multivalued attribute. If the object corresponds to a person, it is typically the person’s full name Organization: All the names that identify the institution, including acronyms. Person: Full name as obtained from the employee or student management system. May contain variants of the person’s name. Required. One of the two required attributes in the person object class (the other is [sn](#sn)). As such it is one of three recommended “core application utility” attributes. The third is [eduPersonOrgDN](#edupersonorgdn). With eduPersonOrgDN and cn, the client knows the person’s name and the distinguished name of the organization with which he/she is associated. The latter could help them find a directory entry for the person’s organization. **Feide usage notes** This attribute will not be a problem as long as the person does not have special needs for anonymity. In such cases all name related attributes must be protected or pseudonyms used. **Example applications for which this attribute would be useful:** All. ### dc
Name Dc
Description A string holding one component, a label, of a DNS domain name naming a host.
Format IA5 String
# of values Single
References RFC 4519, RFC 1123, RFC 2181
OID 2.16.840.1.113730.3.1.241
Examples dc: uninett
**Usage notes** Valid values include “example” and “com” but not “example.com”. The latter is invalid as it contains multiple domain components. It is noted that the directory service will not ensure that values of this attribute conform to the host label restrictions. It is the client’s responsibility to ensure that the labels it stores this attribute are appropriately restricted. Directory applications supporting International Domain Names SHALL use the ToASCII method [RFC 3490](https://datatracker.ietf.org/doc/html/rfc3490) to produce the domain component label. The special considerations discussed in Section 4 of [RFC 3490](https://datatracker.ietf.org/doc/html/rfc3490) should be taken, depending on whether the domain component is used for “stored” or “query” purposes. **Example applications for which this attribute would be useful:** Directory of directories, white pages, email client. ### displayName
Name displayName
Description The name(s) that should appear in white-pages-like applications for this person; preferred name of a person to be used when displaying entries.
Format DirectoryString
# of values Single
References RFC 2798
OID 2.16.840.1.113730.3.1.241
Examples displayName: Jack Dougherty
displayName: Walter Tveter
**Usage notes** Since other attribute types such as [cn (commonName)](#cn) are multivalued, displayName is a better candidate for use in white pages and configurable email clients. If the institution’s employee and student management systems support this, the attribute may be used. **Example applications for which this attribute would be useful:** Directory of directories, white pages, email client. ### facsimileTelephoneNumber
Name facsimileTelephoneNumber
Description A fax number for the directory entry. Attribute values should comply with the ITU Recommendation E.123 [E.123]: i.e., +44 71 123 4567.
Format FacsimileTelephoneNumber
# of values Multi
References RFC 4519
OID 2.5.4.23
Examples facsimileTelephoneNumber: +47 73557901
**Usage notes** According to [RFC 4519](https://datatracker.ietf.org/doc/html/rfc4519): “The ‘facsimileTelephoneNumber’ attribute type contains telephone numbers (and, optionally, the parameters) for facsimile terminals. Each telephone number is one value of this multivalued attribute. Normally used for employees only, where the value is stored in the employee payroll system. **Example applications for which this attribute would be useful:** Directory of directories, white pages. ### givenName
Name givenName
Description Contains name strings that are the part of a person's name that is not their surname.
Format DirectoryString
# of values Multi
References RFC 4519
OID 2.5.4.42
Examples givenName: Walter Martin
givenName: Walter
**Usage notes** The given name of the person, obtained from the employee management system or the student registry. The attribute may have multiple values. If it does have multiple values they represent the alternative renderings of the given name. **Feide usage** All questions regarding the use of given names, middle names and surnames, are to be referred to the Norwegian naming legislation [navneloven](https://lovdata.no/dokument/NL/lov/2002-06-07-19). ### homePhone
Name homePhone
Description A home telephone number associated with a person. Attribute values should comply with the ITU Recommendation E.123 [E.123]: i.e., +44 71 123 4567.
Format TelephoneNumber
# of values Multi
References RFC 2798, RFC 4524
OID 0.9.2342.19200300.100.1.20
Examples homePhone: +47 23456789
**Usage notes** The home phone number is not really different from the office phone number, in as much as it is not listed with a (home) address. If this is the case then it will reveal a personal (and unprotected) location where one can reach such individuals. Therefore such telephone numbers should probably be listed only with the billing address - that of the university. **Feide usage notes** The value is obtained form the institution’s employee management system. It should be used only when the institution pays for the telephone subscription or the telephone is used for purposes related to the person’s employment. **Example applications for which this attribute would be useful:** Directory of directories, white pages. ### homePostalAddress
Name homePostalAddress
Description A home postal address for an object.
Format PostalAddress
# of values Multi
References RFC 4524
OID 0.9.2342.19200300.100.1.39
Examples homePostalAddress: 1212 Como Ave. $ Midton, SD 45621
**Usage notes** eduPerson has a PostalAddress that complements this attribute. homePostalAddress should only be used by institutions that know this is needed. The PostalAddress syntax [RFC 4517](https://datatracker.ietf.org/doc/html/rfc4517) allows the value to be a list of strings, separated by dollar signs. Each element in the list is usually interpreted as one address line. A dollar sign or backslash, which is part of the proper address string, must be escaped using backslash as an escape character (“\\”, “$”). **Example applications for which this attribute would be useful:** Directory of directories, white pages. ### jpegPhoto
Name jpegPhoto
Description An image of a person using the JPEG File Interchange Format [JFIF].
Format jpegPhoto
# of values Multi
References RFC 2798
OID 0.9.2342.19200300.100.1.60
Examples (Attribute value is in binary format)
**Usage notes** A smallish photo in jpeg format. **Example applications for which this attribute would be useful:** Student cards, physical entrance cards, white pages. ### l (localityName)
Name L
Description The name of a locality, such as a city, county or other geographic region (localityName).
Format DirectoryString
# of values Multi
References X.520, RFC 4519
OID 2.5.4.7
Examples l: Oslo
**Usage notes** When used as a component of a directory name, the locality name identifies a geographical area or locality in which the named object is physically located or with which it is associated in some other important way. If used, it should hold names of locations to which the person is affiliated. For institutions with more than one campus this is relevant. Location names as used by the postal service. The source of this attribute should be the employee or student management systems, and maintaining consistency with the localization used in each organization is a goal. **Example applications for which this attribute would be useful:** Directory of directories, white pages. ### labeledURI
Name labeledURI
Description Uniform Resource Identifier with optional label.
Format CaseExactString
# of values Multi
References RFC 2079
OID 1.3.6.1.4.1.250.1.57
Examples labeledURI: ftp://ds.internic.net/rfc/rfc822.txt
labeledURI: http://www.umich.edu/%7Ersug/ldap/ LDAP Home Page
labeledURI: http://champagne.inria.fr/Unites/rennes.gif Rennes [photo]
**Usage notes** Commonly a URL for a web site associated with this person or entity. The vocabulary for the label portion of the value is not standardized. For persons this is typically a private home page, or at least a privately maintained home page, as opposed to an institution-maintained page or a page representing an institution. As such it will probably be voluntary to have one, and even if this is not so it will probably be up to each individual to decide its content. This does not represent any special problems in a privacy perspective as long as the individuals who have home pages are made aware that their URLs are listed. **Examples of labeledURI Attribute Values:** The first example is of a labeledURI attribute value that does not include a label The second example is of a labeledURI attribute value that contains a tilde character in the URL (special characters in a URL must be encoded). The label is “LDAP Home Page” The third example includes a hint in the label to help the user realize that the URL points to a photo image. The label is “Rennes [photo]”. **Example applications for which this attribute would be useful:** Directory of directories, local search engines, white pages. ### mail
Name Mail
Description The 'mail' (rfc822mailbox) attribute type holds Internet mail addresses in Mailbox [RFC2821] form (e.g., user@example.com).
Format IA5 String
# of values Multi
References RFC 4524
OID 0.9.2342.19200300.100.1.3
Examples mail: sophus.lie@student.hia.no
**Usage notes** Preferred address for the “to:” field of email to be sent to this person or entity. Usually of the form [firstname.lastname@univ.domain](mailto:firstname.lastname@univ.domain). Though multivalued, there is often only one value. Some mail clients will not display entries unless the mail attribute is populated. See the [LDAP Recipe](https://spaces.at.internet2.edu/download/attachments/110336095/ldap-recipe.htm) for further guidance on email addresses, routing, etc. **Feide usage notes** Personal email address for a person. Obtained from the organization’s email system or another authoritative source. Some services treat the attribute [eduPersonPrincipalName](#edupersonprincipalname) as email addresses. While they are not supposed to handle them as such, some services send notifications, invitations to resources, and other information to these “addresses”. If the users’ email address differ from the users’ eduPersonPrincipalName the host organization should consider adding the values in eduPersonPrincipalName as aliases for the users’ real email address in the email system. Depending on how visible the organization wants these aliases to be, they could also add the alias to this mail attribute in Feide if they wish. There is a rising problem with spam/UCE and other unwanted incoming email communication. In the educational institutions (at least in Norway), one has not made any clear decisions as to who owns e-mail addresses and if the users whose name they point to can use them for personal use. If one chooses to view an e-mail address, as a resource that the institution owns, then the listing of it, and the risks that follow with this - unwanted incoming communications, is more of an efficiency problem for the institution than an infringement of the users personal sphere. One could say this is more of a mixed situation in as much as any communication that is aimed at the individual as a private person and not as a representative of an institution is as much an infringement of this individual’s personal sphere as if he or she owned this e-mail address themselves. This argument however, is not valid for an institutions ability to prescribe that its employees (or students) should have accessible e-mail addresses. It is valid towards the senders of the unwanted communications in questions about whether or not one can bring charge against them as individuals, consumers etc. **Example applications for which this attribute would be useful:** Directory of directories, white pages, email client. ### manager
Name Manager
Description The manager of an object represented by an entry.
Format DistinguishedName
# of values Multi
References RFC 4524
OID 0.9.2342.19200300.100.1.10
Examples manager: uid=twilliams,ou=people,dc=hobart,dc=edu
**Usage notes** This attribute carries the DN of the manager of the person represented in this entry. For employees only. Taken from the employee management systems if used at all. Restricted to the person that is the immediate manager for the employee’s job position. **Example applications for which this attribute would be useful:** Directory of directories, white pages. ### mobile
Name Mobile
Description A mobile telephone number associated with a person. Attribute values should comply with the ITU Recommendation E.123 [E.123]: i.e., +44 71 123 4567.
Format TelephoneNumber
# of values Multi
References RFC 4524
OID 0.9.2342.19200300.100.1.41
Examples mobile: +47 40404040
**Feide usage notes** The value in mobile should not be used for one-time passwords without a thorough risk assessment. The value is often self serviced by the end user and if the user account is compromised it can be used for privilege escalation. Feide’s functionality for strong authentication does not use this attribute. **Example applications for which this attribute would be useful.** Directory of directories, white pages. ### o
Name O
Description Standard name of the top-level organization (institution) with which this person is associated.
Format DirectoryString
# of values Multi
References RFC 4519
OID 2.5.4.10
Examples o: St. Cloud State
**Usage notes** Meant to carry the TOP-LEVEL organization name. Do not use this attribute to carry names of organizational sub-units. The o attribute may list all the names of the institution, including the one found in eduOrgLegalName. Each name is one value of this multivalued attribute. **Example applications for which this attribute would be useful:** Directory of directories, white pages. ### ou
Name Ou
Description The names of an organizational unit name.
Format DirectoryString
# of values Multi
References RFC 4519
OID 2.5.4.11
Examples ou: Faculty Senate
**Usage notes** When used as a component of a directory name it identifies an organizational unit with which the named object is affiliated. The designated organizational unit is understood to be part of an organization designated by an OrganizationName [o] attribute. It follows that if an Organizational Unit Name attribute is used in a directory name, it must be associated with an OrganizationName [o] attribute. An attribute value for Organizational Unit Name is a string chosen by the organization of which it is a part. Administratively determined. Located in the employee and student directories. **Example applications for which this attribute would be useful:** Directory of directories, white pages, learning management systems. ### postalAddress
Name postalAddress
Description Campus or office address, specifying the address information required for the physical postal delivery to an object.
Format PostalAddress
# of values Multi
References X.520, RFC 4519
OID 2.5.4.16
Examples postalAddress: P.O. Box 333 $ Whoville, WH 99999
**Usage notes** The PostalAddress syntax [RFC 4517](https://datatracker.ietf.org/doc/html/rfc4517) allows the value to be a list of strings, separated by dollar signs. Each element in the list is usually interpreted as one address line. A dollar sign or backslash, which is part of the proper address string, must be escaped using backslash as an escape character (“\\”, “$”). The postalAddress is, with exception for individuals with a qualified requirement for anonymity, not considered a problematic piece of personal information. **Feide usage notes** Not assigned for students. Contains both mailbox address and postal number, even if these are separate attributes. Taken from the employee management system. **Example applications for which this attribute would be useful:** Directory of directories, white pages. ### postalCode
Name postalCode
Description Codes used by a Postal Service to identify postal service zones.
Format DirectoryString
# of values Multi
References X.520, RFC 4519
OID 2.5.4.17
Examples postalCode: NO-7465
**Usage notes** ZIP code in USA, postal code for other countries. If not prefaced by country code, assume local. If this attribute value is present, it will be part of the object’s postal address. Regarded as unproblematic in a privacy perspective. **Feide usage notes** Campus postal code is taken from the employee management system. **Example applications for which this attribute would be useful:** Directory of directories, white pages. ### postOfficeBox
Name postOfficeBox
Description The Postal Office Box by which the object will receive physical postal delivery.
Format DirectoryString
# of values Multi
References X.520, RFC 4519
OID 2.5.4.18
Examples postOfficeBox: 109260
**Usage notes** Each postal box identifier is a single value of this multivalued attribute. If present, the attribute value is part of the object’s postal address. Regarded as unproblematic in a privacy perspective. **Feide usage notes** postOfficeBox attributes are campus address taken from the employee management system. **Example applications for which this attribute would be useful:** Directory of directories, white pages. ### preferredLanguage
Name preferredLanguage
Description Preferred written or spoken language for a person.
Format ISO 639
# of values Single
References RFC 2798, BCP 47
OID 2.16.840.1.113730.3.1.39
Examples preferredLanguage: nn
**Usage notes** In a privacy perspective, language preference may in certain contexts be sensitive information: Any value other than the national language or English may possibly indicate the registered individuals ethnic origin. A given language preference may lead to an assumption of the individual’s specific ethnic origin, or may indicate a non-specific, but non-native origin. It should therefore be held as confidential as possible without removing its practical use. **Feide usage notes** The attribute originates in student registry system. Attribute values must conform to [BCP 47](https://datatracker.ietf.org/doc/html/bcp47). The values will typically be a two or three letter “Primary Language Subtag”; only rarely will it be followed by any other subtags. The list of allowed primary language subtags is available in the [IANA Language Subtag Registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Typical values are: nn (Norwegian Nynorsk), nb (Norwegian Bokmål), no (Norwegian), en (English), se (Northern Sami), sma (Southern Sami) or smj (Lule Sami) If languages that indicate ethnicity are used, requirements for confidentiality rise to high. **Example applications for which this attribute would be useful:** Presentation of web pages in correct language, directory of directories, white pages. ### sn
Name Sn
Description Surname or family name.
Format DirectoryString
# of values Multi
References X.520, RFC 4519
OID 2.5.4.4
Examples sn: Carson-Smith
sn: Carson
sn: Smith
**Usage notes** In X.520, this attribute is called surname. Required. One of the two required attributes in the person object class from which eduPerson derives (the other is [cn](#cn)). As such it is one of eduPerson’s three “core application utility” attributes. The third is [eduPersonOrgDN](#edupersonorgdn). If the person has a multi-part surname (whether hyphenated or not), store both 1) the whole surname including hyphens if present and 2) each component of a hyphenated surname as a separate value in this multivalued attribute. That yields the best results for the broadest range of clients doing name searches. Beware of applications sorting persons by sn-cn, they may need access controls added to protect them from multivalued surnames. **Feide usage notes** Source is a student registry or human resource system. All questions regarding the use of given names, middle names and surnames, are to be referred to the Norwegian naming legislation [navneloven](https://lovdata.no/dokument/NL/lov/2002-06-07-19). **Example applications for which this attribute would be useful:** All. ### street
Name Street
Description The physical address of the object to which the entry corresponds, such as an address for package delivery.
Format DirectoryString
# of values Multi
References X.520, RFC 4519
OID 2.5.4.9
Examples street: 303 Mulberry St.
**Usage notes** The ‘street’ (‘streetAddress’ in X.500) attribute type contains site information from a postal address (i.e., the street name, place, avenue, and the house number). Each street is one value of this multivalued attribute. As long as the individual that the information relates to does not have any special need for anonymity, then this information is not problematic from a privacy point of view. **Feide usage notes** Sources are student registry or employee payroll system. **Example applications for which this attribute would be useful:** Directory of directories, white pages, door locks. ### telephoneNumber
Name telephoneNumber
Description Office/campus phone number. Attribute values should comply with the ITU Recommendation E.123 [E.123]: i.e., +44 71 123 4567.
Format TelephoneNumber
# of values Multi
References X.520, RFC 4519
OID 2.5.4.20
Examples telephoneNumber: +47 73593000
**Usage notes** Telephone number confidentiality is not a problem in itself. If someone has a special need to be anonymous, then it will have to be possible to hide this. In addition one should be aware that if the phone number is listed with an address in a phone directory, then the number will have to be treated at lest as carefully as the address that is listed. **Feide usage notes** Sources are employee payroll system or PABX or switchboard. **Example applications for which this attribute would be useful:** Directory of directories, white pages. ### title
Name Title
Description The title of a person in their organizational context. Each title is one value of this multivalued attribute.
Format DirectoryString
# of values Multi
References X.520, RFC 4519
OID 2.5.4.12
Examples title: Assistant Vice-Deputy for Redundancy Reduction
**Usage notes** No controlled vocabulary, may contain anything. Student is not considered a title. Both academic titles and functions are covered in this attribute. **Feide usage notes** Source is an employee payroll system or student registry. To encode employee category (“stillingskode”), the [eduPersonEntitlement](#edupersonentitlement) attribute is preferred over the title attribute, to ensure that unambiguous codes (represented by registered URNs) are used. Note that URNs registered by Feide currently does not include employee categories, but organizations owning a URN namespace may define their own values if needed. **Example applications for which this attribute would be useful:** Directory of directories, white pages. ### uid
Name Uid
Description A computer system login name associated with the object.
Format DirectoryString
# of values Multi
References RFC 4519
OID 0.9.2342.19200300.100.1.1
Examples uid: gmettes
**Usage notes** A uid must be restricted to ASCII excluding space; avoiding punctuation is recommended. A common (stronger) restriction is a maximum length of 8 letters, restricted to [a-z, 0-9, -] must start with a letter. Likely only one value. See the extensive discussion in the “[LDAP Recipe](https://spaces.at.internet2.edu/download/attachments/110336095/ldap-recipe.htm)”. A number of off-the-shelf directory-enabled applications make use of this inetOrgPerson attribute, not always consistently. A uid in itself is just an identifier. If mapping from uid to other identifications, such as the NIN, can be done by others, then the uid will require the same level of confidentiality as the NIN. This attribute is reused in [eduPersonPrincipalName](#edupersonprincipalname) and the restrictions on reallocation defined for eduPersonPrincipalName apply. **Feide usage notes** Source is user management system or another authoritative system. A person should have a single uid per organization. Notice that uid is not case sensitive. uid should be used as the first part of eduPersonPrincipalName (before “@”), hence only lower case letters is to be used in uid. See also eduPersonPrincipalName. **Example applications for which this attribute would be useful:** Controlling access to resources. ### userCertificate
Name userCertificate
Description A user's X.509 certificate.
Format Certificate
# of values Multi
References RFC 4523
OID 62.5.4.36
Examples
**Usage notes** [RFC 4523](https://datatracker.ietf.org/doc/html/rfc4523) states that this attribute is to be requested and transferred using the attribute description ‘userCertificate;binary.’ Incompatible implementations exist, see the IETF PKI work for details. Note that userSMIMECertificate is in binary syntax (1.3.6.1.4.1.1466.115.121.1.5) whereas the userCertificate attribute is in certificate syntax (1.3.6.1.4.1.1466.115.121.1.8). The confidentiality of a certificate in itself is not problematic, depending on what information one chooses to include in the certificate. It is probable that the information included will be a combination of different fields of information described in this document. The certificate will then be an accumulation of all the different fields’ combined features. Assigned by a CA (Certificate Authority). Each CA has a contract with the higher education institution. The userCertificate attribute was defined in RFC 2256, but was moved to [RFC 4523](https://datatracker.ietf.org/doc/html/rfc4523). **Example applications for which this attribute would be useful:** Email clients, controlling access to resources, validation of electronic signatures. ### userPassword
Name userPassword
Description The entry's password and encryption method in the following format: {encryption method}encrypted password.
Format OctetString
# of values Multi
References RFC 4519
OID 2.5.4.35
Examples {CRYPT}$6$ufxrIZTs$hl3ocEOAb01o3HC1yk1DUTD6aaHnH7xD5ZDFCH9xnoNUWZky6lt0/
**Usage notes** The server must support the LDAP Simple Bind method over TLS (Transport Layer Security). Applications that use LDAP Bind methods that transmit plain text passwords, such as Simple Bind, must use TLS or SSL (Secure Sockets Layer) to protect the password. The person entries must be associated with a password, so that people can bind to the server. Servers may support various ways to achieve this. Typically the person entry will contain an attribute like userPassword. Even if the password stored in this attribute is hashed, the attribute should be protected by access controls so that nobody can read the attribute and it only can be used to authenticate. Preferably, Bind methods that transmit plain text passwords should also be disabled when TLS or SSL is not established on the connection, in order to teach users not to send plain text passwords. **Feide usage notes** Source is user management system or another authoritative system. All passwords must be hashed/encrypted using a strong encryption method to make it unreadable to an intruder. See [RFC 2307](https://datatracker.ietf.org/doc/html/rfc2307) for format information. It is recommended that passwords consist of a combination of upper and lowercase letters, digits and punctuation, have a length of at least 8 characters, and are not a word that can be found in an ordinary dictionary. For legacy reasons, national letters, such as æøå, should be avoided as they may cause interoperability problems with systems and browsers that do not support international character sets. **Example applications for which this attribute would be useful:** Controlling access to resources. ### userSMIMECertificate
Name userSMIMECertificate
Description An X.509 certificate specifically for use in S/MIME applications (see RFCs 2632, 2633 and 2634).
Format Binary
# of values Multi
References RFC 2798
OID 2.16.840.1.113730.3.1.40
Examples
**Usage notes** According to [RFC 2798](https://datatracker.ietf.org/doc/html/rfc2798), “If available, this attribute is preferred over the userCertificate attribute for S/MIME applications.” See also [RFC 2632](https://datatracker.ietf.org/doc/html/rfc2632), [RFC 2633](https://datatracker.ietf.org/doc/html/rfc2633) and [RFC 2634](https://datatracker.ietf.org/doc/html/rfc2634). [RFC 2798](https://datatracker.ietf.org/doc/html/rfc2798) states that this attribute is to be stored and requested in the binary form, as ‘userSMIMECertificate;binary.’ Semantic follow userSMIMECertificate in [RFC 2798](https://datatracker.ietf.org/doc/html/rfc2798), “A PKCS#7 [RFC 2315] SignedData.” # Document information This chapter is informative only, and does not form part of the norEdu\* specification. ## Acknowledgments Editing team: Ingrid Melve, Jon Strømme, Bård Henry Moum Jakobsen, Anders Lund, Walter Tveter, Ketil Albertsen, Snorre Løvås, Annette Grande, Hildegunn Vada and Jaime Pérez. Contact address is [kontakt@sikt.no](mailto:kontakt@sikt.no) Thanks to Keith Hazelton and Internet2/NMI for allowing us to reuse the eduPerson and eduOrg documentation. Without your example and your kind help, this document would have been much harder to write. Thanks to Peter Green for giving access to auEduPerson and answering questions. Thanks to the SWITCH AAI team for publishing switchEduPerson and documenting choices made. Thanks to the GNOMIS community for feedback and support. Discussions on funetEduPerson attributes proved helpful. Among other persons who provided valuable help and feedback are Steinar Hamre, Hallvard Furuseth, Per-Steinar Iversen and Tor Gjerde. ## Change log ### From version 1.0 to 1.1 - Changed OIDs for the Feide attributes that are not inherited from eduPerson or eduOrg. - Changed names of Feide attributes (norEduPersonBirthDate, norEduPersonNIN, norEduPersonLIN, norEduOrgAcronym, norEduOrgUniqueNumber, norEduOrgUnitUniqueNumber). - Changed norEduPersonNIN type from Integer to DirectoryString - Changed givenName to MANDATORY, due to popular demand. - Indexing information for eduOrg200210 updated and changed as result of testing - Changed matching rules from caseExactIA5Match to caseExactMatch ### From version 1.1 to 1.2 - Changed givenName back to OPTIONAL, after discussions with service providers - userSMIMECertificate and userCertificate both have the same confidentiality level of medium - Fixed typos and removed warning about beta ### From version 1.2 to 1.3 - Changed object classes to Auxiliary to minimize interoperability problems. - Removed all unused attributes from the document - Feide realm specification, added feideSchema for versioning information of AT - Restrictions on Feide name (eduPersonPrincipalName) changed to prevent reuse - Added definitions for jpegPhoto, mobile, eduPersonEntitlement, eduPersonScopedAffiliation - Changed data type from Integer to NumericString for norEduPersonBirthDate and norEduPersonNIN - norEduPersonLIN is defined to include all scoped identifiers. The attribute must be parsed to separate the issuer from the value of the identifier. - labeledURI may be part of norEduOrg, duplicates eduOrgHomePageURI and eduOrgWhitePageURI - Added norEduOrgUniqueIdentifier (replaces norEduOrgUniqueNumber) and norEduOrgUnitUniqueIdentifier (replaces norEduOrgUnitUniqueNumber), and moved the two deprecated attributes to a new object class norEduObsolete - Added federationFeideSchemaVersion attribute in the new object class federationFeideSchema ### From version 1.3 to 1.4 **Schema related changes:** - norEdu\* objects now has no MUST attributes. In the Norwegian Feide federation, a number of attributes are defined as mandatory, as a federation defined restriction on use of the schema. - Added attributes norEduOrgNIN and norEduOrgSchemaVersion. - User password encryption method is no longer required to be MD5. However, a strong encryption method should be used. - Included description of schac attributes schacHomeOrganization and schacUserPrivateAttribute, eduPerson attributes eduPersonNickname and eduPersonTargetedID, and common attribute dc. - Obsoleted attribute federationFeideSchemaVersion and object class feideFederationSchema in favor of norEduOrgSchemaVersion, norEduOrgUniqueNumber in favor of norEduOrgUniqueIdentifier and norEduOrguUnitUniqueNumber in favor of norEduOrgUnitUniqueIdentifier. - The norEdu\* grammar definitions in Appendix A and B is cleaned up and is now formally correct. **Editorial changes:** - Removed search type info from individual attribute description. This information is found in the formal grammar in the appendix. - References to eduPerson updated to include reference to 2004 version. Several citations of eduPerson descriptions updated to the 2004 version of eduPerson. All eduPerson attributes are now incorporated into the norEdu\* description. - Moved obsolete attributes to appendix. - Complete rewrite of introductory chapters, format of attribute descriptions etc. norEdu attributes are now described in alphabetical order (similar to schac and eduPerson/eduOrg schema descriptions). For the electronic document version, the majority of external references have been made clickable links (where such have been found). - Added index of attributes, with clickable (intra document) links to the description and grammar. - References to RFC 2251 to 2256 updated to refer to the revised LDAP RFCs 4510 to 4519. **Feide specific changes:** - Changed Feide relevance from Mandatory to Optional for the ou attribute. - Added definition of Feide [urn:mace:feide.no:value-def:foresatt](urn:mace:feide.no:value-def:foresatt) for use in eduPersonEntitlement. - In Feide, norEduOrgNIN (the “foretaksnummer”, assigned by Brønnøysundregistrene) replaces norEduOrgUniqueIdentifier (assigned by SO) as a mandatory attribute. ### From version 1.4 to 1.4.1 - In the norEduOrg and norEduOrgUnit object classes, those common attributes which are neither specified in the MAY parts of the eduOrg/eduOrgUnit classes nor the X.521 organization object class. The affected attributes are,norEduOrg: dc, mail, labeledURInorEduOrgUnit: cn, mail, labeledURI(These were specified in norEdu 1.3, but the 1.4 class definitions included norEdu attributes only in the MAY part of the Appendix B definitions). - The description of norEduOrgAcronym in chapter 3.1.1 stated that the attribute is to be used with the norEduOgr and norEduOrgUnit class, while it was omitted from the norEduOrgUnit class description in Appendix A. It is now included in both class definitions. - The documentation now states explicitly that Appendix A and B are considered normative, i.e. part of the norEdu specification. Appendix C is informative, i.e. it is not a formal part of the specification. - Chapter 1 now describes how information about new versions and revisions of the specification shall be distributed. ### From version 1.4.1 to 1.5 - Removed the column “Feide relevance” in the Attribute Survey table in 3.1. All information regarding Feide relevance is now found in the two documents “GO-attributter” and “UH-attributter”, for the primary and secondary school and higher education respectively. - Added attribute description and definition for new attribute norEduPersonLegalName. - Removed references to and information about the schac attributes. - Updated information about userPassword. Changed the example from using MD5 to using the SSHA hashing algorithm. Also included a reference to a NIST recommendation for approved algorithms. - Updated the document according to eduPerson200712 and eduPerson200806. - Updated the Feide usage notes and the norEdu attribute descriptions with regard to the increasing use of this specification in primary and secondary education. ### From version 1.5 to 1.5.1 - Added one attribute definition from the schac schema (schacHomeOrganization). - Updated the document according to eduPerson201203. - Updated references. ### From version 1.5.1 to 1.6 - Added two attribute definitions to the norEdu schema for multi-factor authentication. - Updated description of the schac schema as well as its reference. - Updated links to the TERENA website. - Updated references pointing to the attribute table. - Those using this document should from now on monitor [www.feide.no](https://www.feide.no/) for new versions and changes of this document, and not [aktive@feide.no](mailto:aktive@feide.no), [forum@feide.no](mailto:forum@feide.no) or [gnomis@uninett.no](mailto:gnomis@uninett.no). ### From version 1.6 to 2.0 - Updated document to eduPerson201602: - Changes since eduPerson201203: [eduPerson201602: 4. Change log](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html#ChangeLog) - Attribute added: eduPersonPrincipalNamePrior - Attribute added: eduPersonOrcid - Attribute added and reserved for future use: eduPersonUniqueId - Updated document to reference schac 1.5. - Clarified use of mobile attribute for one-time passwords. - Removed availability column from attribute survey. This information is no longer correct because of divergent use. - Removed outdated password hash algorithm SSHA. - Added a note on the mail attribute about some services using the eduPersonPrincipalName as an email address. **Editorial changes:** - Converted the document from a PDF to webpages. - Removed references chapter as we now link directly in the document. - Removed usage notes and example applications for eduPerson and eduOrg attributes. - Added link to definitions, usage notes, and example applications for eduPerson and eduOrg attributes. # Appendix A: Object classes (normative) This appendix is normative, to be considered an integral part of the norEdu\* specification. ## norEdu norEdu\* has adopted the eduPerson and eduOrg object classes, but with some adaptations to the Nordic academic environment. Support for National Identity Numbers ([norEduPersonNIN](./noredu_ch03.html#noredupersonnin)) and support for the numbering scheme for academic institutions have been added. Note that when the norEdu\* schema is used in the Feide federation, several attributes which are optional (MAY) according to the schema definition, are mandatory by the Feide usage rules (equivalent to a schema MUST requirement). ### norEduOrg ```default objectclass (1.3.6.1.4.1.2428.90.2.1 NAME 'norEduOrg' AUXILIARY DESC 'Supplementary attributes for an educational organization' MAY (norEduOrgUniqueIdentifier $ norEduOrgNIN $ norEduOrgAcronym $ norEduOrgSchemaVersion $ dc $ mail $ labeledURI )) ``` ### norEduOrgUnit ```default objectclass (1.3.6.1.4.1.2428.90.2.2 NAME 'norEduOrgUnit' AUXILIARY DESC 'Supplementary attributes for a unit of an educational organization' MAY (norEduOrgUnitUniqueIdentifier $ norEduOrgAcronym $ cn $ mail $ labeledURI)) ``` ### norEduPerson ```default objectclass (1.3.6.1.4.1.2428.90.2.3 NAME 'norEduPerson' AUXILIARY DESC 'Supplementary attributes for a person affiliated with an educational organization' MAY (norEduPersonNIN $ norEduPersonLIN $ norEduPersonBirthDate $ norEduPersonLegalName $ norEduPersonServiceAuthnLevel $ norEduPersonAuthnMethod)) ``` ### norEduObsolete ```default objectclass (1.3.6.1.4.1.2428.90.2.4 NAME 'norEduObsolete' AUXILIARY DESC 'Attributes obsoleted in norEdu 1.4 or later' MAY (norEduOrgUniqueNumber $ norEduOrgUnitUniqueNumber $ federationFeideSchemaVersion)) ``` ## eduPerson EduPerson is an auxiliary object class for campus directories designed to facilitate communication among higher education institutions. It consists of a set of data elements or attributes about individuals within higher education, along with recommendations on the syntax and semantics of the data that may be assigned to those attributes. The eduPerson attributes are found in the next section. All these attribute names are prefaced with eduPerson. The eduPerson auxiliary object class contains all of them as “MAY” attributes: ```default objectclass ( 1.3.6.1.4.1.5923.1.1.2 NAME 'eduPerson' AUXILIARY MAY ( eduPersonAffiliation $ eduPersonNickname $ eduPersonOrgDN $ eduPersonOrgUnitDN $ eduPersonPrimaryAffiliation $ eduPersonPrincipalName $ eduPersonEntitlement $ eduPersonPrimaryOrgUnitDN $ eduPersonScopedAffiliation $ eduPersonTargetedID $ eduPersonAssurance $ eduPersonPrincipalNamePrior $ eduPersonUniqueId $ eduPersonOrcid ) ) ``` It is recommended that person entries have the person, organizationalPerson and inetOrgPerson object classes defined. The former two are defined in X.521 (2001) and inetOrgPerson is defined in [RFC 2798](https://datatracker.ietf.org/doc/html/rfc2798) and based in part on RFC 2256 (now obsoleted by [RFC 4519](https://datatracker.ietf.org/doc/html/rfc4519)). EduPerson attributes would be brought in to the person entry as appropriate from the auxiliary eduPerson object class. Attributes from the person, organizationalPerson and inetOrgPerson classes are listed. The purpose of listing them is primarily as a convenience to enterprise directory designers, but in some cases notes were added to clarify aspects of meaning or usage in the education community beyond what can be found in the original standards documents. Additional information on eduPerson including LDIF for implementing the object class and attributes, is available at its home on the web: [https://www.internet2.edu/products-services/trust-identity/eduperson-eduorg/](https://www.internet2.edu/products-services/trust-identity/eduperson-eduorg/). ## eduOrg eduOrg describes attributes for higher education organizations. ```default objectclass (1.3.6.1.4.1.5923.1.2.2 NAME 'eduOrg' AUXILIARY MAY (eduOrgHomePageURI $ eduOrgIdentityAuthNPolicyURI $ eduOrgLegalName $ eduOrgSuperiorURI $ eduOrgWhitePagesURI $ cn )) ``` # Appendix B: Attribute definitions (normative) ## Attributes defined by norEdu\* This appendix is normative, to be considered an integral part of the norEdu\* specification. Attributes defined by norEdu\* ### norEduPersonNIN ```default attributetype ( 1.3.6.1.4.1.2428.90.1.5 NAME 'norEduPersonNIN' DESC 'National Identity Number, assigned by public authorities' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch USAGE userApplications SINGLE-VALUE ) ``` ### norEduPersonLegalName ```default attributetype ( 1.3.6.1.4.1.2428.90.1.10 NAME 'norEduPersonLegalName' DESC 'The legal name for the subject it is associated with' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SUBSTR caseIgnoreSubstringsMatch EQUALITY caseIgnoreMatch USAGE userApplications SINGLE-VALUE ) ``` ### norEduPersonLIN ```default attributetype ( 1.3.6.1.4.1.2428.90.1.4 NAME 'norEduPersonLIN' DESC 'Locally defined unique identifier for a person' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SUBSTR caseIgnoreSubstringsMatch EQUALITY caseIgnoreMatch USAGE userApplications ) ``` ### norEduOrgAcronym ```default attributetype ( 1.3.6.1.4.1.2428.90.1.6 NAME 'norEduOrgAcronym' DESC 'Acronym for the organization.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch USAGE userApplications) ``` ### norEduPersonBirthDate ```default attributetype ( 1.3.6.1.4.1.2428.90.1.3 NAME 'norEduPersonBirthDate' DESC 'Birth date for a person.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch USAGE userApplications SINGLE-VALUE ) ``` ### norEduOrgSchemaVersion ```default attributetype ( 1.3.6.1.4.1.2428.90.1.11 NAME 'norEduOrgSchemaVersion' DESC 'Version number of the norEdu schema used by the organization' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch USAGE userApplications ) ``` ### norEduOrgUniqueIdentifier ```default attributetype ( 1.3.6.1.4.1.2428.90.1.7 NAME 'norEduOrgUniqueIdentifier' DESC 'Unique identifier describing the organization.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch USAGE userApplications SINGLE-VALUE ) ``` ### norEduOrgUnitUniqueIdentifier ```default attributetype ( 1.3.6.1.4.1.2428.90.1.8 NAME 'norEduOrgUnitUniqueIdentifier' DESC 'Unique identifier describing the organizational unit.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch USAGE userApplications SINGLE-VALUE ) ``` ### norEduOrgNIN ```default attributetype ( 1.3.6.1.4.1.2428.90.1.12 NAME 'norEduOrgNIN' DESC 'Identifier assigned to the organization by public authorities' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch USAGE userApplications SINGLE-VALUE ) ``` ### norEduPersonServiceAuthnLevel ```default attributetype ( 1.3.6.1.4.1.2428.90.1.13 NAME 'norEduPersonServiceAuthnLevel' DESC 'Authentication level enforcement policies.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch USAGE userApplications ) ``` ### norEduPersonAuthnMethod ```default attributetype ( 1.3.6.1.4.1.2428.90.1.14 NAME 'norEduPersonAuthnMethod' DESC 'List of authentication methods that can be used by the subject.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch USAGE userApplications ) ``` ## Obsolete norEdu\* attributes ### norEduOrgUniqueNumber ```default attributetype ( 1.3.6.1.4.1.2428.90.1.1 NAME 'norEduOrgUniqueNumber' DESC 'The number describing the institution.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch USAGE userApplications SINGLE-VALUE ) ``` ### norEduOrgUnitUniqueNumber ```default attributetype ( 1.3.6.1.4.1.2428.90.1.2 NAME 'norEduOrgUnitUniqueNumber' DESC 'The number describing the organizational unit.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch USAGE userApplications SINGLE-VALUE ) ``` ### federationFeideSchemaVersion ```default attributetype ( 1.3.6.1.4.1.2428.90.1.9 NAME 'federationFeideSchemaVersion' DESC 'The norEdu scheme version used by the LDAP of the organization .' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch USAGE userApplications SINGLE-VALUE ) ``` ## Attributes from schac ### schacHomeOrganization ```default attributetype (1.3.6.1.4.1.25178.1.2.9 NAME 'schacHomeOrganization' DESC ' Domain name of the home organization.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch SINGLE-VALUE ) ``` ## Attributes from eduPerson ### eduPersonAffiliation ```default attributetype (1.3.6.1.4.1.5923.1.1.1.1 NAME 'eduPersonAffiliation' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15') ``` ### eduPersonEntitlement ```default attributetype (1.3.6.1.4.1.5923.1.1.1.7 NAME 'eduPersonEntitlement' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseExactMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) ``` ### eduPersonNickname ```default attributetype ( 1.3.6.1.4.1.5923.1.1.1.2 NAME 'eduPersonNickname' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) ``` ### eduPersonOrgDN ```default attributetype ( 1.3.6.1.4.1.5923.1.1.1.3 NAME 'eduPersonOrgDN' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE ) ``` ### eduPersonOrgUnitDN ```default attributetype ( 1.3.6.1.4.1.5923.1.1.1.4 NAME 'eduPersonOrgUnitDN' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' ) ``` ### eduPersonPrimaryAffiliation ```default attributetype ( 1.3.6.1.4.1.5923.1.1.1.5 NAME 'eduPersonPrimaryAffiliation' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE ) ``` ### eduPersonPrimaryOrgUnitDN ```default attributetype ( 1.3.6.1.4.1.5923.1.1.1.8 NAME 'eduPersonPrimaryOrgUnitDN' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE ) ``` ### eduPersonPrincipalName ```default attributetype ( 1.3.6.1.4.1.5923.1.1.1.6 NAME 'eduPersonPrincipalName' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE ) ``` ### eduPersonScopedAffiliation ```default attributetype ( 1.3.6.1.4.1.5923.1.1.1.9 NAME 'eduPersonScopedAffiliation' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) ``` ### eduPersonTargetedID ```default attributetype (1.3.6.1.4.1.5923.1.1.1.10 NAME ' eduPersonTargetedID' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseExactMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) ``` ### eduPersonAssurance ```default attributetype ( 1.3.6.1.4.1.5923.1.1.1.11 NAME 'eduPersonAssurance' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseExactMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) ``` ### eduPersonPrincipalNamePrior ```default attributetype ( 1.3.6.1.4.1.5923.1.1.1.12 NAME 'eduPersonPrincipalNamePrior' DESC 'eduPersonPrincipalNamePrior per Internet2' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) ``` ### eduPersonUniqueId ```default attributetype ( 1.3.6.1.4.1.5923.1.1.1.13 NAME 'eduPersonUniqueId' DESC 'eduPersonUniqueId per Internet2' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE ) ``` ### eduPersonOrcid ```default attributetype ( 1.3.6.1.4.1.5923.1.1.1.16 NAME 'eduPersonOrcid' DESC 'eduPersonOrcid per Internet2' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) ``` ## Attributes from eduOrg ### eduOrgHomePageURI ```default attributetype ( 1.3.6.1.4.1.5923.1.2.1.2 NAME ' eduOrgHomePageURI' DESC 'eduOrg per Internet2 and EDUCAUSE' EQUALITY caseExactMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) ``` ### eduOrgIdentityAuthNPolicyURI ```default attributetype ( 1.3.6.1.4.1.5923.1.2.1.3 NAME ' eduOrgIdentityAuthNPolicyURI' DESC 'eduOrg per Internet2 and EDUCAUSE' EQUALITY caseExactMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) ``` ### eduOrgLegalName ```default attributetype ( 1.3.6.1.4.1.5923.1.2.1.4 NAME ' eduOrgLegalName' DESC 'eduOrg per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) ``` ### eduOrgWhitePagesURI ```default attributetype ( 1.3.6.1.4.1.5923.1.2.1.6 NAME ' eduOrgWhitePagesURI' DESC 'eduOrg per Internet2 and EDUCAUSE' EQUALITY caseExactMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) ``` # Appendix C: Obsolete attributes This appendix is informative only, and does not form part of the norEdu\* specification. ## Attributes obsoleted from norEdu\*1.3 to norEdu\*1.4 - norEduOrgUniqueNumber - Obsoleted by [norEduOrgNIN](./noredu_ch03.html#noreduorgnin), [norEduOrgUniqueIdentifier](./noredu_ch03.html#noreduorguniqueidentifier). - norEduOrgUnitUniqueNumber - Obsoleted by [norEduOrgUnitUniqueIdentifier](./noredu_ch03.html#noreduorgunituniqueidentifier) - federationFeideSchemaVersion - Obsoleted by [norEduSchemaVersion](./noredu_ch03.html#noreduorgschemaversion). # LDAP validator In Feide we have a LDAP validator. This validator checks user directories for common problems and errors. * [Running the LDAP validator](running.html.md) * [Validator errors](errors/index.html.md) # Running the LDAP validator The LDAP validator is used in two locations: * We run a simple check of the user data every time the user logs in. The result of this check is presented in the [customer portal](https://kunde.feide.no/), using the “View errors in user directory” utility. * A full check of all users in the directory can be run using the LDAP crawler. The LDAP crawler can be accessed from a link in the “View errors in user directory” utility in the [customer portal](https://kunde.feide.no/). # Validator errors There are many different warnings and errors that can be emitted by the LDAP validator. This document attempts to document some of the common errors. * [Duplicate identifier in norEduOrgUnitUniqueIdentifier](duplicate_noreduorgunituniqueidentifier.html.md) * [Group ID not in canonical form](groupid_not_canonical.html.md) * [Group IDs without a corresponding group](groupid_without_group.html.md) * [Group with invalid code](group_invalid_code.html.md) * [Group without code](group_without_code.html.md) * [Groups without a corresponding group ID](group_without_groupid.html.md) * [Missing basis group for pupil](missing_basis_groups.html.md) * [Missing Grep codes for student](missing_grep_codes.html.md) * [Missing group IDs](missing_group_ids.html.md) * [Missing groups for teacher or pupil](missing_groups.html.md) * [Missing organization unit](missing_organization_unit.html.md) * [Missing required attribute](missing_required_attribute.html.md) * [Missing teaching groups for teacher or pupil](missing_teaching_groups.html.md) # Duplicate identifier in norEduOrgUnitUniqueIdentifier Users can be associated with one or more organization units. For universities and university colleges, this is typically faculties and departments. For primary and secondary education, these are the actual schools of the user. Each organization unit / school must have a unique identifier. If more than one organization unit has the same identifier, you should check whether a school or organization unit has been duplicated in the user directory. #### NOTE For primary and secondary schools, the value in norEduOrgUnitUniqueIdentifier is the organization number of the school. # Group ID not in canonical form #### NOTE This error only applies to primary and secondary schools. In version 2.0 of the Feide schema we introduced group identifier values in [eduPersonEntitlement](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonentitlement). The group identifiers contain much of the same information as the information registered in groups. They are however structured differently, to allow us to look up all users belonging to a specific group. To allow us to look up all users belonging to a specific group, we need to be able to determine the exact value that will be stored in eduPersonEntitlement for that group. It is therefore important that the eduPersonEntitlement value is encoded exactly as described in [the documentation](../../schema/info_go/go_attributter_chA4.html.md#groupid-formatting). This is what we refer to as “canonical form” in the error message The most common problem is a failure to properly encode the local group identifier. It is important that it is converted to lowercase and then percent encoded. ## Example Consider the following group value: `urn:mace:feide.no:go:group:a::NO987654321:PRJ-%C3%85RBOK:2020-08-01:2021-06-15:student:Prosjekt%20%C3%A5rbok` This represents a group with the name “Prosjekt årbok” and local group identifier `PRJ-ÅRBOK`. Note that the local group identifier in the group value is encoded as `PRJ-%C3%85RBOK`. `%C3%85` is the precent encoding of the uppercase `Å`. To build the group identifier value, we need to transform the elements from the group value to the canonical form. For example, the local group identifier needs to be stored in lowercase format and then percent encoded. A lowercase `å` is encoded as `%C3%A5`, so the local group identifier part becomes `prj-%C3%A5rbok`. The full group identifer value should be: `urn:mace:feide.no:go:groupid:a:NO987654321:prj-%C3%A5rbok:2020-08-01:2021-06-15` # Group IDs without a corresponding group #### NOTE This error only applies to primary and secondary schools. In version 2.0 of the Feide schema we introduced group identifier values in [eduPersonEntitlement](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonentitlement). The group identifiers contain much of the same information as the information registered in groups. They are however structured differently, to allow us to look up all users belonging to a specific group. Group *identifier* values start with the prefix `urn:mace:feide.no:go:groupid:`. Group values start with the prefix `urn:mace:feide.no:go:group:`. There is a one-to-one relation between group identifier values and group values. This means that for every group value there needs to be a corresponding group identifier value, and that for every group identifier value there needs to be a corresponding group value. This error indicates that there is one or more group identifier values that do not match any group values. To fix this, you need to ensure that the values added to eduPersonEntitlement are consistent. For every group retrieved from the data source, you need to create two eduPersonEntitlement values – one group value and one group identifier value. See [Appendix 3 - Registration of group information within eduPersonEntitlement](../../schema/info_go/go_attributter_chA3.html.md) for information about registration of group values and See [Appendix 4 - Registration of group-IDs in eduPersonEntitlement](../../schema/info_go/go_attributter_chA4.html.md) for information about registration of group identifier values. ## Example A user may have the following values in eduPersonEntitlement: * `urn:mace:feide.no:go:group:b::NO987654321:6a:2020-08-01:2021-06-15:student:Klasse%206A` * `urn:mace:feide.no:go:group:u:MAT0006:NO987654321:6a-matte:2020-08-01:2021-06-15:student:Matematikk%20for%206A` * `urn:mace:feide.no:go:groupid:b:NO987654321:6a:2020-08-01:2021-06-15` * `urn:mace:feide.no:go:groupid:u:NO975278964:6a-matte:2020-08-01:2021-06-15` * `urn:mace:feide.no:go:groupid:u:NO975278964:6a-norsk:2020-08-01:2021-06-15` Here the user has an extra group identifier for `6a-norsk`. # Group with invalid code #### NOTE This error only applies to primary and secondary schools. Users are associated with teaching groups (undervisingsgrupper) through the [eduPersonEntitlement](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonentitlement) attribute. Every teaching group is associated with a subject. These subjects are identified through codes (fagkoder) in the [Grep database](https://www.udir.no/om-udir/data/kl06-grep/). For example, mathematics for sixth grade has the code [MAT0006](https://www.udir.no/kl06/MAT0006). It would then be registered with the following entry in eduPersonEntitlement: `urn:mace:feide.no:go:group:u:MAT0006:NO987654321:6a-matte:2020-08-01:2021-06-15:student:Matematikk%20for%206A` The “group with invalid code” error indicates that the code used for a subject is incorrect. We check the codes against the [list of valid codes](https://data.udir.no/kl06/fagkoder) (JSON formatted) in the Grep database. If the code is not found, this error is logged. See [Appendix 3 - Registration of group information within eduPersonEntitlement](../../schema/info_go/go_attributter_chA3.html.md) for more details about registration of groups. ## Example A user may have the following value in eduPersonEntitlement: `urn:mace:feide.no:go:group:u:VAL0002:NO987654321:2a-sal-og-scene:2020-08-01:2021-06-15:student:Sal%20og%20scene%20for%202A` Here the group has the code VAL0002, which is not the correct code for this subject (Sal og scene). Instead, the correct code should be [VAL0001](https://www.udir.no/kl06/VAL0001). # Group without code #### NOTE This error only applies to primary and secondary schools. Users are associated with teaching groups (undervisingsgrupper) through the [eduPersonEntitlement](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonentitlement) attribute. Every teaching group is associated with a subject. These subjects are identified through codes (fagkoder) in the [Grep database](https://www.udir.no/om-udir/data/kl06-grep/). For example, mathematics for sixth grade has the code [MAT0006](https://www.udir.no/kl06/MAT0006). It would then be registered with the following entry in eduPersonEntitlement: `urn:mace:feide.no:go:group:u:MAT0006:NO987654321:6a-matte:2020-08-01:2021-06-15:student:Matematikk%20for%206A` The “group without code” error indicates that there is a teaching group without a subject code. See [Appendix 3 - Registration of group information within eduPersonEntitlement](../../schema/info_go/go_attributter_chA3.html.md) for more details about registration of groups. ## Example A user may have the following value in eduPersonEntitlement: `urn:mace:feide.no:go:group:u::NO987654321:6a-matte:2020-08-01:2021-06-15:student:Matematikk%20for%206A` Here we do not have a subject code for the group. In this case it should have been MAT0006, so the full attribute value should have been: `urn:mace:feide.no:go:group:u:MAT0006:NO987654321:6a-matte:2020-08-01:2021-06-15:student:Matematikk%20for%206A` # Groups without a corresponding group ID #### NOTE This error only applies to primary and secondary schools. In version 2.0 of the Feide schema we introduced group identifier values in [eduPersonEntitlement](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonentitlement). The group identifiers contain much of the same information as the information registered in groups. They are however structured differently, to allow us to look up all users belonging to a specific group. Group *identifier* values start with the prefix `urn:mace:feide.no:go:groupid:`. Group values start with the prefix `urn:mace:feide.no:go:group:`. There is a one-to-one relation between group identifier values and group values. This means that for every group value there needs to be a corresponding group identifier value, and that for every group identifier value there needs to be a corresponding group value. This error indicates that there is one or more group values that do not match any group identifier values. To fix this, you need to ensure that the values added to eduPersonEntitlement are consistent. For every group retrieved from the data source, you need to create two eduPersonEntitlement values – one group value and one group identifier value. See [Appendix 3 - Registration of group information within eduPersonEntitlement](../../schema/info_go/go_attributter_chA3.html.md) for information about registration of group values and See [Appendix 4 - Registration of group-IDs in eduPersonEntitlement](../../schema/info_go/go_attributter_chA4.html.md) for information about registration of group identifier values. ## Example A user may have the following values in eduPersonEntitlement: * `urn:mace:feide.no:go:group:b::NO987654321:6a:2020-08-01:2021-06-15:student:Klasse%206A` * `urn:mace:feide.no:go:group:u:MAT0006:NO987654321:6a-matte:2020-08-01:2021-06-15:student:Matematikk%20for%206A` * `urn:mace:feide.no:go:group:u:NOR0006:NO987654321:6a-norsk:2020-08-01:2021-06-15:student:Norsk%20for%206A` * `urn:mace:feide.no:go:groupid:b:NO987654321:6a:2020-08-01:2021-06-15` * `urn:mace:feide.no:go:groupid:u:NO987654321:6a-matte:2020-08-01:2021-06-15` Here the user is missing the group identifier value for `6a-norsk`. # Missing basis group for pupil #### NOTE This error only applies to primary and secondary schools. All pupils should normally be associated with a basis group (basisgruppe). This is the “klasse” or “basisgruppe” that the pupil is associated with, e.g. “5A”. We check the eduPersonAffiliation attribute to see if the user is a pupil. If the user has `student` in eduPersonAffiliation, the user is a pupil. In that case, we check that the user is associated with a basis group. Group information is registered in the [eduPersonEntitlement](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonentitlement) attribute of the user directory. Basis groups are represented as eduPersonEntitlement-values with the prefix `urn:mace:feide.no:go:group:b:`. If the pupil for some reason should not be part of any basis group, this error can be ignored. See [Appendix 3 - Registration of group information within eduPersonEntitlement](../../schema/info_go/go_attributter_chA3.html.md) for more details. # Missing Grep codes for student #### NOTE This error only applies to primary and secondary schools. From version 1.5 of the Feide schema, it became mandatory to register Grep codes the user directory. This information is registered in the [eduPersonEntitlement](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonentitlement) attribute. The Grep codes are represented as eduPersonEntitlement-values with the prefix urn:mace:feide.no:go:grep:. All pupils should at least be registered with their grade. For pupils in upper secondary education, information about their education programme and programme area must also be registered. There are a few cases where the pupil is not part of the normal educational pathway, and is not associated with any grades. In that case, this error can be ignored. See [Appendix 2 - Registration of Grep-codes within eduPersonEntitlement](../../schema/info_go/go_attributter_chA2.html.md) for more details. # Missing group IDs #### NOTE This error only applies to primary and secondary schools. In version 2.0 of the Feide schema we introduced group identifier values in [eduPersonEntitlement](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonentitlement). The group identifiers contain much of the same information as the information registered in groups. They are however structured differently, to allow us to look up all users belonging to a specific group. Group *identifier* values start with the prefix `urn:mace:feide.no:go:groupid:`. Group values start with the prefix `urn:mace:feide.no:go:group:`. There is a one-to-one relation between group identifier values and group values. This means that for every group value there needs to be a corresponding group identifier value, and that for every group identifier value there needs to be a corresponding group value. This error indicates that the users have group values but no group *identifier* values. To fix this, you need to ensure that the values added to eduPersonEntitlement are consistent. For every group retrieved from the data source, you need to create two eduPersonEntitlement values – one group value and one group identifier value. See [Appendix 3 - Registration of group information within eduPersonEntitlement](../../schema/info_go/go_attributter_chA3.html.md) for information about registration of group values and See [Appendix 4 - Registration of group-IDs in eduPersonEntitlement](../../schema/info_go/go_attributter_chA4.html.md) for information about registration of group identifier values. ## Example A user may have the following values in eduPersonEntitlement: * `urn:mace:feide.no:go:group:b::NO987654321:6a:2020-08-01:2021-06-15:student:Klasse%206A` * `urn:mace:feide.no:go:group:u:MAT0006:NO987654321:6a-matte:2020-08-01:2021-06-15:student:Matematikk%20for%206A` * `urn:mace:feide.no:go:group:u:NOR0006:NO987654321:6a-norsk:2020-08-01:2021-06-15:student:Norsk%20for%206A` Here the user is missing the group identifier value for all three groups. These should have been: * `urn:mace:feide.no:go:groupid:b:NO987654321:6a:2020-08-01:2021-06-15` * `urn:mace:feide.no:go:groupid:u:NO987654321:6a-matte:2020-08-01:2021-06-15` * `urn:mace:feide.no:go:groupid:u:NO987654321:6a-norsk:2020-08-01:2021-06-15` # Missing groups for teacher or pupil #### NOTE This error only applies to primary and secondary schools. From version 1.6 of the Feide schema, it became mandatory to register group information in the user directory. This information is registered in the [eduPersonEntitlement](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonentitlement) attribute. The groups are represented as eduPersonEntitlement-values with the prefix urn:mace:feide.no:go:group:. All pupils should normally be associated with both a basis group (basisgruppe) and several teaching groups (undervisningsgrupper). All teachers should be associated with the teaching groups and in many cases one or more basis group. To identify which users should have groups, we look at the eduPersonAffiliation attribute of the users. If the user has either `student` or `faculty` in eduPersonAffiliation, we assume that the user should be associated with some groups. There are a few cases where the user is not part of any groups. For example substitute teachers may in some cases not be associated with any groups. In that case, this error can be ignored. See [Appendix 3 - Registration of group information within eduPersonEntitlement](../../schema/info_go/go_attributter_chA3.html.md) for more details. # Missing organization unit There are two attributes that are used to indicate which organization units (schools in primary and secondary education) the user is associated with. * [eduPersonOrgUnitDN](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonorgunitdn): Contains all organization units (schools in primary and secondary education) the user is associated with. * [eduPersonPrimaryOrgUnitDN](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonprimaryorgunitdn): Contains the primary organization unit (school in primary and secondary education) the user is associated with. This error indicates that the user has both the `eduPersonPrimaryOrgUnitDN`- and the `eduPersonOrgUnitDN`-attribute, but that the value in `eduPersonPrimaryOrgUnitDN`-value is not present in the `eduPersonOrgUnitDN`-attribute. Either because the value is missing from `eduPersonOrgUnitDN`, or because the `eduPersonPrimaryOrgUnitDN`-value is incorrect. ## Example A user was moved from “One school” to “Other school”, but the `eduPersonPrimaryOrgUnitDN`-value was not updated: * `eduPersonOrgUnitDN: ou=Other school,cn=schools,dc=example,dc=org` * `eduPersonPrimaryOrgUnitDN: ou=One school,cn=schools,dc=example,dc=org` To fix this, update `eduPersonPrimaryOrgUnitDN` as well. # Missing required attribute Many attributes are mandatory to register. If the LDAP validator is missing one of the required attributes, it will log this error with information about which attribute it is missing. Refer to the [The Feide information model for lower education](../../schema/info_go/index.html.md) and [Feides information model for higher education](../../schema/info_uh/index.html.md) documents for information about which attributes are mandatory. ## Missing eduPersonOrgUnitDN / eduPersonPrimaryOrgUnitDN The [eduPersonOrgUnitDN](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonorgunitdn) and [eduPersonPrimaryOrgUnitDN](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonprimaryorgunitdn) attributes are mandatory to register users in primary and secondary schools. However, in some cases it may be necessary to register a few users who are not associated with any schools. E.g. users working in central IT at the municipality. When the user is not associated with any schools, no value should be registered in the eduPersonOrgUnitDN and eduPersonPrimaryOrgUnitDN attributes. The error can be ignored in that case. # Missing teaching groups for teacher or pupil #### NOTE This error only applies to primary and secondary schools. All teachers and pupils should normally be associated with a number of teaching groups (undervisningsgrupper). We check the eduPersonAffiliation attribute to see if the user is a teacher or pupil. If the user has `faculty` or `student` in eduPersonAffiliation, the user is a teacher or pupil. In that case, we check that the user is associated with at least one teaching group. Group information is registered in the [eduPersonEntitlement](../../schema/info_go/go_attributter_ch02.html.md#go-schema-edupersonentitlement) attribute of the user directory. Teaching groups are represented as eduPersonEntitlement-values with the prefix `urn:mace:feide.no:go:group:u:`. There are a few cases where the user is not part of any teaching group. For example substitute teachers may in some cases not be associated with any teaching group. In that case, this error can be ignored. See [Appendix 3 - Registration of group information within eduPersonEntitlement](../../schema/info_go/go_attributter_chA3.html.md) for more details. # APIs * [Feide API](feide-api/index.html.md) * [Groups API](groups_api/index.html.md) * [OpenID Connect userinfo](userinfo.html.md) * [Feide user attributes](attributes_feide/index.html.md) * [Guardian API](guardianapi.html.md) * [Deprecated APIs](deprecated/index.html.md) # Feide API The Feide API provides access to various data about organizations and services connected to Feide. It is available at https://api.feide.no/. ## Accessing the API * [URL structure](url-structure.html.md) * [Versioning](url-structure.html.md#versioning) * [Rate limit](rate-limit.html.md) * [Increasing the rate limit](rate-limit.html.md#increasing-the-rate-limit) * [Access token](access-token.html.md) * [Getting an access token](access-token.html.md#getting-an-access-token) * [Providing the access token to the API](access-token.html.md#providing-the-access-token-to-the-api) * [Select fields in response](select-fields.html.md) * [Availability](select-fields.html.md#availability) * [Example](select-fields.html.md#example) ## Available endpoints * [Multifactor authentication](mfa.html.md) * [Organization information](organizations.html.md) * [Service information](services.html.md) * [Statistics](statistics.html.md) * [Passkey administration](passkey-management.html.md) # URL structure The URL structure for the Feide API is: https://api.feide.no/VERSION/API `VERSION`: The version is a number indicating the version of the API. Whenever we change something that breaks backwards compatibility, we increase that number by 1. `API`: The API / data source you are accessing. ## Versioning The Feide API uses the first element of the URL to version the API. We are currently at version 2, so all URLs start with `/2/`: [https://api.feide.no/2/](https://api.feide.no/2/) # Rate limit If accessing the API without an [access token](access-token.html.md), there is a rate limit that restricts you to 15 requests per 15 minutes. This is a per-IP address limit. If you go over the rate limit, you will get a “503 Service Unavailable”-error. ## Increasing the rate limit To increase the rate limit, you must provide an access token to the API. See the [access token](access-token.html.md) document for more details about obtaining and providing an access token. # Access token By providing a valid access token to the API, you can get a higher rate limit for fetching data. The default rate limit with an access token is 180 requests per 15 minutes, but this can be increased further upon request. ## Getting an access token To get an access token, send an email to [support@feide.no](mailto:support@feide.no) describing what you are using the API for. ## Providing the access token to the API The access token is provided in an Authorization-header with the `Bearer` type: ```default GET /2/org/136 HTTP/1.1 Host: api.feide.no Authorization: Bearer ACCESS-TOKEN ``` # Select fields in response All APIs have a set of fields that are included in the response by default. Many APIs allow you to override this set. This can be used to: * Reduce the amount of data returned if you do not need all the default fields. * Retrieve fields that are not returned by default. This is done through the `fields` query parameter. This query parameter is a comma-separated list of which fields should be returned in the response. ## Availability The `fields` query parameter is only available on specific APIs. This is documented on the individual APIs. The available fields are also documented on the individual API pages. Fields that are not returned by default are marked as such. ## Example To retrieve just the name and provider of a service, you can specify `fields=name,provider` in the query string: `https://api.feide.no/2/sp/16540?fields=name,provider` This will return something like: ```json { "provider": { "id": "136", "name": { "nb": "Uninett AS", "en": "Uninett AS" }, "realm": "uninett.no" }, "name": { "en": "Feide Customer Portal", "nb": "Feide Kundeportal" } } ``` # Multifactor authentication The multifactor authentication API can be used to generate and encrypt [TOTP](https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm) secrets. The multifactor authentication API is available under https://api.feide.no/2/mfa/ ## Time-based one-time password The Time-based one-time password (TOTP) endpoint can be used to generate and encrypt secrets for usage with the authenticator-compatible code generators. This API is available on https://api.feide.no/2/mfa/totp All requests to this API must be [POST](https://en.wikipedia.org/wiki/POST_(HTTP)) requests. ### POST parameters The POST request has the following optional data parameters: * `secret`: The secret to encrypt. The secret consists of exactly 16 characters, using the letters A-Z and the numbers 2-7. This parameter is optional. If not provided, a random secret will be generated. * `label`: The label that can be used to identify the device this secret is generated for. This label is displayed on the login page when the user is asked for their multifactor authentication code. This parameter is optional. If not provided a generic description is used for the generator on the login page. ### Output The result of the API call is a JSON object with the following structure: ```json { "secret": "ABCDABCDABCDABCD", "label": "Some device name", "result": "urn:mace:feide.no:auth:method:ga eyJlbmMiOiAiQTEyOENCQy1IUzI1NiIsICJhbGciOiAiUlNBLU9BRVAifQ.WOXw6dkzja5Q7Ixn4hL3cXaKbL5JepfmGi_F2g-OstR3MoDgJ_9BjJdLPoEfBHzI-54lRHUKvhSv0m9AN71Hb-ebjPVnn1afOJrrPQDwLNX30ZQwLux8hx86eiBEIFE2_mqEv-K5zGsQsBQEHMFhLci-oEnfCiMFfppL6cNJAkmWWMT7Sns3TRlL0gQhPSLxOs9JP6YyzuBKe_YaEB3D7zD_-3ts5eDWTxM_zTGeHH1CGGhMDZwiCc3AvYpxan5YjCEBGBmFM8TOp6-RtrYw8qoUbFsJVhrLU7aPjFOe_BBr1P1BTckA7iBwka5CJu421HAkPb7xnOPQNwYoaT-Zwg.J9yVLY-Ipwj5PtfL9NnwHg.RvJUFDmHRH51CHrOp7sUtfyFeXIszGiv_YsWy-YBdlY.xkto8-e7mXc6Wn88V3do2w label=Some%20device%20name" } ``` The following fields are returned: * `secret`: The secret that was encrypted. This field is included both when the secret was provided in the request and when the secret was generated by the API. * `label`: The label that was included in the generated attribute value. This field is `null` if no label was provided in the request. * `result`: The encrypted secret, encoded as a attribute value suitable for storage in the [`norEduPersonAuthnMethod`](../../../reference/schema/noredu/noredu_ch03.html#noredupersonauthnmethod) attribute. If a label was provided in the request, it will be encoded in the attribute value. Use the `fields` query parameter to [select fields in the response](select-fields.html.md). ### Examples To generate a random secret: ```shell curl -sSLf -XPOST 'https://api.feide.no/2/mfa/totp' ``` To encrypt a fixed secret with a label: ```shell curl -sSLf -d secret='ABCDABCDABCDABCD' -d label='Some device name' 'https://api.feide.no/2/mfa/totp' ``` To generate a random secret with a fixed label ```shell curl -sSLf -d label='Some device name' 'https://api.feide.no/2/mfa/totp' ``` # Organization information The organization information API provides access to information about organizations connected to Feide. This includes both host organizations (organizations whose users can log in using Feide) and service providers. The organization information API is available under https://api.feide.no/2/org/ ## Data model An organization object has the following structure: ```json { "id": "42", "name": { "en": "Example municipality", "nb": "Eksempel kommune", "nn": "Døme kommune" }, "realm": "eksempel.kommune.no", "organization_number": "123456789", "type": [ "home_organization", "primary_and_lower_secondary" ], "attribute_release_policy": "info", "schema_version": "1.6", "support_email": "help@eksempel.kommune.no", "support_phone": "+4798765432", "support_url": { "en": "https://www.eksempel.kommune.no/services/it/support/", "nb": "https://www.eksempel.kommune.no/tjenester/it/support/" } } ``` ### `id` The `id` field contains the identifier of the organization in the Feide database. ### `name` This is the name of the organization. It is an object containing key/value pairs where the key is a language code and the value is the name in that language. The currently available languages are `nb` (Norwegian bokmål), `nn` (Norwegian nynorsk), `se` (Sami) and `en` (English). Not all languages are available for all organizations. ### `realm` The `realm` contains the realm of the users in the organization. This is the part after the `@` in the eduPersonPrincipalName field in authentication responses from Feide. This field is only applicable to home organizations. For service providers it will be `null`. ### `organization_number` The `organization_number` contains the organization_number of the organization. This field is only applicable to home organizations. This field is not returned by default. Use the `fields` query parameter to [include this field in the response](select-fields.html.md). ### `type` The types of the organization. This is a list containing the different categories of the organization. The following types are available: * `higher_education`: A university or university college. * `home_organization`: A home organization, which is an organization whose users can log into Feide services. * `primary_and_lower_secondary`: A organization providing primary and lower secondary schools. Typically municipalities, but also includes private schools. * `service_provider`: An organization providing one or more services. * `upper_secondary`: A organization providing upper secondary schools. Mainly county councils, but also includes private schools. ### `attribute_release_policy` **Deprecated**. User consent policy for home organization. Always set to `info`. This field is deprecated and will be removed in a future version of the API. This field is only applicable to home organizations. For service providers it will be `null`. This field is not returned by default. Use the `fields` query parameter to [include this field in the response](select-fields.html.md). ### `schema_version` Feide schema version used by the organization. This field is not returned by default. Use the `fields` query parameter to [include this field in the response](select-fields.html.md). ### `support_email` Email where the organization provides support for its users or customers. `null` if no email given. This field is not returned by default. Use the `fields` query parameter to [include this field in the response](select-fields.html.md). ### `support_phone` Phone number where the organization provides support for its users or customers. `null` if no phone given. This field is not returned by default. Use the `fields` query parameter to [include this field in the response](select-fields.html.md). ### `support_url` URL where the organization publishes support info for its users or customers. `null` if no URL given. It is an object containing key/value pairs where the key is a language code and the value is a URL. There is one pair for each language we have a URL for. The currently available languages are `nb` (Norwegian bokmål), `nn` (Norwegian nynorsk), `se` (Sami) and `en` (English). Not all languages are available for all organizations. This field is not returned by default. Use the `fields` query parameter to [include this field in the response](select-fields.html.md). ## Available endpoints There are two endpoints available for organization data, one for retrieving all organizations, and one for fetching a single organization ### Fetching all organizations URL: https://api.feide.no/2/org/all This returns a JSON array containing all organizations. Use the `fields` query parameter to [select fields in the response](select-fields.html.md). ### Fetching a single organization URL: https://api.feide.no/2/org/ORG-ID This returns a JSON object for the single organization with the `id` ORG-ID If the organization does not exist, a “404 Not Found” error is returned. Use the `fields` query parameter to [select fields in the response](select-fields.html.md). # Service information This API provides access to information about services connected to Feide. The service information API is available under https://api.feide.no/2/sp/ ## Data model A service object has the following structure: ```json { "about_url": "https://www.feide.no/administrator", "areas_of_use": [], "attributes": [ "eduPersonPrincipalName" ], "audiences": [], "demo_video_url": null, "demo_web_url": null, "description": { "en": "Feide Customer Portal is used by master users at the home organization to subscribe to services, register new services and administer master users. Only registered master users are granted access to Feide Customer Portal.", "nb": "I kundeportalen får man oversikt over hvilke tjenester din organisasjon abonnerer på og hvilke tjenester det kan abonneres på. Utvalgte brukere (berettigede) anvender også kundeportalen til å abonnere på tjenester, varsle om nye tjenester, samt administrere berettigede personer.", "nn": "Feides kundeportal benyttes av de berettigede ved vertsorganisasjonen til å abonnere på tenester, varsle om nye tenester, samt administrere berettigede personar. Kundeportalen er kun tilgjengeleg for de som er registrert som berettiget ved organisasjonen." }, "id": "16540", "levels": [], "login_url": "https://kunde.feide.no/", "logo_rectangular": null, "logo_square": null, "name": { "en": "Feide Customer Portal", "nb": "Feide Kundeportal" }, "ordering_information": null, "payment_model": "free", "privacy_policy_urls": {}, "provider": { "id": "136", "name": { "en": "Uninett", "nb": "Uninett" }, "realm": "uninett.no" }, "subjects": [], "technology_requirements": [] } ``` ### `about_url` An URL with information describing this service. ### `areas_of_use` List of applications / areas of use for this service. The current values are: * `administrative` * `educational` * `utilities` We may add more values in the future. *Note*: This attribute is a list, and one service can have multiple entries here. ### `attributes` List of attributes that this service receives from Feide during login. The list of possible attributes can be found in the [attribute list](../../schema/attributes/index.html.md). ### `audiences` The target audiences for this service. Possible values are: * `higher_education` * `other` * `primary_and_lower_secondary` * `upper_secondary` ### `demo_video_url` An URL to a video demonstrating this service. ### `demo_web_url` A web page with a demo version of the service. ### `description` Description of this service. This is an object with one key for each language. This description will be shown on the Feide login page. In general it is therefore just a single paragraph of text. ### `free_of_charge` This service is at least partially free of charge. Some parts of the service may still require payment. This field replaces the [payment_model](#payment-model) field. This field is not returned by default. Use the `fields` query parameter to [include this field in the response](select-fields.html.md). ### `id` The identifier of this service. ### `levels` List of target levels (grades) for this service. Mainly useful for educational services. Possible values are: * `1-4` * `5-7` * `8-10` * `upper_secondary` ### `login_url` A URL to a page where the end user can log into the service. ### `logo_rectangular` Identifier for a rectangular logo for this service. ### `logo_square` Identifier for a square logo for this service. ### `name` Name of this service. This is an object with one key for each language. ### `ordering_information` Information about where to go for information about where to order this service. This is currently a freeform field, and can contain URLs, e-mail addresses, telephone numbers, etc. ### `payment_model` What payment model this service uses (if available). Possible values are: * `free` * `paid` * `partially_paid` If this information is unavailable, this field contains `null`. ### `privacy_policy_urls` URLs for the service privacy policy. This is an object with one key for each language. ### `provider` The service provider. This contains a subset of the information available from the [organization API](organizations.html.md). ### `subjects` Subjects this service teaches. Mainly applicable for educational services. Each subject is returned in the form of a subject object: ```json { "id": "4", "name": { "en": "History", "nb": "Historie" } } ``` ### `technology_requirements` List of technology requirements this service has. Each entry in the list is freeform text, so there is no real standardization of values here. ## Available endpoints There are several endpoints available for fetching service provider data. In addition to endpoints fetching service data, there is also an endpoint for fetching the service logo. ### Fetching all services URL: https://api.feide.no/2/sp/all This returns a JSON array containing all services. Use the `fields` query parameter to [select fields in the response](select-fields.html.md). ### Fetching a single service URL: https://api.feide.no/2/sp/SVC-ID This returns a JSON object for a single service with the `id` SVC-ID If the service does not exist, a “404 Not Found” error is returned. Use the `fields` query parameter to [select fields in the response](select-fields.html.md). ### Listing a subset of services URL: https://api.feide.no/2/sp/filter This endpoint allows you to filter the list of services based on some criteria. The criteria are passed as query parameters. Currently only a single criteria is available: * `audiences`: `audience`-values this service must have. Multiple values can be specified by repeating the query parameter. In that case all specified values must be present. Use the `fields` query parameter to [select fields in the response](select-fields.html.md). ### Fetching the logo of a service URL: https://api.feide.no/2/sp/SVC-ID/logo/SHAPE/LOGO This URL allows downloads of the logos from the service. URL parameters: * `SVC-ID`: The service identifier. * `SHAPE`: Either `rectangular` or `square` depending on the logo you are fetching. * `LOGO`: The logo identifier. This is the contents of the [logo_rectangular](#logo-rectangular) or [logo_square](#logo-square) field in the returned SP data. # Statistics The statistics API gives access to information about the number of logins in Feide. ## Summary statistics The summary statistics provides a set of total logins for various organizations types over a set of time periods. Summary statistics is available from: [https://api.feide.no/2/stats/summary](https://api.feide.no/2/stats/summary) The returned data of the endpoint is a object where each key is the organization types. Under each organization type the data is further subdivided by the time period. Finally at the leaf node, we have the number of logins. ```json { "upper_secondary": { "this_month": 3884839, "this_week": 1268936, "today": 227977, "this_year": 61763975 }, "all": { "this_month": 9394867, "this_week": 2937908, "today": 516802, "this_year": 152547498 }, "higher_education": { "this_month": 3020137, "this_week": 877840, "today": 146909, "this_year": 51684841 }, "primary_and_secondary": { "this_month": 6357972, "this_week": 2055699, "today": 369134, "this_year": 100548883 }, "primary_and_lower_secondary": { "this_month": 3849200, "this_week": 1238792, "today": 220194, "this_year": 60916448 } } ``` ### Organization types The organization types are: * `all`: Covers all organizations. * `higher_education`: Covers higher education (university & university colleges). * `primary_and_lower_secondary`: Primary and lower secondary schools. (Norwegian: Barne- og ungdomsskoler.) * `upper_secondary`: Upper secondary schools. (Norwegian: Videregående skoler.) * `primary_and_secondary`: Covers primary, lower secondary and upper secondary schools. (Norwegian: Barneskoler, ungdomsskoler og videregående skoler.) *Note*: Some organizations in Feide cover both primary and lower secondary schools as well as upper secondary schools. This means that if you simply sum `primary_and_lower_secondary` with `upper_secondary`, you will be counting some logins twice, and get a larger number than `primary_and_secondary`. ### Time periods The time periods are: * `today`: Logins this far today. * `this_week`: Logins during the current week. * `this_month`: Logins this month. * `this_year`: Logins this year. The periods are adjusted to the [Europe/Oslo](https://en.wikipedia.org/wiki/Europe/Oslo) time zone. # Passkey administration This API provides endpoints for managing passkeys registered by users in your organization. You can list and delete passkeys for users in your own organization, allowing you to support user offboarding, security audits, and helpdesk support for lost or compromised devices. The endpoints are available at https://api.feide.no/2/passkey/ The `` parameter in all endpoints is the numeric organization ID from the Feide Customer Portal. ## Pagination The list endpoints return at most 1000 entries per response. When more entries exist, the response includes a `Link` header pointing to the next page: ```text Link: ; rel="next" ``` To retrieve all entries, follow the `Link` header URL until the response no longer contains one. The `offset` token in the URL is opaque, encrypted, short-lived (5 minutes), and bound to the original request URL — do not attempt to construct, modify, or reuse it across different queries. **Query parameters:** - `per_page` (optional): Page size, between 1 and 1000. Defaults to 1000. - `offset` (optional): Opaque continuation token from a previous response’s `Link` header. Do not set this manually. **Example:** ```bash # Fetch first page curl -i -H "Authorization: Bearer JWT_TOKEN" \ "https://api.feide.no/2/passkey/1234567" # Response includes a "Link: ; rel=\"next\"" header when more # entries exist. Follow it to get the next page: curl -i -H "Authorization: Bearer JWT_TOKEN" "" ``` ### List Passkeys for a User List all passkeys registered by a specific user within an organization. **Endpoint:** `GET /2/passkey/?eppn=` **Required scope:** `passkey.read` **Parameters:** - `org_id` (path, required): The organization’s numeric ID from the Customer Portal - `eppn` (query, required): The user’s eduPersonPrincipalName (e.g., `user@example.no`). The eppn’s realm must match the organization. Note: special characters in the URL must be URL-encoded (e.g., `@` as `%40`). - `per_page` (query, optional): See [Pagination](). - `offset` (query, optional): See [Pagination](). **Response fields:** - `id`: Internal unique identifier of the passkey. The same value is used in the path of the single-passkey delete endpoint. - `eppn`: The user the passkey belongs to. - `label`: User-supplied name for the passkey (e.g., “MacBook Pro”, “YubiKey”). Free-form text; does not necessarily reflect the authenticator’s actual model. - `created_at`: When the passkey was registered (ISO 8601). - `last_used_at`: When the passkey was most recently used to authenticate, or `null` if never used since registration. - `mfa_verified`: Whether the passkey is verified as a multi-factor credential. - `aaguid`: The Authenticator Attestation GUID — a stable identifier for the authenticator *model* (e.g. a specific YubiKey series), as defined by the FIDO2 spec. The all-zero UUID `"00000000-0000-0000-0000-000000000000"` means the authenticator did not provide one (common for some platform authenticators). AAGUIDs identify the device type, not the individual passkey. For a community-maintained mapping from AAGUID to human-readable provider names see [passkey-authenticator-aaguids](https://github.com/passkeydeveloper/passkey-authenticator-aaguids). **Response:** ```json [ { "id": 1, "eppn": "user@example.no", "label": "YubiKey 5", "created_at": "2024-01-15T10:30:00+00:00", "last_used_at": "2024-03-10T14:22:33+00:00", "mfa_verified": true, "aaguid": "cb69481e-8ff7-4039-93ec-0a2729a154a8" }, { "id": 2, "eppn": "user@example.no", "label": "Label for my passkey (set on innsyn)", "created_at": "2024-02-20T09:15:00+00:00", "last_used_at": null, "mfa_verified": false, "aaguid": "00000000-0000-0000-0000-000000000000" } ] ``` **Example:** ```bash curl -H "Authorization: Bearer JWT_TOKEN" \ "https://api.feide.no/2/passkey/1234567?eppn=user%40example.no" ``` ### List All Passkeys for your Organization List all passkeys for all users in your organization. Results are paginated; see [Pagination](). **Endpoint:** `GET /2/passkey/` **Required scope:** `passkey.read` **Parameters:** - `org_id` (path, required): The organization’s numeric ID from the Customer Portal - `per_page` (query, optional): See [Pagination](). - `offset` (query, optional): See [Pagination](). **Response:** Array of passkey objects (same format as user listing). When more entries exist, a `Link: ; rel="next"` header points to the next page. Fetch it by calling that URL exactly as returned, and repeat until a response no longer includes a `Link` header. The example below has only two pages for simplicity. **Example:** ```bash # First page curl -i -H "Authorization: Bearer JWT_TOKEN" \ "https://api.feide.no/2/passkey/1234567" # Next page: use the URL returned in the previous response's Link header curl -i -H "Authorization: Bearer JWT_TOKEN" \ "" ``` ### Delete All Passkeys for a User Delete all passkeys registered by a specific user. **Endpoint:** `DELETE /2/passkey/?eppn=` **Required scope:** `passkey.delete` **Parameters:** - `org_id` (path, required): The organization’s numeric ID from the Customer Portal - `eppn` (query, required): The user’s eduPersonPrincipalName. The eppn’s realm must match the organization. **Response:** ```json { "deleted_count": 3, "eppn": "user@example.no" } ``` **Example:** ```bash curl -X DELETE -H "Authorization: Bearer JWT_TOKEN" \ "https://api.feide.no/2/passkey/1234567?eppn=user%40example.no" ``` ### Delete a Single Passkey Delete a specific passkey by its unique ID. **Endpoint:** `DELETE /2/passkey//` **Required scope:** `passkey.delete` **Parameters:** - `org_id` (path, required): The organization’s numeric ID from the Customer Portal - `id` (path, required): The unique identifier of the passkey to delete (the `id` field returned by the list endpoints) **Response:** ```json { "deleted": true, "id": 6 } ``` **Example:** ```bash curl -X DELETE -H "Authorization: Bearer JWT_TOKEN" \ "https://api.feide.no/2/passkey/1234567/6" ``` ## Error Responses The API returns standard HTTP status codes with a JSON body containing `code` and `message`: - **200 OK:** Successful operation - **400 Bad Request:** Invalid eppn (missing `@`), missing required eppn parameter on DELETE, or invalid pagination parameters (`per_page` out of range, `offset` malformed/expired) - **401 Unauthorized:** Missing or invalid JWT token - **403 Forbidden:** Insufficient scopes, service not authorized for organization, or eppn realm does not match organization - **404 Not Found:** Organization or passkey does not exist - **405 Method Not Allowed:** Wrong HTTP method used Example error responses: ```json { "code": 403, "message": "Token must have all required scopes" } ``` ```json { "code": 403, "message": "Client not authorized for organization" } ``` ```json { "code": 403, "message": "eppn realm 'other.example.no' does not match organization" } ``` ```json { "code": 404, "message": "Passkey does not exist" } ``` ```json { "code": 400, "message": "Invalid 'offset' query parameter -- token has expired" } ``` ## Use Cases Common scenarios for using the Passkey Administration API: **User offboarding** When an employee leaves the organization, automatically remove all their passkeys so they can no longer use passkey-based login. Note that this does not revoke access through other login methods. ```bash # Delete all passkeys for departing user curl -X DELETE -H "Authorization: Bearer JWT_TOKEN" \ "https://api.feide.no/2/passkey/1234567?eppn=former.employee%40example.no" ``` **Security audit** Generate reports of passkey usage across your organization. Walk through all pages by following the `Link: ; rel="next"` header: ```bash # Fetch the first page; follow the Link header until none is returned curl -i -H "Authorization: Bearer JWT_TOKEN" \ "https://api.feide.no/2/passkey/1234567" ``` **Helpdesk support** Assist users who need to remove a lost or compromised device. ```bash # List user's passkeys to find the one to remove curl -H "Authorization: Bearer JWT_TOKEN" \ "https://api.feide.no/2/passkey/1234567?eppn=user%40example.no" # Delete the specific passkey curl -X DELETE -H "Authorization: Bearer JWT_TOKEN" \ "https://api.feide.no/2/passkey/1234567/6" ``` For details on how to gain access to these endpoints see [Feide login with Passkeys](../../../home_organizations/feide_login_with_passkeys.html.md). # Groups API A user belongs to a number of groups of various types. Types of groups include: - Groups which tell what classes, courses, etc. the user is taking part in or teaching. - Groups which tell what school or university the user is enrolled or employed at. - Ad hoc groups created by end users. * [Data model for groups](groups_data_model.html.md) * [Group types](group_types/index.html.md) * [Groups API endpoints](groups_endpoints.html.md) # Data model for groups There are two main object types in the groups API data model: - The group objects. - The membership objects. The specific fields available depends on the group type. See the [group types](group_types/index.html.md) for more details about the various groups and their available fields. ## Group objects Group objects are returned in the following contexts: - Fetching the groups of the current user. - Fetching the groups of an organization. - Fetching a specific group. In all cases, the group object has a common structure with some common fields. ### Example group ```json { "id": "fc:example:random-id", "type": "fc:example", "displayName": "Example group", "parent": "fc:example:parent-id", "membership": { "basic": "member" } } ``` ### Group fields The following fields are common to all group objects: `id` *(required, string)* : The identifier of the group. The structure of the identifier depends on the group type. `type` *(required, string)* : The group type. This is used to distinguish between different types of groups. `displayName` *(required, string)* : The name of the group. `parent` *(optional, string)* : The identifier of the parent group. This is used to build a hierarchy of groups. `membership` *(optional, object)* : The membership of the current user in the group. See the [membership object](#membership-object-model) for details about this structure.
**Note:** This field is only present when requesting groups for a specific user. ## Membership objects The membership object describes the relationship between a user and a group. It is returned in two different contexts: - When fetching a group in the context of a user. In that case, the `membership` field is present in the group object. - When fetching a list of members of a group. ### Example membership ```json { "basic": "member", "displayName": "Student" } ``` ### Membership fields The following fields are common to all membership objects: `basic` *(required, string)* : The basic membership type. This is one of the following values:
- `member`: Regular members. - `admin`: Abstract role of super members, having some kind of additional permissions. For example, the admin may invite or add other members, moderate content in a group or anything else. - `owner`: Only used for [ad-hoc groups](group_types/adhoc.html.md), where this is the creator of the group. `displayName` *(optional, string/object)* : A human readable description of the membership type.
**Note:** This field is usually a plain string, but it can in rare cases be an object with translations. See the individual group types for details about the contents of this field. # Group types The available groups depend on the organization type. ## Primary, lower secondary and upper secondary education For primary and secondary education, we have the following group types: - [School owner](pse_school_owner.html.md): Each user is associated with a single school owner. For primary and lower secondary schools, this is usually the municipality. For upper secondary schools, this is usually the county. - [School](pse_school.html.md): Each user can be associated with one or more schools. - [Basis group](pse_basis.html.md): A group of students who are taught together. This typically represents a class (e.g. 10A). The basis group also contains one or more contact teachers (“kontaktlærere”) for the students. - [Teaching group](pse_teaching.html.md): A group of students who are taught together in a specific subject. Also contains the teacher. - [Other education group](pse_other.html.md): Other groups that are used to organize the students and teachers. - [Grep group](pse_grep.html.md): Groups representing subjects, curricula, etc. from the [national Grep database](https://www.udir.no/om-udir/data/kl06-grep/). ## Higher education For higher education, research institutions, etc. we have the following group types: - [Organization](he_organization.html.md): Each user is associated with a single organization. - [Organization unit](he_organization_unit.html.md): The organization can register various organization units. Can be used to represent faculties, institutes, departments, etc. If the organization is using Felles Studentsystem (FS) and has enabled the FS integration, the following group types are also available: - [Program of study (studieprogram)](fs_program_of_study.html.md): The program of study the student is enrolled in. - [Cohort (kull)](fs_cohort.html.md): A group of students enrolled in a program of study at the same time. - [Class (klasse)](fs_class.html.md): A group of students in a cohort. - [Course (emne)](fs_course.html.md): A particular course / subject the student is taking. - [Field of study (studieretning)](fs_field_of_study.html.md): A specialization, typically within a program of study. ## Common groups Some groups are available for all organization types: - [Ad hoc group](adhoc.html.md): Groups created by end users. # School owner group All Feide user accounts are associated with a single school owner. The school owner group contains information about the school owner. #### NOTE Both school owner and school groups have the same `type` attribute (`fc:org`). To recognize a school owner group, check for a `parent` attribute. Only schools have a `parent` attribute. ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-org` attribute group / scope. Organization type : This group type is available for primary, lower secondary and upper secondary schools. Member list : - It is possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is not possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:org:eksempel.kommune.no", "type": "fc:org", "displayName": "Eksempel kommune", "membership": { "basic": "admin", "displayName": "Lærer", "affiliation": ["member", "employee", "faculty"] }, "public": false, "orgType": ["primary_and_lower_secondary_owner"], "eduOrgLegalName": "Eksempel kommune", "norEduOrgNIN": "NO123456789", "mail": "post@eksempel.kommune.no" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. This is a string with the format `fc:org:`. `` is the domain name of the school owner. `type` *(required, string)* : The group type. Always the string `fc:org` for school owner groups. `displayName` *(required, string)* : The name of the organization. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `public` *(required, boolean)* : Whether this group is included in the list of public groups. This is always `false` for school owner groups. `orgType` *(required, list of strings)* : A list of organization types for this school owner. The list can have the following values:
- `primary_and_lower_secondary_owner`: The school owner has primary and lower secondary schools. (This is common for municipalities.) - `upper_secondary_owner`: The school owner has upper secondary schools. (This is common for counties.)
For most organizations this list contains a single entry, but some organizations (e.g. Oslo kommune) have multiple types. `eduOrgLegalName` *(required, string)* : The official name of the organization.
It contains the `eduOrgLegalName` attribute in the [organization object](../../../schema/info_go/go_attributter_ch03.html.md) in the organization’s user directory. `norEduOrgNIN` *(required, string)* : The organization number of the school owner. This is the organization number from the Brønnøysund Register Centre (Brønnøysundregisteret), prefixed with `NO`.
It contains the `norEduOrgNIN` attribute in the [organization object](../../../schema/info_go/go_attributter_ch03.html.md) in the organization’s user directory. `mail` *(required, string)* : The email address of the organization.
It contains the `mail` attribute in the [organization object](../../../schema/info_go/go_attributter_ch03.html.md) in the organization’s user directory. ## Optional group fields The following additional fields may be included from the [organization object](../../../schema/info_go/go_attributter_ch03.html.md) in the organization’s user directory: These fields are optional. If they are present, they will contain a single string. - `eduOrgHomePageURI` - `eduOrgIdentityAuthNPolicyURI` - `eduOrgWhitePagesURI` - `facsimileTelephoneNumber` - `l` - `labeledURI` - `norEduOrgAcronym` - `norEduOrgUniqueIdentifier` - `postalAddress` - `postalCode` - `postOfficeBox` - `street` - `telephoneNumber` ## Membership objects The membership object describes the role of the user at the school owner. ```json { "basic": "admin", "displayName": "Lærer", "affiliation": ["member", "employee", "faculty"], "primaryAffiliation": "employee", "title": ["Lærer"] } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is a string with one of the following values:
- `admin`: For employees at the organization. - `member`: If the user is not an employee. (E.g. students.)
This field is derived from the `affiliation` field. A user is considered an employee if the `affiliation` list contains the `employee` value. `displayName` *(required, string)* : A human-readable membership type. This field is derived from the `affiliation` field.
It contains a plain string. Typical values are:
- `Lærer` - `Stab` - `Ansatt` - `Elev` `affiliation` *(required, list of strings)* : A list of affiliations for the user. Teachers commonly have the values `member`, `employee`, and `faculty`. Students have `member` and `student`. Staff have `member`, `employee`, and `staff`.
#### NOTE A user can be both student and teacher at the same time. In this case, the user has both the `student` and `faculty` affiliations:
```json { "basic": "admin", "displayName": "Lærer", "affiliation": ["member", "employee", "faculty", "student"] } ``` `primaryAffiliation` *(optional, string)* : The primary affiliation of the user. This will be one of the values in the `affiliation` list.
This field is only present if the user has the `eduPersonPrimaryAffiliation` attribute in the organization’s user directory. `title` *(optional, list of strings)* : The job title of the user. If the field is present, it will be a list with one or more strings.
This field is only present if the user has the `title` attribute in the organization’s user directory. # School group A Feide user account is associated with one or more schools. Each school group contains information about the school. #### NOTE Both school owner and school groups have the same `type` attribute (`fc:org`). To recognize a school group, check for a `parent` attribute. Only schools have a `parent` attribute. ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-org` attribute group / scope. Organization type : This group type is available for primary, lower secondary and upper secondary schools. Member list : - It is possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is not possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:org:eksempel.kommune.no:unit:NO987654321", "type": "fc:org", "displayName": "Eksempelskolen", "membership": { "basic": "member", "primarySchool": true }, "public": false, "orgType": ["primary_and_lower_secondary"], "parent": "fc:org:eksempel.kommune.no" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. Has the format `fc:org::unit:`. `` is the domain name of the school owner. `` is the organization number of the school, prefixed with `NO`.
#### NOTE Some schools abroad do not have a Norwegian organization number. Instead they use an identifier like U87654321. This identifier comes from the [national school register (NSR)](https://nsr.udir.no). `type` *(required, string)* : The group type. Always `fc:org` for school groups. `displayName` *(required, string)* : The name of the school. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `public` *(required, boolean)* : Whether this group is included in the list of public groups. Always `false` for school groups. `orgType` *(required, list of strings)* : A list of organization types for this school. This list can have the following values:
- `primary_and_lower_secondary`: The school is a primary or lower secondary school. - `upper_secondary`: The school is an upper secondary school.
For most schools this list contains a single entry. However, due to limitations in our data model, we include multiple values when the school owner has multiple types. E.g.: For Oslo kommune, all schools will have both `primary_and_lower_secondary` and `upper_secondary`. `parent` *(required, string)* : The group identifier of the school owner. ## Membership objects The membership object describes the role of the user at the school. ```json { "basic": "member", "primarySchool": true } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is always `member`. `primarySchool` *(required, boolean)* : Whether this is the primary school of the user.
This is derived from the `eduPersonPrimaryOrgUnitDN` attribute in the [user object](../../../schema/info_go/go_attributter_ch02.html.md) in the organization’s user directory. # Basis group A basis group (basisgruppe) represents a group of students who are taught together. This typically represents a class (e.g. 10A). The basis group also contains one or more contact teachers (“kontaktlærere”) for the students. ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-edu` attribute group / scope. Organization type : This group type is available for primary, lower secondary and upper secondary schools. Member list : - It is possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:gogroup:eksempel.kommune.no:b:NO987654321:3a:2000-07-01:2100-06-30", "type": "fc:gogroup", "displayName": "3A", "membership": { "basic": "member", "displayName": "Elev", "affiliation": "student" }, "notBefore": "2000-06-30T22:00:00Z", "notAfter": "2100-06-30T22:00:00Z", "go_type": "b", "parent": "fc:gogroup:eksempel.kommune.no:unit:NO987654321", "go_type_displayName": "basisgruppe" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. Has the format `fc:gogroup::b::::`. `` is the domain name of the school owner. `` is the organization number of the school or the organization number of the school owner. In both cases it is prefixed with `NO`. `` is the local identifier of the group at the school owner. `` and `` contain the first and last date the group the group is active. `type` *(required, string)* : The group type. Always `fc:gogroup` for basis groups.
#### NOTE There are multiple groups with the type `fc:gogroup`. To recognize a basis group, check for both `"type": "fc:gogroup"` and `"go_type": "b"`. `displayName` *(required, string)* : A human readable name for the group. E.g. `3A`, `Klasse 3A`, `3. klasse`, etc. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `notBefore` *(required, string)* : The timestamp when the group became active / valid. This is typically before the school year. `notAfter` *(required, string)* : The timestamp when the group is no longer active / valid. This is typically after the end of the school year. `go_type` *(required, string)* : The group type code. Always `b` for basis groups. `parent` *(required, string)* : The group identifier of the school or school owner this group belongs to. This is usually a school, but it is possible to have basis groups that are not part of a specific school. In that case the parent is the school owner. `go_type_displayName`: *(required, string)* : A human readable name for the group type. Always `basisgruppe` for basis groups. ## Membership object The membership object contains information about the user’s role in the basis group. ```json { "basic": "member", "displayName": "Elev", "affiliation": "student" } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is a string with one of the following values:
- `admin`: For teachers in the group. - `member`: For students in the group. `affiliation` *(required, string)* : The user’s affiliation to this group. Common values are:
- `student`: For students in the group. - `faculty`: For teachers in the group. `displayName` *(required, string/object)* : A human-readable version of the `affiliation` field.
This field is either a plain string or a JSON object with different translations. The JSON object contains the language code as key and the translation as value.
It will be returned as a plain string in most cases, but will be returned as a JSON object when retrieving group member lists. # Teaching group A group of students who are taught together in a specific subject. This group also contains the teacher of the subject. A typical example can be “Mathematics 3A”, i.e. the students in class 3A and the teacher of mathematics. ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-edu` attribute group / scope. Organization type : This group type is available for primary, lower secondary and upper secondary schools. Member list : - It is possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:gogroup:eksempel.kommune.no:u:NO987654321:3a-matte:2000-07-01:2100-06-30", "type": "fc:gogroup", "displayName": "Matte 3A", "membership": { "basic": "member", "displayName": "Elev", "affiliation": "student" }, "notBefore": "2000-06-30T22:00:00Z", "notAfter": "2100-06-30T22:00:00Z", "go_type": "u", "parent": "fc:gogroup:eksempel.kommune.no:unit:NO987654321", "go_type_displayName": "undervisningsgruppe", "grep": { "displayName": "Matematikk 3. årstrinn", "code": "MAT0003" } } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. Has the format `fc:gogroup::u::::`. `` is the domain name of the school owner. `` is the organization number of the school or the organization number of the school owner. In both cases it is prefixed with `NO`. `` is the local identifier of the group at the school owner. `` and `` contain the first and last date the group the group is active. `type` *(required, string)* : The group type. Always `fc:gogroup` for teaching groups.
#### NOTE There are multiple groups with the type `fc:gogroup`. To recognize a teaching group, check for both `"type": "fc:gogroup"` and `"go_type": "u"`. `displayName` *(required, string)* : A human readable name for the group. E.g. `Matte 3A`. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `notBefore` *(required, string)* : The timestamp when the group became active / valid. This is typically before the school year. `notAfter` *(required, string)* : The timestamp when the group is no longer active / valid. This is typically after the end of the school year. `go_type` *(required, string)* : The group type code. Always `u` for teaching groups. `parent` *(required, string)* : The group identifier of the school or school owner this group belongs to. This is usually a school, but it is possible to have basis groups that are not part of a specific school. In that case the parent is the school owner. `go_type_displayName` *(required, string)* : A human readable name for the group type. Always `undervisningsgruppe` for teaching groups. `grep` *(required, object)* : A JSON object with information about the subject from the Grep database. This JSON object contains two fields:
`displayName` *(required, string)* : A human readable name of the subject. This is derived from the `tittel` field in the Grep database.
`code` *(required, string)* : The Grep code of the subject. This is the `kode` field in the Grep database. ## Membership object The membership object contains information about the user’s role in the teaching group. ```json { "basic": "member", "displayName": "Elev", "affiliation": "student" } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is a string with one of the following values:
- `admin`: For teachers in the group. - `member`: For students in the group. `affiliation` *(required, string)* : The user’s affiliation to this group. Common values are:
- `student`: For students in the group. - `faculty`: For teachers in the group. `displayName` *(required, string/object)* : A human-readable version of the `affiliation` field.
This field is either a plain string or a JSON object with different translations. The JSON object contains the language code as key and the translation as value.
It will be returned as a plain string in most cases, but will be returned as a JSON object when retrieving group member lists. # Other education group In addition to creating groups for classes and courses, schools can create groups for other purposes. These groups can be used for any purpose and there is no set structure for the groups. For example, these can be created for a group of students working together on a project. ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-edu` attribute group / scope. Organization type : This group type is available for primary, lower secondary and upper secondary schools. Member list : - It is possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:gogroup:eksempel.kommune.no:a:NO987654321:grp_5738:2000-07-01:2100-06-30", "type": "fc:gogroup", "displayName": "Example group", "membership": { "basic": "member", "displayName": "Elev", "affiliation": "student" }, "notBefore": "2000-06-30T22:00:00Z", "notAfter": "2100-06-30T22:00:00Z", "go_type": "a", "parent": "fc:gogroup:eksempel.kommune.no:unit:NO987654321", "go_type_displayName": "andre grupper" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. Has the format `fc:gogroup::a::::`. `` is the domain name of the school owner. `` is the organization number of the school or the organization number of the school owner. In both cases it is prefixed with `NO`. `` is the local identifier of the group at the school owner. `` and `` contain the first and last date the group the group is active. `type` *(required, string)* : The group type. Always `fc:gogroup` for other groups.
#### NOTE There are multiple groups with the type `fc:gogroup`. To recognize an other education group, check for both `"type": "fc:gogroup"` and `"go_type": "a"`. `displayName` *(required, string)* : A human readable name for the group. E.g. `Example group`. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `notBefore` *(required, string)* : The timestamp when the group became active / valid. This is typically before the school year. `notAfter` *(required, string)* : The timestamp when the group is no longer active / valid. This is typically after the end of the school year. `go_type` *(required, string)* : The group type code. Always `a` for other education groups. `parent` *(required, string)* : The group identifier of the school or school owner this group belongs to. This is usually a school, but it is possible to have basis groups that are not part of a specific school. In that case the parent is the school owner. `go_type_displayName` *(required, string)* : A human readable name for the group type. Always `andre grupper` for other education groups. ## Membership object The membership object contains information about the user’s role in the group. ```json { "basic": "member", "displayName": "Elev", "affiliation": "student" } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is a string with one of the following values:
- `admin`: For teachers in the group. - `member`: For students in the group. `affiliation` *(required, string)* : The user’s affiliation to this group. Common values are:
- `student`: For students in the group. - `faculty`: For teachers in the group. `displayName` *(required, string/object)* : A human-readable version of the `affiliation` field.
This field is either a plain string or a JSON object with different translations. The JSON object contains the language code as key and the translation as value.
It will be returned as a plain string in most cases, but will be returned as a JSON object when retrieving group member lists. # Grep group Groups representing subjects, curricula, etc. from the [national Grep database](https://www.udir.no/om-udir/data/kl06-grep/). ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-edu` attribute group / scope. Organization type : This group type is available for primary, lower secondary and upper secondary schools. Member list : - It is possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is not possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Versions There are two versions of the Grep groups. These can be distinguished based on the `type` field. The only difference between the versions is the structure of the `id` field. The `fc:grep` groups are used when accessing the [user groups API](../groups_endpoints.html.md#user-groups-apis). The `fc:grep2` groups are used when accessing the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). ## Example For type `fc:grep`: ```json { "id": "fc:grep:http:__psi.udir.no_laereplan_aarstrinn_aarstrinn3", "type": "fc:grep", "displayName": "Tredje årstrinn", "membership": { "basic": "member" }, "public": true, "grep_type": "aarstrinn", "code": "aarstrinn3" } ``` For type `fc:grep2`: ```json { "id": "fc:grep2:eksempel.kommune.no:http%3A%2F%2Fpsi.udir.no%2Flaereplan%2Faarstrinn%2Faarstrinn3", "type": "fc:grep2", "displayName": "Tredje årstrinn", "membership": { "basic": "member" }, "public": true, "grep_type": "aarstrinn", "code": "aarstrinn3" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. The format of this field depends on the group type.
For `fc:grep` groups, the format is `fc:grep:`. `` is the `id` of the Grep object, with `/` replaced with `_`.
For `fc:grep2` groups, the format is `fc:grep2::`. `` is the domain name of the school owner. `` is the urlencoded `id` of the Grep object. `type` *(required, string)* : The group type. `fc:grep` or `fc:grep2`, depending on the API used to access the groups. `displayName` *(required, string)* : A human readable name for the group. This field is comes from the `tittel` field in the Grep database. E.g. `Tredje årstrinn`. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `public` *(required, boolean)* : Whether the group is included in the list of public groups. Always `true` for Grep groups. `grep_type` *(required, string)* : The type of Grep entry. Possible values are `fagkoder`, `programomraader`, `utdanningsprogram` and `aarstrinn`. Here is a [complete list](https://github.com/Utdanningsdirektoratet/KL06-LK20-public/wiki/liste-over-alle-typene-i-Grep). `code` *(required, string)* : The short form Grep code of a Grep entry. This filed comes from the `kode` field in the Grep database. E.g.: `SAF0001`. ## Membership object The membership object contains information about the user’s role in the Grep group. ```json { "basic": "member" } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is always `member` for Grep groups. # Organization group The user’s organization. #### NOTE This matches the school owner group <./go_school_owner> for primary and secondary education. ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-org` attribute group / scope. Organization type : This group type is available for higher education. Member list : - It is possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is not possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:org:example.org", "type": "fc:org", "displayName": "Eksempeluniversitetet", "membership": { "basic": "admin", "displayName": "Akademisk ansatt", "affiliation": [ "member", "employee", "faculty" ], "primaryAffiliation": "employee" }, "public": false, "orgType": [ "higher_education" ], "eduOrgLegalName": "Eksempeluniversitetet AS", "mail": "mail@example.org", "norEduOrgNIN": "NO123456789" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. This is a string with the format `fc:org:`. `` is the domain name of the school owner. `type` *(required, string)* : The group type. Always the string `fc:org` for organizations in higher education. `displayName` *(required, string)* : The name of the organization. This is a string. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `public` *(required, boolean)* : Whether this group is included in the list of public groups. This is always `false` for organizations in higher education. `orgType` *(required, list of strings)* : A list of organization types for this organization. For organizations in higher education, this is always `["higher_education"]`. `eduOrgLegalName` *(required, string)* : The official name of the organization.
It contains the `eduOrgLegalName` attribute in the [organization object](../../../schema/info_go/go_attributter_ch03.html.md) in the organization’s user directory. `norEduOrgNIN` *(required, string)* : The organization number of the organization. This is the organization number from the Brønnøysund Register Centre (Brønnøysundregisteret), prefixed with `NO`.
It contains the `norEduOrgNIN` attribute in the [organization object](../../../schema/info_go/go_attributter_ch03.html.md) in the organization’s user directory. `mail` *(required, string)* : The email address of the organization.
It contains the `mail` attribute in the [organization object](../../../schema/info_go/go_attributter_ch03.html.md) in the organization’s user directory. ## Optional group fields The following additional fields may be included from the [organization object](../../../schema/info_go/go_attributter_ch03.html.md) in the organization’s user directory: These fields are optional. If they are present, they will contain a single string. * `eduOrgHomePageURI` * `eduOrgIdentityAuthNPolicyURI` * `eduOrgWhitePagesURI` * `facsimileTelephoneNumber` * `l` * `labeledURI` * `norEduOrgAcronym` * `norEduOrgUniqueIdentifier` * `postalAddress` * `postalCode` * `postOfficeBox` * `street` * `telephoneNumber` ## Membership objects The membership object describes the role of the user at the organization. ```json { "basic": "admin", "displayName": "Akademisk ansatt", "affiliation": [ "member", "employee", "faculty" ], "primaryAffiliation": "employee" } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is a string with one of the following values:
- `admin`: For employees at the organization. - `member`: If the user is not an employee. (E.g. students.)
This field is derived from the `affiliation` field. A user is considered an employee if the `affiliation` list contains the `employee` value. `displayName` *(required, string)* : A human-readable membership type. This field is derived from the `affiliation` field.
It contains a plain string. Typical values are:
- `Akademisk ansatt` - `Stab` - `Ansatt` - `Student` `affiliation` *(required, list of strings)* : A list of affiliations for the user. Faculty commonly have the values `member`, `employee`, and `faculty`. Students have `member` and `student`. Staff have `member`, `employee`, and `staff`.
#### NOTE A user can be both student and faculty at the same time. In this case, the user has both the `student` and `faculty` affiliations:
```json { "basic": "admin", "displayName": "Akademisk ansatt", "affiliation": [ "member", "employee", "faculty", "student", ] } ``` `primaryAffiliation` *(optional, string)* : The primary affiliation of the user. This will be one of the values in the `affiliation` list.
This field is only present if the user has the `eduPersonPrimaryAffiliation` attribute in the organization’s user directory. `title` *(optional, list of strings)* : The job title of the user. If the field is present, it will be a list with one or more strings.
This field is only present if the user has the `title` attribute in the organization’s user directory. # Organization unit group Information about organization units in higher education. These groups can provide information about organization units in higher education, such as institutes, faculties, departments, etc. #### NOTE it is not mandatory to register organization units for higher education organizations, so this information will not be available for many users. ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-org` attribute group / scope. Organization type : This group type is available for higher education. Member list : - It is possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is not possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:org:example.org:unit:A42", "type": "fc:orgunit", "displayName": "Institutt for oddetallsfag", "membership": { "basic": "member", "primaryOrgUnit": false }, "public": false, "parent": "fc:org:example.org" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. This is a string with the format `fc:org::unit:`. `` is the domain name of the organization. `` is identifier of the organization unit. `type` *(required, string)* : The group type. Always the string `fc:orgunit` for organization units in higher education. `displayName` *(required, string)* : The name of the organization uit. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `public` *(required, boolean)* : Whether this group is included in the list of public groups. This is always `false` for organization units in higher education. `parent` *(required, string)* : The `id` of the parent organization group. ## Membership objects The membership object describes the role of the user at the organization unit. ```json { "basic": "member", "primaryOrgUnit": true } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is always `member`. `primaryOrgUnit` *(required, boolean)* : Whether this is the primary organization unit of the user.
This is derived from the `eduPersonPrimaryOrgUnitDN` attribute in the [user object](../../../schema/info_go/go_attributter_ch02.html.md) in the organization’s user directory. # FS program of study Group representing a program of study (studieprogram) in Felles Studentsystem (FS). ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-edu` attribute group / scope. Organization type : This group type is available for higher education, where the organization has enabled the integration with Felles Studentsystem (FS). Member list : - It is not possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is not possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:fs:fs:prg:example.org:RF", "type": "fc:fs:prg", "displayName": "Rare fag", "membership": { "basic": "member", "active": true, "displayName": "Student", "fsroles": [ "STUDENT" ], "notBefore": "2024-07-30T22:00:00Z", "notAfter": "2025-07-30T22:00:00Z" }, "url": "https://www.example.org/prg/rare-fag" "parent": "fc:org:example.org" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. This is a string with the format `fc:fs:fs:prg::`. `` is the domain name of the organization. `` is the identifier of the program of study. `type` *(required, string)* : The group type. Always the string `fc:fs:prg` for program of study groups. `displayName` *(required, string)* : The name of the program of study. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `url` *(optional, string)* : An URL to a description of the program of study. `parent` *(required, string)* : The `id` of the parent group. This is the group for entire organization. ## Membership objects The membership object describes the role of the user in the program of study. ```json { "basic": "member", "active": true, "displayName": "Student", "fsroles": [ "STUDENT" ], "notBefore": "2024-07-30T22:00:00Z", "notAfter": "2025-07-30T22:00:00Z" } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is a string with one of the following values:
- `owner`: For instructors, etc in the program of study. - `member`: For students in the program of study. `active` *(required, boolean)* : Whether the user is currently active in the group. `displayName` *(required, string)* : A human readable descriptive name of the affiliation to the group. `fsroles` *(required, list of strings)* : A list of roles from Felles studentsystem. E.g. `["STUDENT"]`. `notBefore` *(optional, string)* : The date/time when the membership started. `notAfter` *(optional, string)* : The date/time when the membership ended. # FS cohort Group representing a cohort (kull) in a program of study (studieprogram). ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-edu` attribute group / scope. Organization type : This group type is available for higher education, where the organization has enabled the integration with Felles Studentsystem (FS). Member list : - It is not possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is not possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:fs:fs:kull:example.org:RF:2024H", "type": "fc:fs:kull", "displayName": "Kull for høst 2024 Rare fag", "membership": { "basic": "member", "active": true, "displayName": "Student", "fsroles": [ "STUDENT" ], "notBefore": "2024-07-30T22:00:00Z", "notAfter": "2025-07-30T22:00:00Z" }, "parent": "fc:fs:fs:prg:RF" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. This is a string with the format `fc:fs:fs:kull:::`. `` is the domain name of the organization. `` is the identifier of the program of study. `` is the identifier of the cohort within the program of study. `type` *(required, string)* : The group type. Always the string `fc:fs:prg` for program of study groups. `displayName` *(required, string)* : The name of the cohort. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `parent` *(required, string)* : The `id` of the parent group. This is the group for the program of study. ## Membership objects The membership object describes the role of the user in the cohort. ```json { "basic": "member", "active": true, "displayName": "Student", "fsroles": [ "STUDENT" ], "notBefore": "2024-07-30T22:00:00Z", "notAfter": "2025-07-30T22:00:00Z" } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is a string with one of the following values:
- `member`: For students in the cohort. `active` *(required, boolean)* : Whether the user is currently active in the group. `displayName` *(required, string)* : A human readable descriptive name of the affiliation to the group. `fsroles` *(required, list of strings)* : A list of roles from Felles studentsystem. E.g. `["STUDENT"]`. `notBefore` *(optional, string)* : The date/time when the membership started. `notAfter` *(optional, string)* : The date/time when the membership ended. # FS class Group representing a class (klasse) within a cohort (kull) in a program of study (studieprogram). ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-edu` attribute group / scope. Organization type : This group type is available for higher education, where the organization has enabled the integration with Felles Studentsystem (FS). Member list : - It is not possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is not possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:fs:fs:klasse:example.org:RF:2024H:A", "type": "fc:fs:klasse", "displayName": "Klasse Rare fag A høst 2024", "membership": { "basic": "member", "active": true, "displayName": "Student", "fsroles": [ "STUDENT" ], "notBefore": "2024-07-30T22:00:00Z", "notAfter": "2025-07-30T22:00:00Z" }, "parent": "fc:fs:fs:kull:example.org:RF:2024H" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. This is a string with the format `fc:fs:fs:klasse::::`. `` is the domain name of the organization. `` is the identifier of the program of study. `` is the identifier of the cohort within the program of study. `` is the identifier of the class within the cohort. `type` *(required, string)* : The group type. Always the string `fc:fs:klasse` for classes. `displayName` *(required, string)* : The name of the class. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `parent` *(required, string)* : The `id` of the parent group. This is the group for the cohort within the program of study. ## Membership objects The membership object describes the role of the user in the class. ```json { "basic": "member", "active": true, "displayName": "Student", "fsroles": [ "STUDENT" ], "notBefore": "2024-07-30T22:00:00Z", "notAfter": "2025-07-30T22:00:00Z" } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is a string with one of the following values:
- `owner`: For instructors, etc in the class. - `member`: For students in the class. `active` *(required, boolean)* : Whether the user is currently active in the group. `displayName` *(required, string)* : A human readable descriptive name of the affiliation to the group. `fsroles` *(required, list of strings)* : A list of roles from Felles studentsystem. E.g. `["STUDENT"]`. `notBefore` *(optional, string)* : The date/time when the membership started. `notAfter` *(optional, string)* : The date/time when the membership ended. # FS course A group for students and instructors in a particular course / subject. ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-edu` attribute group / scope. Organization type : This group type is available for higher education, where the organization has enabled the integration with Felles Studentsystem (FS). Member list : - It is not possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is not possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:fs:fs:emne:example.org:OTF5913:A", "type": "fc:fs:emne", "displayName": "Bruk av oddetall", "membership": { "basic": "member", "active": true, "displayName": "Student", "fsroles": [ "STUDENT" ], "notBefore": "2024-07-30T22:00:00Z", "notAfter": "2025-07-30T22:00:00Z", "subjectRelations": "undervisning" }, "url": "https://www.example.org/emne/otf5913", "parent": "fc:org:example.org" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. This is a string with the format `fc:fs:fs:emne:::`. `` is the domain name of the organization. `` is the code for the course. `` identifies a particular version of the course. `type` *(required, string)* : The group type. Always the string `fc:fs:emne` for courses. `displayName` *(required, string)* : The name of the course. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `url` *(optional, string)* : An URL to a description of the course. `parent` *(required, string)* : The `id` of the parent group. This is the organization group. ## Membership objects The membership object describes the role of the user in the course. ```json { "basic": "member", "active": true, "displayName": "Student", "fsroles": [ "STUDENT" ], "notBefore": "2024-07-30T22:00:00Z", "notAfter": "2025-07-30T22:00:00Z", "subjectRelations": "undervisning" } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is a string with one of the following values:
- `owner`: For instructors, etc in the course. - `member`: For students in the course. `active` *(required, boolean)* : Whether the user is currently active in the group. `displayName` *(required, string)* : A human readable descriptive name of the affiliation to the group. `fsroles` *(required, list of strings)* : A list of roles from Felles studentsystem. E.g. `["STUDENT"]`. `notBefore` *(optional, string)* : The date/time when the membership started. `notAfter` *(optional, string)* : The date/time when the membership ended. `subjectRelations` *(required, string)* : The relation of the user to the course. One or both of the following values:
- `undervisning` - `vurdering`
(If both values are present, they are separated by a comma.) # FS field of study Group representing a field of study (studieretning) in Felles Studentsystem (FS). ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-edu` attribute group / scope. Organization type : This group type is available for higher education, where the organization has enabled the integration with Felles Studentsystem (FS). Member list : - It is not possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is not possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:fs:fs:str:example.org:KS", "type": "fc:fs:str", "displayName": "Kompliserte studier", "membership": { "basic": "member", "active": true, "displayName": "Student", "fsroles": [ "STUDENT" ], "notBefore": "2024-07-30T22:00:00Z", "notAfter": "2025-07-30T22:00:00Z" }, "parent": "fc:org:example.org" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. This is a string with the format `fc:fs:fs:str::`. `` is the domain name of the organization. `` is the identifier of the field of study. `type` *(required, string)* : The group type. Always the string `fc:fs:str` for field of study groups. `displayName` *(required, string)* : The name of the program of study. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `parent` *(required, string)* : The `id` of the parent group. This is the group for entire organization. ## Membership objects The membership object describes the role of the user in the field of study. ```json { "basic": "member", "active": true, "displayName": "Student", "fsroles": [ "STUDENT" ], "notBefore": "2024-07-30T22:00:00Z", "notAfter": "2025-07-30T22:00:00Z" } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is a string with one of the following values:
- `owner`: For instructors, etc in the field of study. - `member`: For students in the field of study. `active` *(required, boolean)* : Whether the user is currently active in the group. `displayName` *(required, string)* : A human readable descriptive name of the affiliation to the group. `fsroles` *(required, list of strings)* : A list of roles from Felles studentsystem. E.g. `["STUDENT"]`. `notBefore` *(optional, string)* : The date/time when the membership started. `notAfter` *(optional, string)* : The date/time when the membership ended. # Ad hoc groups Ad hoc groups allow end users to create their own groups. These groups can consist of users within one organization, or they can consist of users across organizations. ## Availability Attribute group : To retrieve these groups, the application needs access to the `groups-other` attribute group / scope. Organization type : This group type is available for all organization types. Member list : - It is not possible to list the members in this group through the [organization groups API](../groups_endpoints.html.md#organization-groups-apis). - It is possible to list the members in this group through the [user groups API](../groups_endpoints.html.md#user-groups-apis). ## Example ```json { "id": "fc:adhoc:b492111d-97f0-48ec-a492-ef0724eae3b5", "type": "voot:ad-hoc", "displayName": "Example group", "membership": { "basic": "member" }, "public": true, "description": "This is an example group" } ``` ## Group object The group objects has the following fields: `id` *(required, string)* : Unique identifier of the group. Has the format `fc:adhoc:`. `` is an UUID that identifies the group. `type` *(required, string)* : The group type. Always `voot:ad-hoc` for ad hoc groups. `displayName` *(required, string)* : The name of the group. `membership` *(optional, object)* : The role of the current user in the group. This field is only present when requesting groups for a specific user. `public` *(optional, boolean)* : Whether this group is included in the list of public groups. This is `true` if the group is public. If the group is not public, this field is absent. `description` *(optional, string)* : A description of the group. This field is absent if there is no description. ## Membership objects The membership object describes the role of the user in the ad hoc group. ```json { "basic": "member" } ``` It has the following fields: `basic` *(required, string)* : The basic membership role of the user. This field is a string with one of the following values:
- `owner`: The owner of the group. - `admin`: Administrators of the group. - `member`: Other users in the group. # Groups API endpoints The protocol is a simple, lightweight REST-ish protocol. The group endpoints require that you provide a valid access token with scopes for appropriate attribute groups. `groups-edu`, `groups-org` and `groups-other` are attribute groups for different kinds of groups. - [How to obtain a Feide OIDC/OAuth Token](../../../service_providers/openid_connect/feide_obtaining_tokens.html.md) - [Read more about the various Feide attribute groups](../../schema/attributegroups/index.html.md) The base URL prefix of all group related endpoints on Feide is: `https://groups-api.dataporten.no/groups` The group API is divided into three sections: - [User groups APIs](#user-groups-apis) - [Organization groups APIs](#organization-groups-apis) - [Other group APIs](#other-group-apis) ## List of group protocol endpoints | Endpoint | Protocol description | Data returned | |----------------------------------------------------------------------|-------------------------------------------------------------------------|-----------------------| | [/me/groups](#me-groups) | Group memberships of the current user | List of groups | | [/me/groups/{groupid}](#me-membership) | My membership of this particular group | One membership object | | [/groups/{groupid}](#group-details) | Details about a group | One group object | | [/groups/{groupid}/members](#group-members) | Members of a group | A list of users | | [/groups](#groups-list) | List all groups | A list of groups | | [/v1/orgs/{domain}/groups/{groupid}](#orgs-group-details) | Details about a group at the given organization by domain name | One group object | | [/v1/orgs/{domain}/groups/{groupid}/members](#orgs-group-members) | All members of a group at the given organization by domain name | A list of users | | [/v1/orgs/{domain}/groups](#orgs-groups-list) | List all groups at the given organization by domain name | A list of groups | | [/v1/by-orgno/{orgno}/groups/{groupid}](#orgs-group-details) | Details about a group at the given organization by organization number | One group object | | [/v1/by-orgno/{orgno}/groups/{groupid}/members](#orgs-group-members) | All members of a group at the given organization by organization number | A list of users | | [/v1/by-orgno/{orgno}/groups](#orgs-groups-list) | List all groups at the given organization by organization number | A list of groups | | [/grouptypes](#group-types) | List all group types | A list of group types | ## User groups APIs The user groups APIs return group data for the current user. To access these APIs you must provide an access token that is bound to a user. ### The group memberships of the current user Requests need to be authenticated with a personal token. This endpoint returns all **active** group memberships of the current user. Expired or otherwise inactive groups are not returned by default. #### API endpoint `https://groups-api.dataporten.no/groups/me/groups` #### Query string parameter `showAll=true` : The provider will list all groups that the current user is associated with, also expired and inactive groups and roles. #### Response The response contains a list of groups. If the user is not a member of any active groups, an empty list is returned; `[]`. Here is an example of a response body: ```http GET /groups/me/groups HTTP/1.1 Host: groups-api.dataporten.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 HTTP/1.1 200 OK Content-Type: application/json [ { "id": "fc:adhoc:8878ae43-965a-412a-87b5-38c398a76569", "displayName": "...", "...": "..." }, { "id": "fc:adhoc:8878ae43-965a-412a-87b5-38c398a76569", "displayName": "....", "...": "..." } ] ``` For the specifications of the attributes of groups, review the group type specifications: - [Data model: Group Type specifications](group_types/index.html.md) #### Errors If the token isn’t bound to a user, 403 Forbidden is returned. ### My membership of this particular group Requests need to be authenticated with a personal token. #### API endpoint `https://groups-api.dataporten.no/groups/me/groups/{groupid}` #### Path parameter `groupid` : The group identifier. #### Response If the user is a member of the specified group, this endpoint returns the membership object representing the user’s relation to the group. ```http GET /groups/me/groups/fc%3Aadhoc%3A8878ae43-965a-412a-87b5-38c398a76569 HTTP/1.1 Host: groups-api.dataporten.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 HTTP/1.1 200 OK Content-Type: application/json { "basic": "member" } ``` #### Errors If the access token doesn’t allow access to the group or the token isn’t bound to a user, the endpoint returns 403 Forbidden. If the user isn’t a member of the group, 404 Not Found is returned. ### Details about a group Requests need to be authenticated with a token. This endpoint returns details about a group that the user has access to. The user may have access to view information about the group even if the user is not member. For example, the group information might be public. #### API endpoint `https://groups-api.dataporten.no/groups/groups/{groupid}` #### Path parameter `groupid` : The group identifier. #### Response Details about the group. ```http GET /groups/groups/fc%3Aadhoc%3A8878ae43-965a-412a-87b5-38c398a76569 HTTP/1.1 Host: groups-api.dataporten.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 HTTP/1.1 200 OK Content-Type: application/json { "id": "fc:adhoc:8878ae43-965a-412a-87b5-38c398a76569", "displayName": "Project on group APIs", "type": "voot:ad-hoc" } ``` #### Errors If the access token doesn’t allow access to the group, the endpoint returns 403 Forbidden. If the user isn’t a member of the group or the token isn’t bound to a user, the response from the endpoint is as follows: | Group type | Response | |--------------------|---------------| | fc:adhoc (public) | group data | | fc:adhoc (private) | 404 Not Found | | fc:fs | 404 Not Found | | fc:gogroup | 404 Not Found | | fc:grep | group data | | fc:org | 404 Not Found | ### Members of a group Requests need to be authenticated with a token. This endpoint returns all \*active\* group members of the specified group. Expired or otherwise inactive members will not returned by default. #### API endpoint `https://groups-api.dataporten.no/groups/groups/{groupid}/members` #### Path parameter `groupid` : The group identifier. #### Query string parameter `showAll=true` : The provider will list all members that are associated with the group, also expired and inactive user memberships. #### Response The response contains a list of users. If the group does not currently have any members, an empty list is returned; `[]`. ```http GET /groups/groups/fc%3Aadhoc%3A8878ae43-965a-412a-87b5-38c398a76569/members HTTP/1.1 Host: groups-api.dataporten.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 ``` Some group types do not support listing members. In these cases an empty list is returned. Normally, user IDs are not returned for the users when listing group members. However, when the attribute group groups-memberids is configured and the group backend supports it, the user ID is returned in a userid_sec attribute and the [OpenID Connect subject identifier](../../schema/identifiers/index.html.md#openid-connect-subject-identifier) is included in a `sub` attribute. This attribute group is moderated by Sikt. Currently, this attribute group is supported by the backend for primary and secondary education in Norway. Here is an example of a response body: ```json [ { "name": "Andreas Åkre Solberg", "membership": { "basic": "member" } }, { "name": "Anders Lund", "membership": { "basic": "admin" } }, { "name": "Olav Morken", "membership": { "basic": "member" } } ] ``` Example, with user IDs included: ```json [ { "sub": "6e7d1650-8f00-4007-bbb3-4e92f248441b", "name": "Alf Berg", "userid_sec": [ "feide:aberg04@elgskinnetskole.sunnvik.kommune.no" ], "membership": { "affiliation": "student", "basic": "member", "displayName": { "nb": "Elev" } } }, ... { "sub": "4ceb0786-2573-4af1-a131-43e155b56fa1", "name": "Eva Vesthus", "userid_sec": [ "feide:evesthus01@elgskinnetskole.sunnvik.kommune.no" ], "membership": { "affiliation": "student", "basic": "member", "displayName": { "nb": "Elev" } } } ] ``` #### Errors If the access token doesn’t allow access to the group, the endpoint returns 403 Forbidden. If the user isn’t a member of the group or the token isn’t bound to a user, the response from the endpoint is as follows: | Group type | Response | |--------------------|---------------------------------------------------| | fc:adhoc (public) | list of members | | fc:adhoc (private) | 403 Forbidden | | fc:fs | both members and nonmembers receive an empty list | | fc:gogroup | 404 Not Found | | fc:grep | both members and nonmembers receive an empty list | | fc:org | both members and nonmembers receive an empty list | ### List all (or query a set of) groups Requests need to be authenticated with a token. #### API endpoint `https://groups-api.dataporten.no/groups/groups` #### Response The response is a list of group objects. If no groups were found or the token isn’t bound to a user, an empty list is returned: `[]`. The list contains the following groups: - Groups the user belongs to - Public [ad hoc groups](group_types/adhoc.html.md) ## Organization groups APIs The organization groups APIs allow you to retrieve group information for all groups at a given organization. To access these APIs you must provide an access token that: - Is not bound to a user. - Has the `system-all-users` scope. - Has the scope/attribute group (groups-org / groups-edu / groups-other) for the group information you want to retrieve. These APIs can be used to provision users & groups without waiting for the user to log in. See the [provisioning documentation](../../../service_providers/provisioning/index.html.md) for more information. ### Identifying the organization There are two sets of organization groups endpoints that differ only in how they identify the organization. `/orgs/{domain}/...` : These endpoints identify the organization by its Feide [domain name](../../../service_providers/finding_domain_name.html.md#finding-domain-name) (realm). `/by-orgno/{orgno}/...` : These endpoints identify the organization by its 9 digit Norwegian organization number as found in Brønnøysundregistrene, corresponding to the `norEduOrgNIN` attribute in Feide. #### Organization number resolution The `{orgno}` path parameter accepts the organization number as 9 digits with an optional case-insensitive prefix “NO”. `713293725`, `NO713293725`, and `no713293725` are all valid and refer to the same organization. The organization number is resolved to a domain name before the request is processed. The outcome depends on how many valid domain names that are found for the given organization number: - Exactly one match: resolves to that domain name and continues just as for the corresponding `/orgs/{domain}/...` endpoint. - No match: returns `404 Not Found`. - Multiple matches: returns `409 Conflict` as the resolution was ambiguous. - Invalid organization number format: returns `400 Bad Request`. ### Details about a group at the given organization Requests need to be authenticated with a token obtained with client credentials flow. These endpoints return group data for a single group present in the user directory of the given organization. #### API endpoints `https://groups-api.dataporten.no/groups/v1/orgs/{domain}/groups/{groupid}` `https://groups-api.dataporten.no/groups/v1/by-orgno/{orgno}/groups/{groupid}` #### Path parameters `domain` / `orgno` : See [Identifying the organization](#identifying-the-organization). `groupid` : The group identifier. #### Response Details about the group. Identify organization by the domain name `sunnvik.kommune.no`: ```http GET /groups/v1/orgs/sunnvik.kommune.no/groups/fc%3Aorg%3Asunnvik.kommune.no HTTP/1.1 Host: groups-api.dataporten.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 HTTP/1.1 200 OK Content-Type: application/json ``` Identify organization by the organization number `NO713293725`: ```http GET /groups/v1/by-orgno/NO713293725/groups/fc%3Aorg%3Asunnvik.kommune.no HTTP/1.1 Host: groups-api.dataporten.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 HTTP/1.1 200 OK Content-Type: application/json ``` Example of a response body: ```json { "id": "fc:org:sunnvik.kommune.no", "displayName": "Sunnvik kommune", "type": "fc:org", "orgType": [ "primary_and_lower_secondary_owner", "upper_secondary_owner" ], "mail": "post@sunnvik.kommune.no", "norEduOrgNIN": "NO713293725", "eduOrgLegalName": "Sunnvik kommune" } ``` #### Errors `403 Forbidden` : The access token lacks the `system-all-users` scope, doesn’t allow access to the group data for the given organization, or is bound to a user. `404 Not Found` : The group was not found, or the organization number does not resolve to a domain name. `409 Conflict` : The organization number resolves to multiple domain names. ### All members of a group at the given organization Requests need to be authenticated with a token obtained with client credentials flow. These endpoints return all members of the given group present in the user directory of the given organization. #### API endpoints `https://groups-api.dataporten.no/groups/v1/orgs/{domain}/groups/{groupid}/members` `https://groups-api.dataporten.no/groups/v1/by-orgno/{orgno}/groups/{groupid}/members` #### Path parameters `domain` / `orgno` : See [Identifying the organization](#identifying-the-organization). `groupid` : The group identifier. #### Optional query string parameter `affiliation` : examples:
`affiliation=student`
Only return members with the given [affiliation](../../schema/attributes/edupersonaffiliation.html.md#saml-attribute-edupersonaffiliation). #### Response Members of the group. Identify organization by the domain name `sunnvik.kommune.no`: ```http GET /groups/v1/orgs/sunnvik.kommune.no/groups/fc%3Aorg%3Asunnvik.kommune.no/members HTTP/1.1 Host: groups-api.dataporten.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 HTTP/1.1 200 OK Content-Type: application/json ``` Identify organization by the organization number `NO713293725`: ```http GET /groups/v1/by-orgno/NO713293725/groups/fc%3Aorg%3Asunnvik.kommune.no/members HTTP/1.1 Host: groups-api.dataporten.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 HTTP/1.1 200 OK Content-Type: application/json ``` Example of a response body: ```json [ { "sub": "6e7d1650-8f00-4007-bbb3-4e92f248441b", "name": "Alf Berg", "userid_sec": [ "feide:aberg04@elgskinnetskole.sunnvik.kommune.no" ], "membership": { "affiliation": ["student", "member"], "basic": "member", "displayName": { "nb": "Elev" }, "primaryAffiliation": "student" } }, ... { "sub": "4ceb0786-2573-4af1-a131-43e155b56fa1", "name": "Eva Vesthus", "userid_sec": [ "feide:evesthus01@elgskinnetskole.sunnvik.kommune.no" ], "membership": { "affiliation": "student", "basic": "member", "displayName": { "nb": "Elev" }, "primaryAffiliation": "student" } } ] ``` Member user attributes are included as far as the corresponding attribute groups have been enabled: * `eduPersonPrincipalName` in `userid-sec` requires `userid-feide`. * `name` requires `userinfo-name`. * `sub` is always included. This is the [OpenID Connect subject identifier](../../schema/identifiers/index.html.md#openid-connect-subject-identifier) of the member. #### Errors `403 Forbidden` : The access token lacks the `system-all-users` scope, doesn’t allow access to the group data for the given organization, or is bound to a user. `404 Not Found` : The group was not found, or the organization number does not resolve to a domain name. `409 Conflict` : The organization number resolves to multiple domain names. ### All groups at the given organization Requests need to be authenticated with a token obtained with client credentials flow. These endpoints return all groups for the given organization from the user directory. #### API endpoints `https://groups-api.dataporten.no/groups/v1/orgs/{domain}/groups` `https://groups-api.dataporten.no/groups/v1/by-orgno/{orgno}/groups` #### Path parameter `domain` / `orgno` : See [Identifying the organization](#identifying-the-organization). #### Optional query string parameters `go_type` : examples:
`go_type=a`, `go_type=b`, `go_type=u`
Only return GO groups with the specific `go_type` value. `grep_code` : example:
`grep_code=MAT0009`
Only return GO groups with the given [GREP code](https://www.udir.no/om-udir/data/kl06-grep/). `orgunit` : examples:
`orgunit=NO975279014`
`orgunit=U90099013`
Return organization unit groups and GO groups with the given organization number. The number should be prefixed with ‘NO’ for Norwegian organization numbers and ‘U’ for foreign. #### Response Groups at the organization. Identify organization by the domain name `sunnvik.kommune.no`: ```http GET /groups/v1/orgs/sunnvik.kommune.no/groups HTTP/1.1 Host: groups-api.dataporten.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 HTTP/1.1 200 OK Content-Type: application/json ``` Identify organization by the organization number `NO713293725`: ```http GET /groups/v1/by-orgno/NO713293725/groups HTTP/1.1 Host: groups-api.dataporten.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 HTTP/1.1 200 OK Content-Type: application/json ``` Example of a response body: ```json [ { "id": "fc:org:sunnvik.kommune", "displayName": "Sunnvik kommune", "type": "fc:org", "orgType": [ "primary_and_lower_secondary_owner", "upper_secondary_owner" ], "mail": "post@sunnvik.kommune.no", "norEduOrgNIN": "NO713293725", "eduOrgLegalName": "Sunnvik kommune" }, { "id": "fc:org:sunnvik.kommune.no:unit:NO895395126", "parent": "fc:org:sunnvik.kommune.no", "displayName": "Elgskinnet skole", "type": "fc:org", "orgType": [ "upper_secondary" ] }, { "id": "fc:gogroup:sunnvik.kommune.no:b:NO895395126:vg1a:2000-07-01:2100-06-30", "displayName": "Basisgruppe VG1A", "type": "fc:gogroup", "notBefore": "2000-06-30T22:00:00Z", "notAfter": "2100-06-30T23:00:00Z", "go_type": "b", "parent": "fc:org:sunnvik.kommune.no:unit:NO895395126", "go_type_displayName": "basisgruppe" }, { "id": "fc:grep2:sunnvik.kommune.no:http%3A%2F%2Fpsi.udir.no%2Flaereplan%2Faarstrinn%2Fvg1", "type": "fc:grep2", "code": "vg1", "grep_type": "aarstrinn", "displayName": { "nb": "Videregående trinn 1" }, } ] ``` #### Errors `403 Forbidden` : The access token lacks the `system-all-users` scope, doesn’t allow access to the group data for the given organization, or is bound to a user. `404 Not Found` : The organization number does not resolve to a domain name. `409 Conflict` : The organization number resolves to multiple domain names. ### Pagination The [organization groups endpoints](#organization-groups-apis) return paged responses, with a default of 100 objects per page. A link to the next page of data is given in a `Link` header, like this: ```http GET /groups/v1/orgs/sunnvik.kommune.no/groups HTTP/1.1 Host: groups-api.dataporten.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 HTTP/1.1 200 OK Content-Type: application/json Link: ; rel="next" ``` To change the page size, you can use the `per_page` query parameter. ### Group identifiers in URLs Group identifiers are used as path elements in URLs. The group `fc:gogroup:spusers.feide.no:b:NO856326499:6a:2021-07-01:2022-07-30` represents a group in lower education in Norway. Here is how to retrieve it: ```default GET https://groups-api.dataporten.no/groups/groups/fc%3Agogroup%3Aspusers.feide.no%3Ab%3ANO856326499%3A6a%3A2021-07-01%3A2022-07-30 ``` The group ID may contain ‘%’ or other special characters. You have to encode these before you use them in a URL. E.g. turn ‘6%20a’ into ‘6%2520a’. The reason is that whenever a web server encounters a ‘%’ in a URL, it interprets it as the start of an encoded character. The urls `https://www.example.org/hi` and `https://www.example.org/h%69` are actually the same URL. The Group API will only see a ‘%’ if it is encoded to ‘%25’. The group ID should be [percent encoded](https://en.wikipedia.org/wiki/Percent-encoding) as specified in the rules for path segments in [**RFC 3986**](https://datatracker.ietf.org/doc/html/rfc3986.html). The characters that do *not* need encoding according to this standard are ‘A-Z’, ‘a-z’, ‘0-9’, ‘-’, ‘.’, ‘_’ and ‘~’. For the groups API, ‘:’ can also be left unencoded. ## Other group APIs ### List all group types This endpoint is used to return information about group types. It will at least return group type information for all group types represented by the groups that the current user is a member of. #### API endpoint `https://groups-api.dataporten.no/groups/grouptypes` #### Response The response contains a list of group types. If no group types was found, an empty list is returned; `[]`. Here is an example of a response body: ```http GET /groups/grouptypes HTTP/1.1 Host: groups-api.dataporten.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 ``` ```json [ { "id": "voot:adhoc", "displayName": "Ad hoc group" }, { "id": "fc:org", "displayName": "Organization" }, { "id": "fc:emne", "displayName": "Subject" } ] ``` # OpenID Connect userinfo The userinfo endpoint is an OIDC/OAuth protected resource where client applications can retrieve claims, or assertions, about the logged in end-user. Clients must present a valid access token to retrieve the userinfo claims. The userinfo endpoint is: - [https://auth.dataporten.no/openid/userinfo](https://auth.dataporten.no/openid/userinfo) Example of a userinfo response: ```http GET /openid/userinfo HTTP/1.1 Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 HTTP/1.1 200 OK Content-Type: application/json { "sub": "76a7a061-3c55-430d-8ee0-6f82ec42501f", "dataporten-userid_sec": [ "feide:andreas@uninett.no" ], "https://n.feide.no/claims/userid_sec": [ "feide:andreas@uninett.no" ], "https://n.feide.no/claims/eduPersonPrincipalName": "andreas@uninett.no", "name": "Andreas \u00c5kre Solberg", "email": "andreas.solberg@uninett.no", "email_verified": false, "picture": "https://api.dataporten.no/userinfo/v1/user/media/p:a3019954-902f-45a3-b4ee-bca7b48ab507" } ``` The set of information that will be available from userinfo depends on which attribute groups the client has authorized and which scopes are requested in the authorization request. connect-userid_sec : #### WARNING Deprecated and will be removed in the future. Included for backward compatibility. Same as https://n.feide.no/claims/userid_sec. dataporten-userid_sec : #### WARNING Deprecated. Same as https://n.feide.no/claims/userid_sec. There’s no plan to remove this claim in the near future. https://n.feide.no/claims/userid_sec : Contains a namespaced user ID, e.g. Feide identifier.
The attribute groups userid-feide, userid-nin, userid-edugain, userid-social and eidas determine what information is included here. https://n.feide.no/claims/eduPersonPrincipalName : Contains eduPersonPrincipalName (Full Feide name) for valid Feide users. Requires the userid-feide attribute group. https://n.feide.no/claims/nin : Contains the national identification number. Requires the userid-nin attribute group. email : Email address of the authenticated user. Requires the email attribute group. email_verified : This will always be false since Feide does not verify email addresses. name : The name of the authenticated user. Requires the userinfo-name attribute group. picture : A picture of the authenticated user, if available. Requires the userinfo-photo attribute group. sub : The internal ID of the authenticated user. This ID is stable but opaque, not releasing any additional information about the user. Always included. - [Read more about the various Feide attribute groups](../schema/attributegroups/index.html.md) ## Extended userinfo Additional information from Feide directories is available at the [extended userinfo endpoint](attributes_feide/extended_userinfo.html.md#extended-userinfo). # Feide user attributes Feide provides APIs for retrieving user attributes and checking whether a user exists: - [Attributes for the current user](extended_userinfo.html.md#extended-userinfo) - [Attributes for specific users](user_lookup.html.md#user-lookup) - [Check user existence](check_user_existence.html.md#check-user-existence) These APIs only work with Feide accounts. Attribute groups determine which user attributes a service gets access to through the APIs. An attribute is returned if it is present for the user and the client has been granted the corresponding attribute group. The list of attributes and their corresponding attribute groups is at [Available user attributes](available_attributes.html.md#available-attributes). # Available user attributes The [extended userinfo](extended_userinfo.html.md#extended-userinfo) and [user lookup](user_lookup.html.md#user-lookup) APIs return user attributes for Feide accounts. Which attributes are available to a service depends on the attribute groups the service has access to. The attribute groups are configured in the customer portal. Attribute groups correspond to scopes in OAuth/OpenID Connect terminology. The list below shows all attributes that may be returned. They are included in the response if they are present for the user and the client has the corresponding attribute group. For each attribute, the following information is given: - The attribute name - The attribute group required to access the attribute - The attribute’s data type - A description of the attribute ## Subject identifier As long as the subject identifier (sub) exists for the user, it will be present in the response. This requires no specific attribute group. A sub is generated either the first time a user logs in with OpenID Connect or within a few hours after the user is created. sub : Attribute group: (no group required)
Data type: String

The [OpenID Connect subject identifier](../../oauth_oidc/userids.html.md#primary-userid) of the user. This is a stable, opaque and unique identifier for the user. ## Required attributes As long as the client has the corresponding attribute group, the following attributes are always present in the response: cn : Attribute group: `userinfo-name`
Data type: Array which may hold multiple strings

Person’s name as registered at their home organization displayName : Attribute group: `userinfo-name`
Data type: String

Person’s preferred name eduPersonAffiliation : Attribute group: `groups-org`
Data type: Array which may hold multiple strings

Person’s role at home organization (e. g.: student, employee) eduPersonEntitlement : Attribute group: `groups-edu` or `userinfo-entitlement`
Data type: Array which may hold multiple strings

This attribute has multiple uses. Feide uses it to encode group affiliations for primary and secondary education. Organizations may also use it for other purposes.
Entitlements which encode groups are available to services which have the `groups-edu` scope. The encoding is described in [Appendix 3 - Registration of group information within eduPersonEntitlement](../../schema/info_go/go_attributter_chA3.html.md). However, we strongly recommend that services use the [groups API](../groups_api/index.html.md#groups-api) to access group information.
Example - group affiliations for a primary school teacher:
```json "eduPersonEntitlement": [ "urn:mace:feide.no:go:group:b::NO987654321:7A:2024-08-01:2025-06-30:Faculty:7A", "urn:mace:feide.no:go:group:b::NO987654321:7B:2024-08-01:2025-06-30:Faculty:7B", "urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn7" ] ```
Services which have the `userinfo-entitlement` scope will get all entitlements which match any of the entitlement prefixes registered for the service in the customer portal.
Example - organization internal use:
```json "eduPersonEntitlement": [ "accountOrigin:SAP" ] ``` eduPersonPrincipalName : Attribute group: `userid-feide`
Data type: String

Person’s Feide ID givenName : Attribute group: `userinfo-name`
Data type: Array which may hold multiple strings

Person’s first name norEduPersonLegalName : Attribute group: `userinfo-name`
Data type: String

Person’s formal name as registered with public authorities norEduPersonNIN : Attribute group: `userid-nin`
Data type: String

Person’s national identity number sn : Attribute group: `userinfo-name`
Data type: Array which may hold multiple strings

Person’s surname uid : Attribute group: `userid-feide`
Data type: Array which holds a single string

Person’s local username ## Attributes required for higher education The attributes below are required for higher education and optional for primary and secondary education. mail : Attribute group: `email`
Data type: Array which may hold multiple strings

Person’s email address schacHomeOrganization : Attribute group: `groups-org`
Data type: String

Realm for the person’s home organization ## Optional attributes The following attributes are optional: eduPersonOrcid : Attribute group: `userid-orcid`
Data type: Array which may hold multiple strings

Person’s ORCID digital researcher IDs eduPersonPrimaryAffiliation : Attribute group: `groups-org`
Data type: String

Person’s primary role (e.g. student, employee) eduPersonPrincipalNamePrior : Attribute group: `userid-feide`
Data type: Array which may hold multiple strings

Person’s previous Feide IDs at the same organization eduPersonScopedAffiliation : Attribute group: `groups-org`
Data type: Array which may hold multiple strings

Person’s role and institution at home organization. Example: `["student@trondheim.kommune.no", "student@no975278921.trondheim.kommune.no"]` facsimileTelephoneNumber : Attribute group: `userinfo-phone`
Data type: Array which may hold multiple strings

Person’s facsimile telephone number homePhone : Attribute group: `userinfo-phone`
Data type: Array which may hold multiple strings

Person’s home phone number homePostalAddress : Attribute group: `userinfo-address`
Data type: Array which may hold multiple strings

Person’s home postal address l : Attribute group: `userinfo-address`
Data type: Array which may hold multiple strings

Name of locality mobile : Attribute group: `userinfo-mobile`
Data type: Array which may hold multiple strings

Person’s mobile telephone number norEduPersonBirthDate : Attribute group: `userinfo-birthdate`
Data type: String

Person’s date of birth norEduPersonLIN : Attribute group: `userid-lin`
Data type: Array which holds a single string

Local replacement for national identity number o : Attribute group: `groups-org`
Data type: String

Name of the person’s home organization ou : Attribute group: `groups-org`
Data type: Array which may hold multiple strings

Name of the person’s school/organization unit postOfficeBox : Attribute group: `userinfo-address`
Data type: Array which may hold multiple strings

Person’s P.O. box postalAddress : Attribute group: `userinfo-address`
Data type: Array which may hold multiple strings

Person’s postal addresses postalCode : Attribute group: `userinfo-address`
Data type: Array which may hold multiple strings

Person’s postal code preferredLanguage : Attribute group: `userinfo-language`
Data type: String

Person’s preferred language street : Attribute group: `userinfo-address`
Data type: Array which may hold multiple strings

Person’s street address telephoneNumber : Attribute group: `userinfo-phone`
Data type: Array which may hold multiple strings

Person’s telephone numbers title : Attribute group: `userinfo-title`
Data type: Array which may hold multiple strings

Person’s title # Attributes for the current user Attributes for the logged in user are available through this API, which is also called “extended userinfo”. It is only available for users logged in with a Feide account. ## API endpoint `https://api.dataporten.no/userinfo/v1/userinfo` ## Example The testuser `asbjorn_elevg@testusers.feide.no` is logged in and has the scopes `userid-feide` and `userinfo-name` in the access token. The endpoint is called like so: ```shell curl -sSLf -H 'Authorization: Bearer ....' \ 'https://api.dataporten.no/userinfo/v1/userinfo' ``` This gives the following output: ```json { "sub": "af761fdb-71fa-484b-9782-ababdc739559", "cn": [ "Asbj\u00f8rn ElevG Hansen" ], "displayName": "Asbj\u00f8rn ElevG Hansen", "eduPersonPrincipalName": "asbjorn_elevg@testusers.feide.no", "givenName": [ "Asbj\u00f8rn ElevG" ], "sn": [ "Hansen" ], "uid": [ "asbjorn_elevg" ] } ``` ## Return values The API returns a JSON object containing the user attributes. The keys in the returned object are the attribute names. The [available attributes](available_attributes.html.md#available-attributes) page lists the attributes that may be included in the response and the attribute groups required to access them. ## Errors The API returns `401 Unauthorized` when the access token is missing, invalid or expired. It returns `403 Forbidden` when the access token is not associated with a logged in user. It returns `404 Not Found` when the logged in user is not a Feide user, or when the user cannot be found. # Attributes for specific users Attributes for specific Feide users is available through this API. In order to access the API, a number of [requirements](#user-lookup-requirements) have to be met. The API only supports looking up Feide accounts. It cannot be used to retrieve information about, for example, guest users or users logging in using ID-Porten. #### NOTE This API is intended for retrieving user attributes. If your service only needs to check whether a user exists, use the dedicated [check user existence API](check_user_existence.html.md#check-user-existence) with the narrower `system-check-user-existence` scope instead. ## API endpoint The API supports looking up attributes for a user by providing either a [Feide ID](../../oauth_oidc/userids.html.md#feide-id) or a [sub](../../oauth_oidc/userids.html.md#primary-userid). The structure of the output is the same for both variants. `https://api.dataporten.no/userinfo/v1/lookup/{identifier}` ## Examples The examples below are for the testuser `asbjorn_elevg@testusers.feide.no`. This user can be identified by the values: - Feide ID: `feide:asbjorn_elevg@testusers.feide.no` - sub: `af761fdb-71fa-484b-9782-ababdc739559` The following API calls rely on an access token with the scopes `system-all-users`, `userid-feide` and `userinfo-name`. ### Lookup by Feide ID To look up this user by their Feide ID `feide:asbjorn_elevg@testusers.feide.no`, make the following call: ```shell curl -sSLf -H 'Authorization: Bearer ....' \ 'https://api.dataporten.no/userinfo/v1/lookup/feide%3Aasbjorn_elevg%40testusers.feide.no' ``` ### Lookup by sub To look up this user by their sub `af761fdb-71fa-484b-9782-ababdc739559`, make the following call: ```shell curl -sSLf -H 'Authorization: Bearer ....' \ 'https://api.dataporten.no/userinfo/v1/lookup/af761fdb-71fa-484b-9782-ababdc739559' ``` ### Output In both cases this will give the following output: ```json { "sub": "af761fdb-71fa-484b-9782-ababdc739559", "cn": [ "Asbj\u00f8rn ElevG Hansen" ], "displayName": "Asbj\u00f8rn ElevG Hansen", "eduPersonPrincipalName": "asbjorn_elevg@testusers.feide.no", "givenName": [ "Asbj\u00f8rn ElevG" ], "sn": [ "Hansen" ], "uid": [ "asbjorn_elevg" ] } ``` ## Parameters ### identifier The `identifier` path parameter specifies the target user. This parameter accepts the following identifiers: - Feide ID: A [Feide account identifier](../../oauth_oidc/userids.html.md#feide-id) prefixed with `feide:`, e.g. `feide:user@kommune.test`. - sub: An [OpenID Connect subject identifier](../../oauth_oidc/userids.html.md#primary-userid) as a UUID, e.g. `20aa6dfc-9725-4c70-9963-4d31894970fb`. The `identifier` must be [percent encoded](https://en.wikipedia.org/wiki/Percent-encoding) as specified in the rules for path segments in [**RFC 3986**](https://datatracker.ietf.org/doc/html/rfc3986.html). Example: `feide%3Auser%40kommune.test` ## Return values The API returns a JSON object containing the user attributes. The keys in the returned object are the attribute names. The [available attributes](available_attributes.html.md#available-attributes) page lists the attributes that may be included in the response and the attribute groups required to access them. ## Errors The API returns `400 Bad Request` when the identifier is malformed or does not refer to a Feide account (e.g. a guest user). It returns `401 Unauthorized` when the access token is missing, invalid or expired. It returns `403 Forbidden` when the [requirements](#user-lookup-requirements) below aren’t met. It returns `404 Not Found` when the user cannot be found. ## Requirements for accessing the API - The service must have the `system-all-users` scope. - The access token must have been obtained using the [client credentials flow](../../../service_providers/openid_connect/client_credentials_flow.html.md). - The service must have been activated for one of the organization units the user belongs to or the entire organization. # Check user existence The check user existence API allows a service to check whether a Feide user exists at an organization, without the user needing to be logged in and without retrieving any user attributes. In order to access the API, a number of [requirements](#check-user-existence-requirements) have to be met. The API only supports Feide accounts. It cannot be used to check for the existence of, for example, guest users or users logging in using ID-Porten. **Important notice:** There is no guarantee that organizations delete user accounts when they are no longer in use. A positive result means the user account exists in the organization’s records, not necessarily that the user is still active. If this distinction matters, it is recommended to take this up with the organization directly. ## API endpoints The API supports checking the existence of a user by providing either a [Feide ID](../../oauth_oidc/userids.html.md#feide-id), [sub](../../oauth_oidc/userids.html.md#primary-userid), or a combination of an organization domain and an email address. The structure of the output is the same for all three variants. **By Feide ID or sub** `https://api.dataporten.no/userinfo/v1/exists/{identifier}` **By email address:** `https://api.dataporten.no/userinfo/v1/exists-by-mail/{domain}/{mail}` ## Examples The examples below are for the testuser `asbjorn_elevg@testusers.feide.no`. This user belongs to the organization with domain `testusers.feide.no` and can be identified by the values: - Feide ID: `feide:asbjorn_elevg@testusers.feide.no` - sub: `af761fdb-71fa-484b-9782-ababdc739559` - email address: `asbjorn.hansen@elev.feide.no` The following API calls rely on an access token with the scope `system-check-user-existence`. ### Check existence by Feide ID To check whether this user exists by their Feide ID `feide:asbjorn_elevg@testusers.feide.no`, make the following call: ```shell curl -sSLf -H 'Authorization: Bearer ....' \ 'https://api.dataporten.no/userinfo/v1/exists/feide%3Aasbjorn_elevg%40testusers.feide.no' ``` ### Check existence by sub To check whether this user exists by their sub `af761fdb-71fa-484b-9782-ababdc739559`, make the following call: ```shell curl -sSLf -H 'Authorization: Bearer ....' \ 'https://api.dataporten.no/userinfo/v1/exists/af761fdb-71fa-484b-9782-ababdc739559' ``` ### Check existence by email address To check whether this user exists by their organization domain `testusers.feide.no` and email address `asbjorn.hansen@elev.feide.no`, make the following call: ```shell curl -sSLf -H 'Authorization: Bearer ....' \ 'https://api.dataporten.no/userinfo/v1/exists-by-mail/testusers.feide.no/asbjorn.hansen%40elev.feide.no' ``` ### Output If a user with the provided Feide ID, sub, or email address exists at the organization, the API returns: ```json { "exists": true } ``` If no such user exists, it instead returns: ```json { "exists": false } ``` ## Parameters ### identifier The `identifier` path parameter specifies the target user. This parameter accepts the following identifiers: - Feide ID: A [Feide account identifier](../../oauth_oidc/userids.html.md#feide-id) prefixed with `feide:`, e.g. `feide:user@kommune.test`. - sub: An [OpenID Connect subject identifier (sub)](../../oauth_oidc/userids.html.md#primary-userid) as a UUID, e.g. `20aa6dfc-9725-4c70-9963-4d31894970fb`. The `identifier` must be [percent encoded](https://en.wikipedia.org/wiki/Percent-encoding) as specified in the rules for path segments in [**RFC 3986**](https://datatracker.ietf.org/doc/html/rfc3986.html). Example: `feide%3Auser%40kommune.test` ### domain The `domain` path parameter specifies the domain of the organization that the target user belongs to. Example: `kommune.test` ### mail The `mail` path parameter specifies the email address of the target user. The `mail` must be [percent encoded](https://en.wikipedia.org/wiki/Percent-encoding) as specified in the rules for path segments in [**RFC 3986**](https://datatracker.ietf.org/doc/html/rfc3986.html). Example: `user%40ansatt.kommune.test` ## Return values The API returns a JSON object with a single `exists` key. The value is - `true` if one or more matching users are found and the service is activated for the entire organization or for at least one of the users’ organizational units. - `false` if no matching user is found, or if matching users are found but the service is not activated for any of their organizational units. ### Multiple users If multiple users are found with the provided email address, the API returns `true`, as it can tell that a matching user does indeed exist. ### Service activation Even if a user exists, the response still depends on whether the service is activated for the user’s organization or organizational units. There are three possible cases: 1. Activated for the entire organization: `true` 2. Activated for at least one of the found user’s organizational units: `true` 3. Activated, but not for any of the found user’s organizational units: `false` If not activated for the organization at all, see [Errors](). ## Errors The API returns *400 Bad Request* when the `identifier` is not a valid Feide ID or sub. A Feide ID must have the prefix `feide:` and contain an *@* symbol. It returns *401 Unauthorized* when the bearer token is missing or invalid. It returns *403 Forbidden* when the [requirements](#check-user-existence-requirements) below are not met. ## Requirements for accessing the API - The service must have the `system-check-user-existence` scope. - The access token must have been obtained using the [client credentials flow](../../../service_providers/openid_connect/client_credentials_flow.html.md). - The service must be activated for the entire organization or for at least one of the organization’s organizational units. # Guardian API An API for information about students a given parent/guardian is responsible for. #### WARNING This is a proof of concept implementation. It may be changed or discontinued at short notice. All calls are to be made using ‘POST’. ## Examples The example looks up the students of a given guardian. It assumes that you are logged into Feide and that `$TOKEN` contains the access token you received during authentication. You must also have the `gk_guardianapi` scope in order to be able to access this API. ### Students for a guardian Look up students for a given guardian. The guardian must be logged in using ID-porten. ```default curl -sS -H "Authorization: Bearer $TOKEN" -d guardian=21079416549 -d realm=testusers.feide.no \ https://guardianapi.dataporten-api.no/guardian_students [{"eduPersonPrincipalName": "thea_elevg@testusers.feide.no", "email": "thea.nilsen@test.feide.no", "userid": "9eb60ee0-8d10-410d-93a8-04190d51ba89", "givenName": "Thea", "norEduPersonLegalName": "Thea Nilsen"}] ``` Returns an `application/json` array of one object for each of the students in a Feide realm the guardian is parent/guardian of. The possible attributes of the students that can be returned - if they are available in the system - are: - `eduPersonPrincipalName` - `email` - `givenName` - `mobile` - `norEduPersonLegalName` - `norEduPersonLIN` - `norEduPersonNIN` - `userid` If there is more than one student for a guardian, there will be one object like this for each student. In this proof of concept implementation, only the logged in guardian’s own students may be looked up. It is possible that we may later want to allow teachers or administrators to perform the call. This is the reason that there is an explicit `guardian` parameter. # Deprecated APIs #### WARNING These endpoint are deprecated and will be phased out. New applications should avoid them, and existing applications should migrate off them. * [Legacy check user existence](checkuser.html.md) * [Legacy OAuth userinfo endpoint](legacy_userinfo.html.md) # Legacy check user existence #### WARNING This endpoint is deprecated and will be shut down in the future. Services should migrate to the [check user existence endpoints](../attributes_feide/check_user_existence.html.md#check-user-existence) using the `system-check-user-existence` scope. The gatekeeper subscope required to access this endpoint (`gk_checkuser_systemlookup`) is also deprecated and will serve no purpose after the endpoint is shut down. Access to this API could only be managed through Dataporten Dashboard, which is no longer available. If you need to make changes regarding this API, please contact us at [kontakt@sikt.no](mailto:kontakt@sikt.no). We need to know the service ID and client ID of the configuration, and the organizations whose users you wish to check the existence of. **Important notice:** There is no guarantee that organizations delete user accounts when they are no longer in use. If you are using this endpoint to check if a user still has an active account at an organization, it is recommended to communicate with the organization. To use the legacy checkuser API your client needs to get an access token using the [client credentials flow](../../../service_providers/openid_connect/client_credentials_flow.html.md). Then, simply send a request to the following endpoint with your access token `https://checkuser.dataporten-api.no/check_single/username@domain` Example request: ```http GET /check_single/username%40domain HTTP/1.1 Host: checkuser.dataporten-api.no Authorization: Bearer 0f0935c3-a997-40fb-89c2-f7da126ba5d9 ``` Example response: ```json { "exists": true } ``` The `"exists"` attribute has the value `true` if the user exists, otherwise `false`. # Legacy OAuth userinfo endpoint #### WARNING This endpoint is deprecated and will be phased out. New applications should use [OpenID Connect userinfo](../userinfo.html.md) instead, and existing applications should migrate off it. The legacy OAuth userinfo endpoint dates from when OpenID Connect had not yet emerged as the leading standard. The endpoint offers roughly the same functionality as [OIDC userinfo](../userinfo.html.md). The set of information that will be available from legacy userinfo depends on which attribute groups the client has authorized and which scopes are requested in the authorization request. The legacy userinfo endpoint is: `https://auth.dataporten.no/userinfo` Here is an example request: ```http GET /userinfo HTTP/1.1 Host: auth.dataporten.no Authorization: Bearer 083a7ef0-ea97-49ec-8804-379dc1e9b54c ``` ```http HTTP/1.1 200 OK Content-Type: application/json { "user": { "userid": "76a7a061-3c55-430d-8ee0-6f82ec42501f", "userid_sec": ["feide:andreas@uninett.no"], "name": "Andreas \u00c5kre Solberg", "email": "andreas.solberg@uninett.no", "profilephoto": "p:a3019954-902f-45a3-b4ee-bca7b48ab507" }, "audience": "e8160a77-58f8-4006-8ee5-ab64d17a5b1e" } ``` When using the legacy userinfo endpoint to authenticate the user, the application **MUST** verify that the `audience` property matches the client id of the application. With only the `userinfo-photo`, `userinfo-name` and `userid-feide` attribute groups, the accessible user properties are: ```json { "userid": "76a7a061-3c55-430d-8ee0-6f82ec42501f", "profilephoto": "p:a3019954-902f-45a3-b4ee-bca7b48ab507", "name": "Andreas \\u00c5kre Solberg" } ``` - [Read more about the various Feide attribute groups](../../schema/attributegroups/index.html.md) ## User Profile photo If the application has obtained the `userinfo-photo` public handle of the user, the application may fetch the profile photo from: `https://api.dataporten.no/userinfo/v1/user/media/{userinfo-photo handle}` E.g.: `https://api.dataporten.no/userinfo/v1/user/media/p:a3019954-902f-45a3-b4ee-bca7b48ab507` The photo is often square, and 128 x 128px. If not square, the longest edge will be 128px, and the aspect ratio will be unchanged from the original. # MFA * [Technical specification](technical_reqs.html.md) * [Enforcing multifactor authentication](technical_reqs.html.md#enforcing-multifactor-authentication) * [SMS authentication](technical_reqs.html.md#sms-authentication) * [Authenticator](technical_reqs.html.md#authenticator) * [Entra ID](technical_reqs.html.md#entra-id) * [MFA Examples](examples.html.md) # Technical specification All the information related to the usage of multifactor authentication by a certain user must be stored directly in the user’s entry at the institutional directory. In order to accommodate such information without interfering with other attributes already in the directories, and to guarantee the technical and administrative requisites needed, Feide has extended the [norEduPerson schema](../schema/noredu/index.html.md) with two additional attributes: norEduPersonServiceAuthnLevel : a multivalued attribute that lets the institution decide whether multifactor authentication is enabled or not for the current user, the strength of the authentication mechanism, and for which services. norEduPersonAuthnMethod: : a multivalued attribute that lets the institution specify which multifactor methods can be used by the current user. ## Enforcing multifactor authentication In order to allow someone to use multifactor authentication in Feide, one or more multifactor methods MUST be defined. However, this requirement is not sufficient, as multifactor authentication MUST also be enabled for the service being accessed or for a specific user. Institutions can configure which services should use multifactor authentication in [Feide’s Customer Portal](https://kunde.feide.no/). Alternatively, the general configuration can be overridden on a per-user basis by adding the norEduPersonServiceAuthnLevel attribute of the [norEduPerson schema](../schema/noredu/index.html.md) to the specific subject. The attribute consists of two strings separated by a white space. The first one is the fixed string `urn:mace:feide.no:spid:` followed by one of these values: * The keyword `all`, used to enforce multifactor authentication for all services. * A *Service ID* identifying a specific service, as found in Feide’s Customer Portal for that service. These values MUST be followed by another string representing the assurance level desired for either all or the particular services specified. Currently, Feide supports only the third level described by the Norwegian [Framework for authentication and nonrepudiation in electronic communications with and in the public sector](https://www.regjeringen.no/globalassets/upload/fad/vedlegg/ikt-politikk/eid_rammeverk_trykk.pdf). The level of assurance can be expressed with the string `urn:mace:feide.no:auth:level:fad08:` followed by the numerical value identifying the level, in this case, `3`. Please note that none of the authentication methods currently supported by Feide provide level 4 according to this framework. Therefore, requiring that level would make it impossible for users to access the service or services affected. ## SMS authentication Institutions can enable multifactor authentication based on text messages by enabling multifactor authentication as described in the previous section, and adding a *norEduPersonAuthnMethod* attribute to every user who should be able to use this mechanism. This attribute is multivalued and each value MUST contain: * The fixed string `urn:mace:feide.no:auth:method:sms` identifying the SMS multifactor method in Feide. * The mobile phone number associated with the user in international format, including the country code prefixed with the plus sign (+). Phone numbers MUST NOT have blank spaces, dashes or any other character different than numbers, with the only exception of the aforementioned international code prefix. Optionally, a label identifying the device associated with the phone number can be added after these two mandatory elements. If no label is specified, the last digits of the phone number are displayed. Labels take the form `label=value`, where value is a string that we want to be displayed in order to identify the associated number. The value MUST be URL-encoded as defined by [**RFC 3986**](https://datatracker.ietf.org/doc/html/rfc3986.html) and therefore comply with the following rules: * Equal signs (=) MUST be escaped according to [percent encoding](https://en.wikipedia.org/wiki/Percent-encoding) as defined by [**RFC 3986**](https://datatracker.ietf.org/doc/html/rfc3986.html), that is, substituted by the string %3D. * Spaces MUST be escaped according to percent encoding as defined by [**RFC 3986**](https://datatracker.ietf.org/doc/html/rfc3986.html), that is, substituted by the string %20. * Percent signs (%) MUST be escaped according to percent encoding as defined by [**RFC 3986**](https://datatracker.ietf.org/doc/html/rfc3986.html), that is, substituted by the string %25. * No single or double quotes are allowed surrounding the values. All parts of the *norEduPersonAuthnMethod* attribute MUST be separated by a single blank space and keep the order specified here, so that the resulting value has the following format: `urn:mace:feide.no:auth:method:sms + label=` Refer to Appendix 1 for examples of values that are correctly formatted and values that are not. ## Authenticator In this section we present the technical details for storing and encrypting secrets in user directories, so that they can be used securely to perform multifactor authentication with the *Authenticator* method. *Authenticator* secrets consist of 16 base32-encoded characters. This means that valid secrets can only contain: * Uppercase ASCII letters from A to Z, both included. * Digits from 2 to 7, both included. There is no restriction on the proportion of letters or digits, though, so secrets can be random strings base32-encoded with the aforementioned fixed length of 16 characters. It is therefore RECOMMENDED to randomly generate these secrets. Institutions MUST NOT use functions to derive the secret from known or guessable values like the user identifier or e-mail address. If the Authenticator secret can be derived from other information related to the user, it is then useless as anybody could guess the right secret for a specific person. ### API for generating and encrypting secrets Feide provides a API for generation and encryption of *Authenticator* secrets. This API is described in the [multi-factor authentication API document](../apis/feide-api/mfa.html.md#time-based-one-time-password). Note that this API is [rate-limited](../apis/feide-api/rate-limit.html.md). ### Manual secret encryption Those willing to integrate *Authenticator* secret encryption with their own processes and systems can do it without depending on the API provided by Feide. Secrets are encrypted using the [JSON Web Encryption](https://datatracker.ietf.org/doc/html/rfc7516) specification with a [public key](https://metadata.feide.no/feide_authenticator_key.pem) specific for this use and published on the [Feide metadata website](https://metadata.feide.no/). The secret used as input for the encryption algorithm MUST be encoded as a JSON object, with the form: `{"secret": "SECRET_TO_ENCRYPT"}` where SECRET_TO_ENCRYPT is the randomly generated secret that has been configured on the user’s device. The [JWA](https://datatracker.ietf.org/doc/html/rfc7518) specification defines multiple algorithms for key and content encryption. Currently, Feide supports only the RSA-OAEP key management algorithm and the A128CBC_HS256 content encryption algorithm. Appendix 2 presents code examples of how to encrypt the *Authenticator* secrets suitable for their use in Feide in different programming languages. ### Storage of secrets Secrets for *Authenticator* instances MUST be stored in the user’s entry in the corporate directory. The secrets themselves will be stored in the *norEduPersonAuthnMethod* attribute defined by the [norEduPerson schema](../schema/noredu/index.html.md). The values of this attribute MUST contain: * The fixed string `urn:mace:feide.no:auth:method:ga` identifying the *Authenticator* multifactor method in Feide. * The Authenticator secret encrypted with Feide’s public key as described in the previous section. Optionally, a label identifying a specific instance of the *Authenticator* can be included. Labels are prefixed by the string label=, which is omitted if no label is attached to this *Authenticator* instance. All parts of the attribute value MUST be separated by a single blank space and keep the order, so that the resulting value has the following format: `urn:mace:feide.no:auth:method:ga label=` Both the encrypted secret and the label (excluding its prefix) MUST comply with the following rules: * Equal signs (=) MUST be escaped according to percent encoding as defined by [**RFC 3986**](https://datatracker.ietf.org/doc/html/rfc3986.html), that is, substituted by the string %3D. * Spaces MUST be escaped according to percent encoding as defined by [**RFC 3986**](https://datatracker.ietf.org/doc/html/rfc3986.html), that is, substituted by the string %20. * Percent signs (%) MUST be escaped according to percent encoding as defined by [**RFC 3986**](https://datatracker.ietf.org/doc/html/rfc3986.html), that is, substituted by the string %25. * No single or double quotes are allowed surrounding the values. ## Entra ID Institutions can enable multifactor authentication based on Entra ID if the Entra ID login method has been enabled in the Customer Portal. A *norEduPersonAuthnMethod* attribute needs to be added to every user who should be able to use this mechanism. This attribute is multivalued and MUST contain the following fixed string identifying the *Entra ID* multifactor method in Feide: `urn:mace:feide.no:auth:method:azuread -` This also indicates that the user has had their identity verified and that the multifactor authentication method has been provisioned to the user securely. When we authenticate a Feide user using Entra ID we validate the following claims of the access token: * `acr`: Has to be the value `1`. * `amr`: The list has to contain the value `mfa`. If and only if both of these are satisfied the multifactor authentication is successful. For more details on the access token and claims, see the [access token claims reference](https://learn.microsoft.com/en-us/entra/identity-platform/access-token-claims-reference). # MFA Examples The following are valid phone numbers to be used with SMS authentication: * +4701234567 * +34012345678 * +10123456789 The following are NOT valid phone numbers to be used with SMS authentication: * 004701234567 (it uses the 00 prefix instead of +) * 4701234567 (it does not use the international prefix +) * +470123456 (the number has incorrect length) * +47 01 23 45 67 (it contains spaces) * +1-012-345-6789 (it contains dashes) The following are valid secrets to be used with the Authenticator method: * ABCDEFGHIJ234567 * MKMPIDBZ2UOUSCTZ * ABCDEFGHIJKLMNOP * 2345672345672345 The following are NOT valid secrets to be used with the Authenticator method: * abcdefghijklmnop (it uses lowercase characters) * 0123456789012345 (it uses numbers other than those from 2 to 7) * 0123456789 (it uses invalid numbers and is shorter than 16) * 234567ABC (it uses valid characters and numbers but is shorter than 16). * ABCDEFGHIJKLMNOPQRSTUVWXYZ (it uses valid characters but is longer than 16) * ABC +=1234567DEF (it uses invalid symbols) The following are valid values for the *norEduPersonServiceAuthnLevel* attribute. Please note that line feeds are used for display purposes and should be disregarded: * `urn:mace:feide.no:spid:all urn:mace:feide.no:auth:level:fad08:3` (enable multifactor authentication for all services) * `urn:mace:feide.no:spid:123 urn:mace:feide.no:auth:level:fad08:3` (enable multifactor authentication for the service with Service ID number 123) The following are valid values for the *norEduPersonAuthnMethod* attribute. Please note that line feeds are used for display purposes and should be disregarded. * For a device labeled “Mobile” ```none urn:mace:feide.no:auth:method:ga eyJhbGciOiAiUlNBLU9BRVAiLCAiZW 5jIjogIkExMjhDQkMtSFMyNTYifQ.X7IU3zolmVtGzXxfKIxJLyvP5KNnqEdDG JBQNx8Y8VwvvdoeGjTiiU0V5OJKykylEhUITVTQ1l5snlBndVtVSjlkhK7CVZx 12OUcferIIC90tBg-GJRbom-RWVIYbXdB1jcUwMaUPZB49yoquhP1mTfFv76e9 5uize124XfyowcrM6dnPWhSSuPgDzp3_oA8e5Z6U1qzm-mDHe3BF1krNBXQjwx HWY4lC1zd7wbIGhBcngqmK8-ebRyDelMUpbOSgADWiQxdTeEkXVSOEn3JKiRuo YhggePNWM1rGnarooUktnuxdK6pggRSIAPkzM-ghJEDPtuk5gc5NSWNBE0x3g. LgmSqnSduW8WnpUjPfF4Gg.In2Wd2AU-6OMRxFily8EbKtmG4gC5EnKyyYZthk aM9w.MWE29ywstyWKCrCUttUYZg label=Mobile ``` * For a device labeled “My mobile phone” ```none urn:mace:feide.no:auth:method:ga eyJhbGciOiAiUlNBLU9BRVAiLCAiZW 5jIjogIkExMjhDQkMtSFMyNTYifQ.X7IU3zolmVtGzXxfKIxJLyvP5KNnqEdDG JBQNx8Y8VwvvdoeGjTiiU0V5OJKykylEhUITVTQ1l5snlBndVtVSjlkhK7CVZx 12OUcferIIC90tBg-GJRbom-RWVIYbXdB1jcUwMaUPZB49yoquhP1mTfFv76e9 5uize124XfyowcrM6dnPWhSSuPgDzp3_oA8e5Z6U1qzm-mDHe3BF1krNBXQjwx HWY4lC1zd7wbIGhBcngqmK8-ebRyDelMUpbOSgADWiQxdTeEkXVSOEn3JKiRuo YhggePNWM1rGnarooUktnuxdK6pggRSIAPkzM-ghJEDPtuk5gc5NSWNBE0x3g. LgmSqnSduW8WnpUjPfF4Gg.In2Wd2AU-6OMRxFily8EbKtmG4gC5EnKyyYZthk aM9w.MWE29ywstyWKCrCUttUYZg label=My%20mobile%20phone ``` * For a device labeled “% = %” ```none urn:mace:feide.no:auth:method:ga eyJhbGciOiAiUlNBLU9BRVAiLCAiZ W5jIjogIkExMjhDQkMtSFMyNTYifQ.X7IU3zolmVtGzXxfKIxJLyvP5KNnqEdD GJBQNx8Y8VwvvdoeGjTiiU0V5OJKykylEhUITVTQ1l5snlBndVtVSjlkhK7CVZ x12OUcferIIC90tBg-GJRbom-RWVIYbXdB1jcUwMaUPZB49yoquhP1mTfFv76e 95uize124XfyowcrM6dnPWhSSuPgDzp3_oA8e5Z6U1qzm-mDHe3BF1krNBXQjw xHWY4lC1zd7wbIGhBcngqmK8-ebRyDelMUpbOSgADWiQxdTeEkXVSOEn3JKiRu oYhggePNWM1rGnarooUktnuxdK6pggRSIAPkzM-ghJEDPtuk5gc5NSWNBE0x3g .LgmSqnSduW8WnpUjPfF4Gg.In2Wd2AU-6OMRxFily8EbKtmG4gC5EnKyyYZth kaM9w.MWE29ywstyWKCrCUttUYZg label=%25%20%3D%20%25 ``` The following are *NOT* valid values for the *norEduPersonAuthnMethod* attribute. Please note that line feeds are used for display purposes and should be disregarded. * The method identifier URN does not correspond with Feide’s Authenticator method ```none urn:mace:feide.no:auth:method:authenticator eyJhbGciOiAiUlNBLU9 BRVAiLCAiZW5jIjogIkExMjhDQkMtSFMyNTYifQ.X7IU3zolmVtGzXxfKIxJLy vP5KNnqEdDGJBQNx8Y8VwvvdoeGjTiiU0V5OJKykylEhUITVTQ1l5snlBndVtV SjlkhK7CVZx12OUcferIIC90tBg-GJRbom-RWVIYbXdB1jcUwMaUPZB49yoquh P1mTfFv76e95uize124XfyowcrM6dnPWhSSuPgDzp3_oA8e5Z6U1qzm-mDHe3B F1krNBXQjwxHWY4lC1zd7wbIGhBcngqmK8-ebRyDelMUpbOSgADWiQxdTeEkXV SOEn3JKiRuoYhggePNWM1rGnarooUktnuxdK6pggRSIAPkzM-ghJEDPtuk5gc5 NSWNBE0x3g.LgmSqnSduW8WnpUjPfF4Gg.In2Wd2AU-6OMRxFily8EbKtmG4gC 5EnKyyYZthkaM9w.MWE29ywstyWKCrCUttUYZg label=Mobile ``` * The encrypted secret is not a valid secret ```none urn:mace:feide.no:auth:method:ga eyJhbGciOiAiUlNBLU9BRVAiLCAiZW 5jIjogIkExMjhDQkMtSFMyNTYifQ..MWE29ywstyWKCrCUttUYZg label=Mobile ``` * The Authenticator secret is not encrypted ```none urn:mace:feide.no:auth:method:ga ABCDEFGHIJ234567 label=Mobile ``` * The encrypted secret contains equal signs that are not percent encoded ```none urn:mace:feide.no:auth:method:ga eyJhbGciOiAiUlNBLU9BRVAiLCAiZ W5jIjogIkExMjhDQkMtSFMyNTYifQ.X7IU3zolmVtGzXxfKIxJLyvP5KNnqEdD GJBQNx8Y8VwvvdoeGjTiiU0V5OJKykylEhUITVTQ1l5snlBndVtVSjlkhK7CVZ x12OUcferIIC90tBg-GJRbom-RWVIYbXdB1jcUwMaUPZB49yoquhP1mTfFv76e 95uize124XfyowcrM6dnPWhSSuPgDzp3_oA8e5Z6U1qzm-mDHe3BF1krNBXQjw xHWY4lC1zd7wbIGhBcngqmK8-ebRyDelMUpbOSgADWiQxdTeEkXVSOEn3JKiRu oYhggePNWM1rGnarooUktnuxdK6pggRSIAPkzM-ghJEDPtuk5gc5NSWNBE0x3g .LgmSqnSduW8WnpUjPfF4Gg.In2Wd2AU-6OMRxFily8EbKtmG4gC5EnKyyYZth kaM9w.MWE29ywstyWKCrCUttUYZg=== label=Mobile ``` * The label contains spaces and percent signs that are not percent encoded ```none urn:mace:feide.no:auth:method:ga eyJhbGciOiAiUlNBLU9BRVAiLCAiZ W5jIjogIkExMjhDQkMtSFMyNTYifQ.X7IU3zolmVtGzXxfKIxJLyvP5KNnqEdD GJBQNx8Y8VwvvdoeGjTiiU0V5OJKykylEhUITVTQ1l5snlBndVtVSjlkhK7CVZ x12OUcferIIC90tBg-GJRbom-RWVIYbXdB1jcUwMaUPZB49yoquhP1mTfFv76e 95uize124XfyowcrM6dnPWhSSuPgDzp3_oA8e5Z6U1qzm-mDHe3BF1krNBXQjw xHWY4lC1zd7wbIGhBcngqmK8-ebRyDelMUpbOSgADWiQxdTeEkXVSOEn3JKiRu oYhggePNWM1rGnarooUktnuxdK6pggRSIAPkzM-ghJEDPtuk5gc5NSWNBE0x3g .LgmSqnSduW8WnpUjPfF4Gg.In2Wd2AU-6OMRxFily8EbKtmG4gC5EnKyyYZth kaM9w.MWE29ywstyWKCrCUttUYZg label=My mobile %phone ``` The following is a valid QR code to configure an Authenticator instance with the label My device and the secret ABCDEFGHIJ234567: ![Authenticator QR-code](reference/mfa/images/multifactor-deploy-qr.png) # OpenID Connect and OAuth 2.0 * [User IDs](userids.html.md) * [OpenID Connect details](openid_connect_details.html.md) * [Logout](logout.html.md) # User IDs How to identify users, people, and accounts within Feide. Feide with OIDC/OAuth is not limited to a single kind of user ID. Each user is at least issued a unique, opaque user ID and a user ID determined by the user’s login provider. ## Subject identifier - The main OIDC user ID The subject identifier is an opaque UUID, which does not reveal any information about the user. It is intended to be long-term and survive mergers of schools and universities. The subject identifier is generated the first time a user logs in with OpenID Connect (OIDC). For Feide users that have not yet logged in with OIDC, an identifier is generated automatically within a few hours of the account being created. Consequently, recently created Feide users and other users that have not yet logged in with OIDC may not have a subject identifier. In this case, other user IDs will still be available. The subject identifier is available as the claim [sub](../apis/userinfo.html.md#ref-sub): ```json { "sub": "7b96eab9-b69e-4b8c-9636-1da868207864" } ``` ## Other user IDs A user will always have one other user ID besides the subject identifier. It will be available in its own claim, and which user ID this is depends on the [login provider](../../service_providers/manage/openid_connect/login_providers.html.md) that holds the user account. A Feide ID and national identity number may additionally be exposed through their own dedicated claims. ### Namespaced user ID Each user has a single namespaced user ID on the format `:`. If the corresponding attribute group is granted, the user ID is included in the claim [https://n.feide.no/claims/userid_sec](../apis/userinfo.html.md#ref-https-n-feide-no-claims-userid-sec). This is a string array with at most one element. The namespaced user ID mainly serves to link the user identity from the login provider to the account in Feide. As such, the login provider of the user determines which user ID appears in the claim. Below are a few examples that illustrate this: When Feide is the login provider and the application is granted the `userid-feide` attribute group, the claim looks like this: ```json { "https://n.feide.no/claims/userid_sec": [ "feide:olanor@example.org" ] } ``` When ID-Porten is the login provider and the application is granted the `userid-nin` attribute group, the claim looks like this: ```json { "https://n.feide.no/claims/userid_sec": [ "nin:10108012345" ] } ``` When eduGAIN is the login provider and the application is granted the `userid-edugain` attribute group, the claim looks like this: ```json { "https://n.feide.no/claims/userid_sec": [ "edugain:https%2A//some.edugain.idp/entityId:user@some-edugain.org" ] } ``` Note that the colon (`:`) in the eduGAIN identifier part is used as a separator. Because of this, any colon (`:`) or percentage (`%`) characters used in the distinct parts of the identifier are URL-encoded. ### Feide identifier If the user has a Feide account and the application is granted the `userid-feide` attribute group, the Feide ID is exposed through the dedicated claim [https://n.feide.no/claims/eduPersonPrincipalName](../apis/userinfo.html.md#ref-https-n-feide-no-claims-edupersonprincipalname): ```json { "https://n.feide.no/claims/eduPersonPrincipalName": "olanor@example.org" } ``` ### National identity number If the national identity number is available and the application is granted the `userid-nin` attribute group, it is exposed through the dedicated claim [https://n.feide.no/claims/nin](../apis/userinfo.html.md#ref-https-n-feide-no-claims-nin): ```json { "https://n.feide.no/claims/nin": "10108012345" } ``` # OpenID Connect details OpenID Connect (OIDC) is a simple standardized identity (authentication) layer on top of OAuth 2.0. After a successful login, the user agent is in possession of an access token and an [ID token](#id-token). The access token looks the same as for plain OAuth2. The ID token is a signed [JSON Web Token](https://jwt.io/introduction/) with info about the user. The information is also available from the userinfo endpoint described in the reference doc: [Userinfo Endpoint](../apis/userinfo.html.md). ## Discovery and configuration All you need to know in order to configure your OpenID Connect client to the Feide platform is available through the discovery endpoint: - [https://auth.dataporten.no/.well-known/openid-configuration](https://auth.dataporten.no/.well-known/openid-configuration) ## Client registration In order to access the Feide APIs, you need to register your application, and obtain the OIDC/OAuth credentials for your application. The customer portal allows Feide administrators to register and manage applications. When registering a client, you need to know the redirect URI endpoint of your application. This is under the configuration tab when editing the service. ![Screenshot of adding Redirect URI to a configuration](reference/oauth_oidc/images/oidc_add_redirect_uri.png) *Screenshot of adding Redirect URI to a configuration* ## Scopes, claims and attribute groups In the Feide customer portal, administrators allow or deny access to information in *attribute groups*. These mean the same for SAML and OpenID Connect. Developers of OpenID Connect applications will encounter two additional concepts: scopes : Access tokens carry *scopes* which determine which information can be retrieved. The concept is defined in the OAuth2 standard. The OpenID Connect standard defines some standardized scopes. claims : Each piece of information in ID token and OpenID Connect userinfo is a *claim*. Some claims are specified in the OpenID Connect standard. Others are specific to Feide and defined by us. The authorization request takes a `scope` parameter. It can be used to request what information the access token should grant access to. However, the `openid` scope is special. Instead of requesting access to information, it is used to tell OpenID Connect apart from other variants of OAuth2. The application should include `openid` in the request. If you are using an OIDC library, this is probably already taken care of. When adding an OpenID Connect configuration in the customer portal, the scopes `openid` and `userid` are automatically authorized.. Those are not visible in the user information tab for the service. Typically, the authorization request will only mention the `openid` scope. The resulting access token will be authorized for all attribute groups that are configured for the service. If a more restrictive access token is wanted, the desired scopes can be requested explicitly. Names of attribute groups can be used as scopes in Feide. In addition, some scopes are defined in the standard. According to the standard, `profile` requests name and photo. Which of these, if any, are returned depends on which of the attribute groups `userinfo-name` and `userinfo-photo` are authorized in the customer portal. The standardized scope `name` works if `userinfo-name` is authorized, and `picture` needs `userinfo-photo`. ## OpenID Specifications - [OpenID Connect Core](https://openid.net/specs/openid-connect-core-1_0.html) - [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html) ### Supported features - Authorization Code flow response_mode: `code` - Implicit grant flow response_mode: `id_token token` - Hybrid flow response_mode: `code id_token` - ID token signed with PKI (RS256) - [Proof Key for Code Exchange (PKCE)](https://oauth.net/2/pkce/) may be used with authorization code flow and hybrid flow. code_challenge_method: `S256` Implicit grant flow response_mode: `id_token token` is also still supported. But due to weak security, it should be avoided for new clients. Existing clients should migrate to authorization code flow with PKCE. Dynamic registration is not supported. ### Requiring a specific authentication level The application can request a specific authentication level via the optional `acr_values` parameter. For more details refer to [this page](../../service_providers/mfa/openid_connect.html.md). An organization can also request a specific authentication level for some or all users, see the [multifactor authentication deployment guide](../../general/mfa_guide.html.md). ### Login hints - bypassing the login discovery page The default behaviour when a client sends the end user to Feide for authentication is that the user first meets either the account chooser or the ID-provider discovery page. Sometimes the client may want to let the user bypass the discovery page / accountchooser and go to a specific ID provider. This is possible by using the OpenID login_hint parameter to the authorization endpoint. The following prerequisites needs to be met to use this functionality: - The client owner needs to configure the client to not require user interaction. This can be done using the customer portal on the OIDC-configuration when editing the service. Uncheck the checkbox «Always require user interaction». ![Screenshot of require user interaction](reference/oauth_oidc/images/require_user_interaction.png) *Screenshot of require user interaction* - Consider the security implications of allowing Single Sign-on to automatically login users to your site without user interaction. - Make sure that the `openid` scope is included in the authentication request. If not, the request is interpreted as a plain OAuth request, and then the login hint functionality is not supported The login_hint parameter is sent as part of the authentication request to Feide as a query string parameter. The parameter may have one of these values: `feide|all` Automatically send user to Feide login page with no specific organization preselected. Feide will remember if the user has selected an organization previously. `feide|realm|uninett.no` Automatically send user to Feide login page with the specific organization Uninett. Uninett will then be preselected in the Feide login page. `feide|realm|uninett.no|andreas@uninett.no` Automatically send user to Feide login page with the specific organization Uninett. Uninett will then be preselected in the Feide login page. Also specify which user we expect to login. If user tries to login with another account the user will get an warning that the user was not expected, but the userID is not enforced beyond that. `idporten` Automatically send user to ID-porten. `eidas` Automatically send user to eIDAS (European authentication framework). `edugain|urn:mace:entity` Automatically send user to the Identity Provider with entity ID `urn:mace:entity` via eduGAIN. `openidp` Automatically send user to Feide’s OpenIdP (guest accounts). ## ID Token The ID token is a signed information object representing the authenticated identity of the user. It is specified in the OpenID Connect standard. The ID token is encoded as a JWT, and signed using the JWS standard. For details on Feide ID tokens see the [reference docs](../tokens.html.md#ref-id-token). The client must validate the ID token. In particular, the `iss` claim has to be `https://auth.dataporten.no` and the `aud` claim has to match the client id. See the section about [ID token validation](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) in the OIDC standard for full details. To see what is inside an ID token, the online JWT debugger at [https://jwt.io](https://jwt.io) is useful. # Logout If your application uses OpenID Connect, you can use the logout mechanism described in [OpenID Connect logout](../../service_providers/manage/openid_connect/redir_etter_logout.html.md). It lets you control which page the user is redirected to after logging out. In the application, include a logout link that performs the following: * First, kills the local session for the current user. * Then, redirects the user to the *end session endpoint*. The user will then automatically be logged out from the Feide core platform, as well as the authentication source Feide, ID-porten or similar, and the end user will be shown a page telling the user he/she is now successfully logged out. Notice that the end user will not be automatically logged out from other Feide applications. For OpenID Connect applications, the end session endpoint is `https://auth.dataporten.no/openid/endsession`. For legacy applications, it is `https://auth.dataporten.no/logout`. # SAML 2.0 * [Introduction](saml2_technical_guide.html.md) * [SAML in Feide](saml2_technical_guide.html.md#saml-in-feide) * [The user’s Feide session](saml2_technical_guide.html.md#the-users-feide-session) * [Metadata](saml2_technical_guide.html.md#metadata) * [User attributes](saml2_technical_guide.html.md#user-attributes) * [Testing](saml2_technical_guide.html.md#testing) * [Technical requisites](saml2_technical_requisites.html.md) * [Selecting the user organization](selectorg.html.md) # Introduction This document is a companion to the [Feide Integration Guide](../../../service_providers/integration_guide/). It is recommended to read that document for a conceptual and architectural introduction to Feide. In this document you will find a more thorough discussion of the technical side of becoming a Feide integrated service provider. The first part of this document discusses how Feide implements SAML, and the next part gives an overview of the Feide user attributes. # SAML in Feide [Security Assertion Markup Language (SAML)](https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf) is a protocol framework for federated identity management. SAML is an XML-based standard. The Feide federation consist of 3 parties: - The Feide *Identity Provider* (IdP). - The *Service Provider* (SP). - The Feide user. There are many choices left to the developers when it comes to implementing SAML inside and across organizations. [Interoperable SAML 2.0 Profile](https://kantarainitiative.github.io/SAMLprofiles/saml2int.html) is an effort to specify a “least common denominator” for SAML federated Web based Single Sign-On (SSO). The Feide configuration is based on this profile and recommendations for [single logout (SLO)](#logout-slo). There are pre-made SAML handling libraries for the major web development platforms. We urge you to use one of these unless you have a compelling reason to do otherwise. To do a robust implementation of SAML protocol handling is a major undertaking. There is more about available software and integration in [Feide Integration Guide](../../../service_providers/integration_guide/) in the chapter Choose and deploy SAML 2.0 Service Provider software. ## SAML Messages During user login and logout SAML messages are communicated between the SP and IdP. How the messages are transmitted between IdP and SP is explained in [Bindings](#bindings) below. ### Login When an SP wants to authenticate a Feide user, an *authentication request* is sent from the SP to the IdP. The message is sent by redirecting the user to the IdP web page for authentication. ```xml urn:mace:feide.no:services:no.feide.openwikicore ``` *Example 1: Authentication request* A typical authentication request is shown in example 1. Key elements in the message are: 1. Unique **ID** for the request. The authentication response refers to this ID. 2. **Destination** endpoint URL for this request. This information is taken from the IdP metadata that have been imported into the SAML software. 3. **ProtocolBinding** indicates how the response message is to be transported from the IdP to the SP. Bindings are briefly explained in [Bindings](#bindings) below. 4. **AssertionConsumerServiceURL** is the destination URL for the authentication response message sent back from the IdP to the SP. 5. **Issuer** is the *entityID* for this service. Upon successful authentication the browser is instructed to post the authentication response message by HTTP-post binding to the *AssertionConsumerServiceURL* at the SP. ```xml https://idp.feide.no CUT: Assertion part shown separately ``` *Example 2: Authentication response* A typical authentication response is shown in example 2. The *Assertion* part of the message is separated out and shown in example 3. Key elements in the message are: 1. **InResponseTo** refers to the message *ID* in the *AuthnRequest* message. 2. **Issuer** is the *entityID* for the IdP. 3. The value of the **StatusCode** indicates whether the authentication was successful or not. ```xml https://idp.feide.no CUT: Lot of signature markup _508ddf0c3974b7a5951f5879e0796f97be449fcfdd urn:mace:feide.no:services:no.feide.openwikicore urn:oasis:names:tc:SAML:2.0:ac:classes:Password CUT: Lots of attribute markup shown separately ``` *Example 3: Assertion part* Key elements in the assertion part are: 1. The assertion is signed to prevent tampering with the message. 2. **SessionNotOnOrAfter** indicates the lifetime of this assertion. Session timing is discussed in [The user’s Feide session](#the-users-feide-session) below. 3. The **SessionIndex** is an ID for the IdP session. 4. The value of **AuthnContextClassRef** indicates how the user was authenticated. Feide supports password and multi factor authentication. 5. In the *Assertion* you will also find an **AttributeStatement**. The attributes transmitted to the SP are contained in the *AttributeStatement*. You find a description of the formatting of the attributes in [SAML Assertion](#saml-assertion) below. ### Logout Feide supports logout from one single service at a time or Single Logout (SLO) from all the services in the Feide federation where the user is logged in. A *LogoutRequest* message is sent to an entity to request a logout from that entity. That entity responds by sending a *LogoutResponse* message. The *LogoutResponse* indicates whether the logout was successful or not. Depending on the mode of logout the SP may send a *LogoutRequest* to the IdP or receive a *LogoutRequest* from the IdP. The SLO modes are explained in [Logout SLO](#logout-slo). ```xml urn:mace:feide.no:services:no.feide.openwikicore _508ddf0c3974b7a5951f5879e0796f97be449fcfdd _64da5b6b8235a8f13433e1604a1e0b31c1cd1bbb7d ``` *Example 4: Logout request* A logout request example is shown in example 4. Key elements in the message are: 1. **NameID** is an identification of the subject (the user) of the messages and has to match the *NameID* in the *Assertion* message, here shown in example 3. 2. The **SessionIndex** is the *SessionIndex* from the login assertion. ```xml https://idp.feide.no ``` *Example 5: Logout response* A *LogoutResponse* example is shown in example 5. Key elements in the message are: 1. The **InResponseTo** value is the *ID* from the *LogoutRequest* this is a response to. 2. The value **StatusCode** indicates whether the logout was successful or not. ## Bindings The bindings specify how the SAML messages are transported between the SP and IdP. As specified in the [SAML profile](https://kantarainitiative.github.io/SAMLprofiles/saml2int.html), Feide only uses the HTTP-redirect and HTTP-post bindings. This means that all SAML messages are transported through the user’s web browser, piggy-backed on the various HTTP requests and replies. This is called front-channel communication. It eliminates the hassle of establishing a direct communication path between SP and IdP. The binding can be illustrated by the login transaction as shown in illustration 1. 1. The user tries to access a protected web page at the SP. 2. The SP SAML functionality instructs the user’s web browser (by redirect) to visit the login page at the IdP. An encoded version of the *AuthnRequest* is appended to the URL. 3. Upon successful authentication, the web browser receives a page including a hidden form control. The authentication response is encoded in this form. The browser is also instructed by a script to post this data to the SAML consumer endpoint at the SP. The same principle is used for logout, except that logout only uses redirects. ![Figure showing the SAML message flow during a login. The process starts with the user accessing a protected page on a service. The service redirects the users web browser to Feide. The redirect includes a SAMLRequest parameter that contains a SAML 2.0 authentication request. Feide then sends a SAML 2.0 authentication response back to the service. The response is sent in the SAMLResponse parameter in a HTTP POST request.](reference/saml/images/SAMLMessageFlow.png) *Illustration 1: SAML Message flow during login* ## Signing For securing SAML communication, Feide relies on SSL/HTTPS security. This means that the SAML messages are encrypted in the communication channel between the user’s browser and the service endpoint and the browser and the IdP endpoint. But the SAML messages pass through the user’s web browser unencrypted. To prevent tampering with the assertion message on the user’s client computer, the Feide IdP signs the assertion message in the *authentication response*. The Feide IdP’s public certificate is embedded in the metadata for the IdP. ## Profile Profiles define specific sets of rules for using SAML for a specific task. The following chapters are a summary of the login and logout profile used in Feide. ### Login Feide is loosely based on the [Interoperable SAML 2.0 profile specification](https://kantarainitiative.github.io/SAMLprofiles/saml2int.html). This is a summary of the specification, adapted to its usage in Feide. The authentication request message: - Uses either the HTTP-redirect or the HTTP-POST binding. Please note that even though the HTTP-POST binding is allowed for sending *authentication request* messages, the use of the HTTP-redirect binding is recommended and encouraged. - Is not signed. - Must include AssertionConsumerURL. - Must not include RequestedAuthnContext. - Should, for the *NameIDPolicy,* set *AllowCreate* to *true*. - Should, for the *NameIDPolicy,* set *nameid-format* to *transient*. The authentication response message: - Uses the HTTP-post binding. - SP must support unsolicited responses. This is to support the cases where the user *bookmarks* the IdP login page. - Includes the user attributes. - Attributes name format is *basic*. More information about attribute names in [SAML Assertion](#saml-assertion). SAML endpoints must use SSL/HTTPS. ### Logout SLO The Feide IdP supports Single Logout (SLO). The SPs have to handle two different scenarios to properly handle SLO. Illustration 2 shows an example where one user is logged into three SPs. When the user chooses to logout from SP1, then SP 1 initializes a logout by sending a *LogoutRequest* to the IdP. Then the user selects to logout from all the services. The IdP initializes logout on the rest of the SPs (SP 2 and SP 3) by sending a *LogoutRequest* to each of them. The SPs will perform a local logout and respond to the IdP by sending a *LogoutResponse* message back to the IdP. When the IdP has completed all the logouts it will respond to SP 1 by sending a *LogoutResponse* message to SP 1. The user may initialize a SLO from any of the SPs. This means that any SP should be able both to send *LogoutRequest* messages and to respond to incoming *LogoutRequest* messages from the IdP. Recommendation for Service Provider: - *Should be able to initialize Single Logout from the service by sending a LogoutRequest* message to the IdP. - Should be able to handle incoming *LogoutRequest* messages from the IdP. If it is able to initialize *Single Logout*, it must be able to handle incoming *LogoutResponse* messages. ![Figure showing the message flow during logout. The logout process starts with a service sending a SAML 2.0 logout request to Feide. Feide then sends a SAML 2.0 logout request to two other services the user is logged into. For each service it waits for a SAML 2.0 logout response. Once it receives a SAML 2.0 logout response from the last service, it sends a SAML 2.0 logout response back to the service that started the logout process.](reference/saml/images/SLOMessaging.png) *Illustration 2: SLO message flow* Feide Identity Provider: - Handles Single Logout initiated by any of the connected Service Providers. - Interacts with the user to let the user select SLO or only logout from the IdP and the SP where logout was initialized. The logout request message is: - Sent by either the HTTP-redirect or HTTP-POST binding. Please note that even though the HTTP-POST binding is allowed for sending *authentication request* messages, the use of the HTTP-redirect binding is recommended and encouraged. # The user’s Feide session When the user does a “fresh” login on the IdP for the first time, an IdP session is created. The user’s attributes are fetched from the home organization and are cached in the session storage. The IdP session has a lifetime of 8 hours from the username and password is entered. During this 8-hour session the user will be able to directly access services without entering the username and password again. If the user tries to access a service after the 8-hour session has expired, a new Feide login is initiated and a new 8-hour session is created. ![Figure showing various loging session lifetimes in Feide. The figure shows the session lifetimes for the user logging into three services in a day. The user logs into the first service (SP 1) in the morning. This creates two sessions - a IdP session in Feide and a session in SP 1. Both of those sessions have a lifetime of eight hours. The user then accesses a second service (SP 2) later in the day. Since this is within the lifetime of the initial IdP session, the user does not need to log into Feide again. After the login, the user has a new session in SP 2 that is valid for eight hours. The lifetime of the initial IdP session Feide is unchanged. The user then accesses a third service (SP 3) even later in the day. This happens more than eight hours after the first login in the day. The initial IdP session is therefore expired, and the user has to log in again. This creates a new IdP session and a session in SP 3. Both of these sessions have a lifetime of eight hours.](reference/saml/images/SessionLifetime.png) A new session is created on each SP when the SP receives the assertion from the IdP. The SP session lifetime is also set to 8 hours. In the assertion part in the authentication response message is an *AuthnStatement* tag (example 6). This tag contains some attributes relevant to session timings. ```xml ``` *Example 6: Authentication statement* 1. The **SessionNotOnOrAfter** attribute is a time stamp set to 8 hours after the authentication assertion was sent. The SP must adhere to this time limit and initiate a new login if the user tries to access the resource after this time has expired. The login session can be terminated in one of three ways: 1. The user selects logout. 2. The user closes the web browser. The IdP and SP session cookies are automatically deleted. 3. The IdP session is automatically terminated 8 hours after the username and password was entered. The SP session is automatically terminated 8 hours after the SP received the assertion. # Metadata Before your SP and the Feide IdP can operate in a federation, the entities must exchange SAML Metadata. Feide operates both a test IdP and a production IdP. - The Feide test IdP metadata can be downloaded as XML from this link: [https://idp-test.feide.no/simplesaml/saml2/idp/metadata.php](https://idp-test.feide.no/simplesaml/saml2/idp/metadata.php) - Or found formatted for web on this link: [https://idp-test.feide.no/simplesaml/saml2/idp/metadata.php?output=xhtml](https://idp-test.feide.no/simplesaml/saml2/idp/metadata.php?output=xhtml) - And the Feide production IdP metadata can be downloaded from: [https://idp.feide.no/simplesaml/saml2/idp/metadata.php](https://idp.feide.no/simplesaml/saml2/idp/metadata.php) Metadata must be generated for your SP. This is usually done by the SAML library you are using. An SP metadata example is shown in example 7. ```xml urn:oasis:names:tc:SAML:2.0:nameid-format:transient Andreas Åkre Solberg andreas@uninett.no ``` *Example 7: Service metadata* The most important metadata entries: 1. **entityID** This is a unique ID for your service. It should either be a URN or a URL. 2. **SingleLogoutService** The *Location* attribute is the URL where logout requests and responses are handled. If this endpoint is available, it must be able to both send *LogoutRequests* and handle incoming *LogoutRequests*. 3. **AssertionConsumerService** The *Location* attribute is the URL where authentication responses sent from the IdP will be posted. If the *entityID* is a URL it should be a URL pointing to the metadata for the service. An URN *entityID* should be a part of Feide’s URN-namespace `“urn:mace:feide.no:services:”` and consist of 3 parts separated by dot (.): 1. *no* for Norwegian service providers or the ccTLD for the country of origin of the service provider. 2. The subdomain name for the service provider. 3. A descriptive name for the service offered. The name should be unique in the service provider’s DNS namespace. The *entityID* in example 7 shows a URN formatted entity id. # User attributes User attributes carry different pieces of information about the user, the user’s home organization and the user’s school. It may be information like name, role, school affiliations etc. When the Feide IdP has successfully authenticated the user against the user directory at the user’s home organization, the Feide IdP will retrieve a set of attributes from the directory. After the Feide IdP has retrieved the attributes, it will process and filter the attributes before it passes them on according to the agreements between Feide and the SP. ## Information model There are three documents describing the Feide information model: - The [norEdu\* Object Class Specification](../../../reference/schema/noredu/) describing how the attributes are organized. The norEdu\*-specification is based on *eduPerson*, *eduOrg* and some other LDAP schemas. - Feide requirements for primary and secondary education. - Feide requirements for higher education. To understand the Feide information model, it is important to understand that the Feide federation has members from two parts of the Norwegian educational sector: - higher education (with universities and university colleges) - primary and secondary education These two parts are organized differently as regards to ownership and internal structures, which affect the Feide information model. Essential to the Feide information model is that each person is associated with one top organization (the *home organization*) and possibly one or more organization units. This is shown in illustration 4. ![All Feide users are associated with one home organization and possibly one or more organization units.](reference/saml/images/user-org.png) *Illustration 4: All Feide users are associated with one home organization and possibly one or more organization units.* For students, employees and other persons in higher education, the home organization is the university / university college. Organization units are various faculties or departments within the top organization. There is no requirement that a person in higher education should be associated with an organization unit, and Feide puts no requirements on which attributes should be registered for organization units in higher education. ![Trondheim kommune example](reference/saml/images/user-org-ex1.png) *Illustration 5: A pupil must be associated with both a top organization and at least one organization unit. In this example, the top organization is Trondheim kommune (the municipality) and the organization unit is Nyborg skole (the school).* Because of different organization and owner structures in primary and secondary education, the Feide information model for primary and secondary education is different from higher education. For pupils, teachers and other persons in primary and secondary education, the home organization is the owner of the school, in most cases the municipality/county. All the schools owned by the same municipality/county are organization units under the home organization. All persons in primary and secondary education are associated with at least one organization unit (one school). Feide puts specific requirements on which attributes should be registered for organization units in primary and secondary education. An example of how this might be is shown in illustration 5. If the service is to do authorization based on school affiliation, it is crucial to understand how higher education and primary and secondary education are represented in Feide. The following list summarizes the various organization types: * Higher education: **Home organization**: University, university college (e.g. Universitetet i Oslo) **Organization units**: Various departments and faculties (e.g. Faculty of Humanities) **Organization unit requirements**: Feide places no requirements on the organization units. They are optional. For schools that have them, they can contain any kind of organization unit data. * Secondary education: **Home organization**: County e.g. (Rogaland fylkeskommune) **Organization units**: Secondary schools (e.g. St. Svithun videregående skole) **Organization unit requirements**: It is mandatory to register the users schools as organization units. * Primary education: **Home organization**: Municipality (e.g. Trondheim kommune) **Organization units**: Primary schools (e.g. Nyborg skole) **Organization unit requirements**: It is mandatory to register the users schools as organization units. ## Attribute availability The availability of attributes is governed by the [norEdu\* Object Class Specification](../../../reference/schema/noredu/) together with the Feide requirements for primary and secondary education and higher education respectively. These documents state what information should be registered about each user and how the user directory should be organized. The *norEdu\* Object Class Specification* has been released in several versions. As a result of this, some organizations are using an older version of the specification and do not necessarily have all the attributes required by the latest specification. A list of user attributes available for services is [available here](../schema/attributes/index.html.md). ### Name Due to the fact that not all home organizations adhere to the latest *norEdu\* Object Class Specification*, there is today no single attribute that is guaranteed to hold the user’s name. A suggested strategy to get a name value to use in the application is as follows: 1. Check if the user has a *displayName* and use that. If not present… 2. Check if the user has one or several [givenName](../schema/attributes/givenname.html.md#saml-attribute-givenname) attributes; select the first one and join with the first value from *sn* (surname) if you want to display full name. If not present… 3. Use the first value from *cn* (common name) ### User id When it comes to selecting a user ID we have to balance between two conflicting demands – the services’ demand for a unique and persistent id and the users’ demand for anonymity and privacy. The possible user IDs should be considered in the following order: 1. *eduPersonTargetedID*: This ID gives anonymous user authentication, but still gives the service the ability to track a particular user from login session to login session. This ID is different on different services for a particular user. 2. *eduPersonPrincipalName*: This is the “Feide ID”. This is a valid and unique user ID as long as the person is a member of an educational institution. 3. *norEduPersonNIN*: This is intended as a lifelong personal identity number. Where a key is needed to combine information from other governmental information sources, this ID can be used. ### Schools As described in section 5.1, higher education and primary and secondary education are organized in different ways and this affects the Feide information model. To simplify, Feide can release the attribute *feideSchoolList* to SPs that request information about the users’ schools. feideSchoolList is a multivalued attribute with the following properties: - Contains the schools’ organization numbers, which uniquely identify the schools. - If there is a primary school registered for the user, this school is listed first. - For users in higher education, only the organization number of the home organization is listed. ### Grades and subjects For pupils in primary and secondary education it is intended to populate the *eduPersonEntitlement* attribute with Grep-codes. Grep-codes can be used to express a pupil’s grade, subjects, major area etc. For further information please contact Feide. ## SAML Assertion The attributes are transmitted from the IdP to the SP wrapped in a SAML assertion. The SAML specification only specify an attribute name-value pair relationship. It does not specify how to map a tree like information structure into a flat name-value pair message structure. This chapter will explain how Feide organizes this information in the SAML assertion. ### Attribute value letter case User identity values like *eduPersonPrincipalName* are by definition case insensitive. However, Feide preserves case for attribute values and some home organizations have saved the values with both uppercase and lowercase letters. We therefore recommend doing case insensitive matching when *eduPersonPrincipalName* is used as a user identity key in the SP system. ### Referenced objects and namespaces ```xml ``` *Example 8: Attribute name* All attributes carrying information about the user’s home organization are prefixed by “eduPersonOrgDN”, and all attributes carrying information about the user’s organization units are prefixed by “eduPersonOrgUnitDN”. The prefix and the attribute name are joined with colon (:). The notation is shown in example 8. ### Multivalued attributes The SAML assertion message snippet in example 9 shows an example where *eduPersonAffiliation* has multiple values. There is no particular ordering of the attribute values. ```xml employee member ``` *Example 9: Multivalued attribute* ### Several orgUnits The user may be tied to several orgUnits. The Feide IdP does some custom mapping to be able to convey this information to the service via the assertion message. ![Multiple org units mapping](reference/saml/images/orgUnitMapping_color.png) *Illustration 6: Multiple org units mapping* The value for each attribute name in each orgUnit object is grouped together as a multivalued attribute in the assertion message. This mapping is illustrated in 6, and example 10 shows an example message. This mapping is done consistently, so for each attribute name in the assertion message, the first value is always from the first orgUnit object and so on. An empty value is inserted if an orgUnit object is missing this attribute. ```xml Eksterne tjenester Tjenesteavdeling ``` *Example 10: Attribute from multiple OrgUnits* This mapping alters the semantic meaning of multivalued attributes in the assertion message for orgUnits. So, in the cases where the *orgUnit* attribute is already multivalued, this has to be encoded in a different way. The multivalued attributes are joined together with the pipe (|) symbol as a separator. Example 11 shows an example where the *ou* attribute has two values. ```xml ET|Eksterne Tjenester TA|Tjenestavdelingen ``` *Example 11: Multivalued attribute from multiple OrgUnits* # Testing Feide has some infrastructure to facilitate integration testing for service providers. - Test IdP to test the SP ↔ IdP communication and metadata compatibility. The test IdP metadata is found at: [https://idp-test.feide.no/simplesaml/saml2/idp/metadata.php?output=xhtml](https://idp-test.feide.no/simplesaml/saml2/idp/metadata.php?output=xhtml) To start testing your service, it must be integrated with the Feide test IdP. This is done by exchanging metadata with this IdP. Feide has a test user. >
> > > > > > > > > > > > > > > >
OrganizationFeide
Usernametest
Password098asd
>
Feide IdP-test stores a cookie in your browser. The name of this cookie is *SimpleSAMLSessionID*. You can delete this cookie when you do trial and error testing, to get back to a “clean state”. For further support, you can contact Feide support at e-mail address: [support@feide.no](mailto:support@feide.no) # Technical requisites Here is the list of technical requisites that all Service Providers must meet in order to connect to Feide. You can use it as a checklist to verify that you comply with all the requirements so that you are ready to proceed with integration. ## Requirements notation The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.txt). The use of SHOULD, SHOULD NOT, and RECOMMENDED reflects broad consensus on deployment practices intended to foster both interoperability and guarantees of security and confidentiality needed to satisfy the requirements of many organizations that engage in the use of federated identity. Deviating may limit a deployment’s ability to technically interoperate without additional negotiation, and should be undertaken with caution. ## Standards referenced Feide uses [Security Assertion Markup Language version 2.0](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) and supports the [Interoperable SAML 2.0 Web Browser SSO Deployment Profile](https://kantarainitiative.github.io/SAMLprofiles/saml2int.html). For more information about Feide as well as technical details for the integration, please refer to the [Feide Integration Guide](../../service_providers/integration_guide/) and the [Feide Technical Guide](../../reference/saml/saml2_technical_guide.html). ## SAML 2.0 Web SSO Profile Feide uses the [Web Browser SSO Profile defined by SAML 2.0](https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf). When implementing this profile, Service Providers MUST support the use of the following bindings: - The *HTTP Redirect* or the *HTTP POST* bindings for sending *Authentication Requests* to Feide. Note that the *HTTP Redirect* binding is RECOMMENDED. - The *HTTP POST* binding for receiving *Authentication Responses* from Feide. Additionally, Service Providers MUST support the following authentication flows: - The Service Provider MUST be able to send an *Authentication Request* to Feide when a user requests authentication, and consume the *Authentication Response* received upon successful authentication, commonly known as *SP-initiated authentication*. - The Service Provider MUST be able to consume an unsolicited *Authentication Response* received from Feide, commonly known as *IdP-initiated authentication*. ## SAML 2.0 Single Logout Profile Full support of the [Single Logout profile](https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf) is RECOMMENDED in Feide. Service Providers SHOULD be able to: - Send *Logout Requests* to Feide when a user initiates logout at the Service Provider. - Receive *Logout Requests* and proceed accordingly, by terminating the session of the current user and replying with a *Logout Response* to Feide. - Send and receive the aforementioned messages using the *HTTP Redirect* or *HTTP POST* bindings. Note that the *HTTP Redirect* binding is RECOMMENDED. ## Identification of users Service Providers MAY support the unambiguous and persistent identification of single users based on their [attributes](../schema/attributes/index.html.md). In particular, Service Providers MUST: - Avoid the use of *name identifiers* as an identifier of a user. Feide uses *transient* name identifiers that change every session and are therefore not suitable for persistent identification. ## Attribute format Service Providers MUST support the following attribute name format [SAMLCore](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf): - Basic, identified with the URI: `urn:oasis:names:tc:SAML:2.0:attrname-format:basic` ## Identification of Norwegian organizations Service Providers willing to perform authorization based on the home organization of the user SHOULD identify the organization by means of one of the following: - The [eduPersonOrgDN:norEduOrgNIN](../../reference/schema/noredu/noredu_ch03.html#noreduorgnin) attribute, or - The *realm* part of the [eduPersonPrincipalName](../../reference/schema/noredu/noredu_ch03.html#edupersonprincipalname) attribute. For those Service Providers that need a finer granularity to identify primary and secondary schools, the previous attributes can be used in addition to the following: - The *feideSchoolList*[4](https://www.feide.no/attribute/feideschoollist) attribute, which holds the list of schools associated with the user. Additionally, Service Providers identifying Norwegian organizations MUST: - Avoid using Feide’s *entity ID* to identify an organization, since Feide is a federation with one single SAML Identity Provider that provides service for all Norwegian institutions. ## Secure web transport To ensure the security and privacy of Feide users, and avoid security warnings displayed by web browsers when logging in to Feide, Service Providers MUST: - Support *HTTPS* on all the SAML URLs used to communicate with Feide. - Support security protocols (TLS) and mechanisms (certificates signed by well-known certification authorities) compatible with most modern web browsers. # Selecting the user organization If the service knows what organization the user is going to use on the login page, it is possible to prepopulate the organization choice on the login page. To do this, the user needs to be redirected via a special URL on the login page. This URL will save the organization choice in a cookie. ## Implementation To select the organization for the user, the user must be redirected via the following URL: `https://idp.feide.no/simplesaml/module.php/feide/preselectOrg.php` This URL requires two query parameters: * `HomeOrg`: Realm to the user’s organization. E.g. `uninett.no` for Uninett, `feide.osloskolen.no` for Oslo kommune, `skjaakskulane.no` for Skjåk kommune. * `ReturnTo`: URL the user should be returned to after the organization choice is stored. This is normally a URL at the service that triggers login. Remember to URL-escape this parameter. ## Realm See [Finding the organization domain name of a school](../../service_providers/finding_domain_name.html.md#finding-domain-name) for how to find the domain name (realm) of an organization. ## Example ```none https://idp.feide.no/simplesaml/module.php/feide/preselectOrg.php?HomeOrg=uninett.no&ReturnTo=https%3A//sp.example.org/login%3Fmethod%3Dfeide ``` This URL will select Uninett as the organization. Afterwards, the user will be sent to: `https://sp.example.org/login?method=feide` The latter URL should send a login request to Feide. ## Notes * The organization set with this method will override any organization choice made by the user. It is therefore important that the service is certain that the organization it selects is the correct organization. * Even when the organization selects the organization using this method, the user is still able to override it. The user can change the organization on the login page using the “Not your affiliation?”-link. The service must therefore be prepared for the possibility that the user will return from the login request with a user from another organization. # Tokens used in Feide This page describes the types of tokens used by Feide, their format and use. The key used to sign our JWT tokens may be obtained here: - [https://auth.dataporten.no/openid/jwks](https://auth.dataporten.no/openid/jwks) ## Feide access token An opaque ASCII string. Example: > `afd4988b-a205-49f9-b2e0-03e00bb4b8c0` Used to access APIs provided by Feide and third party data sources using the legacy API gatekeeper. ## Feide JWT access token An ASCII string. Example (shortened): > `eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI...` It is intended for use with third party data sources. It consists of a header, a payload and a signature, with a `.` between them. Each are base64url encoded. See [**RFC 7519 - JSON Web Token (JWT)**](https://datatracker.ietf.org/doc/html/rfc7519.html). The payload is a json object containing claims. Here is an example of what the payload may look like after decoding: ```json { "aud": "https://n.feide.no/datasources/02d0f79b-7fbc-422b-bb31-a4d22121f040", "iss": "https://auth.dataporten.no", "exp": 1610448035, "iat": 1610447735, "nbf": 1610447735, "client_id": "208335d4-e8c1-4910-8928-05b2e5b14127", "sub": "208335d4-e8c1-4910-8928-05b2e5b14127", "scope": "read append", "act": { "sub": "208335d4-e8c1-4910-8928-05b2e5b14127", "https://n.feide.no/claims/customer_portal_id": "https://n.feide.no/service_ids/1234" }, "name": "Bekymret Sky", "https://n.feide.no/claims/eduPersonPrincipalName": "bsk@uinn.no", "https://n.feide.no/claims/nin": "05840399895" } ``` If the token was issued in the context of an authenticated user, it may contain claims about the user. A claim is only included if the service that requested the token and the data source both are authorized to access the claim. The following claims are always included in the token: aud : Audience. The data source should only accept the token if it is the intended audience. iss : Issuer. Value is `https://auth.dataporten.no` if token was issued by Feide. iat : Time of issue. This and other time attributes are given in seconds since 1970-01-01T0:0:0 UTC. exp : Expiration time. nbf : Not valid before time. Protects against clock skew. client_id : ID of the application that requested the token. sub : Subject - the identity which the token authenticates. Can be a dataporten user ID or a client ID. In the future, a datasource UUID may also become possible. scope : The scopes that were granted. act : Actor. It represents a chain of delegation. E.g., an application could authorize a data source to access another on its behalf. We do not currently support delegation in JWT tokens, so the chain is only one level deep. It is a json object with the following attributes:
sub : Has the same value as `client_id` in the token.
https://n.feide.no/claims/customer_portal_id : The service or datasource that the token was issued for. For services, it is the string `https://n.feide.no/service_ids/` followed by the customer portal ID of the service that the token was issued for.
Datasources aren’t currently supported, but may be added in the future. If supported, they will be represented as the string `https://n.feide.no/datasource_ids/` followed by the customer portal ID of the datasource that the token was issued for. ### User claims in JWT access tokens The following user claims *may* be included: name : Name of user who the token authenticates. picture : Picture of user. sub : Described above https://n.feide.no/claims/userid_sec : Namespaced user ID of user. https://n.feide.no/claims/eduPersonPrincipalName : eduPersonPrincipalName of user. Only for users who authenticated to the Feide IDP. https://n.feide.no/claims/nin : Norwegian national identity number of user. ## ID token The ID token is a signed information object representing the authenticated identity of the user. It is specified in the OpenID Connect standard. The ID token is encoded as a JWT, and signed using the JWS standard. The information included - the `claims` - depends on the scopes / attribute groups enabled for the application. Claims are namespaced, so that claims which are specific to Feide are prefixed with `https://n.feide.no/claims/`. Claims without this prefix are specified in [the OIDC standard](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) or in [RFC 7519 - JSON Web Token (JWT)](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1). ID token example: ```default eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvYXV0aC5kZ XYuZmVpZGVjb25uZWN0Lm5vIiwiYXVkIjoiNWFjODc1M2YtODI5Ni00MWJmLWI5ODUtNTl kODk3NjkwMDVlIiwic3ViIjoiNzZhN2EwNjEtM2M1NS00MzBkLThlZTAtNmY4MmVjNDI1M DFmIiwiaWF0IjoxNDQ5MDY1NDMyLCJleHAiOjE0NDkwNjkwMzIsImF1dGhfdGltZSI6MTQ 0OTA2NTM2NH0.bObvZ\_Ampf\_exj4iUcocptJwHKt\_zZI4GnZ-VrXoqYlXaGGgwACzCz hSpck\_z1C87gZYlOdK-TQwILHcGyObmi1rH5VCvrYL1xNyGeHYlYs8bQ8odhZAPiYjb9c et5nP1aP4ZeJu5aInWwLIaeVUgavQEVAl1xGiPRh8WjKZdP-P1WslLACnVZu84YLrOZQYn kGMpDS\_VBGHVSK3VPVjRd14vhqYCoGTaKSXrp49LlejU0dzaokmGI\_ZAejwVY1BCFMon EyDNwZVZKoq2GbHwqpjhucWOZRQjYzeWTEXlly18EwYg55k6awNPZt8fKp0XoRoTB4we5W GoFV6XZuaGA ``` Here is a decoded example of a minimal ID token: ```json { "iss": "https://auth.dataporten.no", "aud": "5ac8753f-8296-41bf-b985-59d89769005e", "sub": "76a7a061-3c55-430d-8ee0-6f82ec42501f", "iat": 1449065432, "exp": 1449069032, "auth_time": 1449065364 } ``` The example above shows what the ID token includes when only the `openid` scope is enabled. All times are in seconds since 1970-01-01 00:00:00 UTC. iss : Issuer aud : Audience - the client ID sub : Subject - The internal ID of the authenticated user. This ID is stable but opaque, not releasing any additional information about the user. iat : Issued at - Time issued (in seconds since 1970-01-01T0:0:0 UTC) exp : Expiration time (in seconds since 1970-01-01T0:0:0 UTC) auth_time : Time when the end-user authentication occurred The attributes `acr`, `at_hash`, `c_hash` and `nonce` may also be present. See [the OIDC standard](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) for info about these. Here is an example of a decoded ID token which includes all supported claims: ```json { "iss": "https://auth.dataporten.no", "jti": "f95ed523-b9b2-42e7-b193-a08143d9f342", "aud": "5ac8753f-8296-41bf-b985-59d89769005e", "sub": "76a7a061-3c55-430d-8ee0-6f82ec42501f", "iat": 1635509702, "exp": 1635513302, "auth_time": 1635505713, "nonce": "PLt3i3bT2~xTw7m", "email": "jon.kare.hellan@uninett.no", "name": "Jon Kåre Hellan", "picture": "https://api.dataporten.no/userinfo/v1/user/media/p:c0050004-386e-4c58-9073-e37344bc8769", "https://n.feide.no/claims/userid_sec": [ "feide:jk@uninett.no" ], "https://n.feide.no/claims/eduPersonPrincipalName": "jk@uninett.no", "at_hash": "DiafctHGah2reptMDjEqUg", "acr": "urn:mace:feide.no:auth:level:fad08:3" } ``` Note that the `acr` claim is only included if: - The user authenticated with a Feide account - The service [requested](../service_providers/mfa/openid_connect.html.md) multi factor authentication - The user met the requirements for the requested level of authentication ### User claims in ID tokens email : The user’s email. Requires the `email` attribute group name : The user’s name. Requires the `userinfo-name` attribute group picture : A picture of the user. Requires the `userinfo-photo` attribute group https://n.feide.no/claims/userid_sec : An array containing at most one namespaced user ID on the format `:`.
If the application has the `userid-feide` attribute group, and the user logged in with Feide, it will contain `feide:` followed by the `eduPersonPrincipalName` of the user. Example: `feide:jk@uninett.no`.
If the application has the `userid-nin` attribute group, and the user logged in with ID-porten, it will contain `nin:` followed by the national identity number of the user. Example: `nin:10108012345`
If the application has the `userid-edugain` attribute group, and the user is logged in with eduGAIN, it will contain `edugain:` followed by the the entity ID of the authenticating eduGAIN IdP. That is then followed by the user ID from eduGAIN. Note that since `:` is used as a separator, the characters `:` and `%` will be URL-encoded. Example: `edugain:https%2A//some.edugain.idp/entityId:user@some-edugain.org`. https://n.feide.no/claims/eduPersonPrincipalName : The user’s `eduPersonPrincipalName`. Requires the `userid-feide` attribute group. Only available if the user logged in with Feide. https://n.feide.no/claims/nin : The user’s national identity number. Requires the `userid-nin` attribute group. # Feide test users Feide has a number of test users that can be used to test services. They all exist in the `testusers.feide.no` realm, and to use them your service must be explicicty configured to allow test users. All test users have the same password: `098asd`. ## Organizations and units These are all organizations and units that the test users belong to. #### Lower education organizations | School | Org number | School owner | Org number | |---------------------------|---------------|-------------------------------|---------------| | Alna grunnskole | `NO876326125` | Test kommune | `NO713293725` | | Bjerke grunnskole | `NO876326126` | Test kommune | `NO713293725` | | Frogner VGS | `NO895395126` | Test kommune | `NO713293725` | | GLOVARM IVRIG PIGGSVIN | `NO310550795` | URIMELIG STABIL BJØRN KOMMUNE | `NO313475964` | | Grøn barneskole | `NO856326499` | Osp kommune | `NO856326502` | | Grorud VGS | `NO895395127` | Test kommune | `NO713293725` | | Hassel barneskole | `NO956326500` | Osp kommune | `NO856326502` | | Heimdal grunnskole | `NO738893611` | Innvikdal kommune | `NO738893611` | | Lerk VGS | `NO856326501` | Rogn fylkeskommune | `NO956326503` | | Lind VGS | `NO956326504` | Rogn fylkeskommune | `NO956326503` | | OMSORGSFULL NETT PIGGSVIN | `NO310360570` | URIMELIG STABIL BJØRN KOMMUNE | `NO313475964` | | RESERVERT SLITEN PIGGSVIN | `NO313839850` | URIMELIG STABIL BJØRN KOMMUNE | `NO313475964` | | SMAL FYSISK PIGGSVIN | `NO212558702` | URIMELIG STABIL BJØRN KOMMUNE | `NO313475964` | | ULLEN EFFEKTIV PIGGSVIN | `NO214215942` | URIMELIG STABIL BJØRN KOMMUNE | `NO313475964` | | UTÅLMODIG TREG PIGGSVIN | `NO213656732` | URIMELIG STABIL BJØRN KOMMUNE | `NO313475964` | #### Higher education organizations | Organization | Org number | |----------------------------|---------------| | Universitetet i Midt-Norge | `NO829033123` | | Universitetet i Rogn | `NO856326505` | | Universitetet i Ut-Norge | `NO829033124` | ## Generic test users These users are the traditional Feide test users, and can be used by any service that authenticates an end user. #### Simple lower education users | Username | Name | School | Type | |--------------------|-------------------------|------------------------------------|---------| | `alexander123elev` | Alexander Hansen | Bjerke grunnskole | Student | | `alf123teacher` | Alf Alfsen | Heimdal grunnskole | Teacher | | `andreas123elev` | Andreas Foss | Alna grunnskole | Student | | `anne_laerervgs` | Anne LærerVGS Haugen | Lerk VGS | Teacher | | `anne123teacher` | Anne Istad | Alna grunnskole, Bjerke grunnskole | Teacher | | `bjorn123staff` | Bjørn Monsen | Alna grunnskole, Bjerke grunnskole | Staff | | `daniel_laerervgs` | Daniel LærerVGS Knutsen | Lind VGS | Teacher | | `emma123elev` | Emma Bjørnsen | Alna grunnskole | Student | | `ida456elev` | Ida Glad | Grorud VGS | Student | | `inger456teacher` | Inger Karlsen | Frogner VGS, Grorud VGS | Teacher | | `irene123elev` | Irene Vik | Alna grunnskole | Student | | `jan123teacher` | Jan Jansen | Bjerke grunnskole,Alna grunnskole | Teacher | | `jan_elevvgs` | Jan ElevVGS Olsen | Lerk VGS, Lind VGS | Student | | `jonas456elev` | Jonas Hansen | Grorud VGS | Student | | `julie123elev` | Julie Eriksen | Alna grunnskole | Student | | `kari456staff` | Kari Nilsen | Frogner VGS, Grorud VGS | Staff | | `kristian456elev` | Kristian Frank | Frogner VGS | Student | | `markus123elev` | Markus Andersen | Alna grunnskole | Student | | `matias123elev` | Matias Duck | Bjerke grunnskole | Student | | `nora123elev` | Nora Gundersen | Bjerke grunnskole | Student | | `per456teacher` | Per Land | Grorud VGS, Frogner VGS | Teacher | | `roger123teacher` | Roger Mikkelsen | Alna grunnskole | Teacher | | `sara123elev` | Sara Christiansen | Bjerke grunnskole | Student | | `thea456elev` | Thea Eide | Frogner VGS | Student | | `ulrik123elev` | Ulrik Mulvik | Heimdal grunnskole | Student | #### Simple higher education users | Username | Name | Type | |------------------------------------------|--------------------------|-----------------| | `eva_student` | Eva Student Åsen | Student | | `eva_student_2f` [1](#f1) | Eva Student Åsen | Student | | `frank_foreleser` | Frank Foreleser Føllesen | Teacher | | `frank_foreleser_2f` [1](#f1) | Frank Foreleser Føllesen | Teacher | | `finn_admin` | Finn Admin Andersen | Staff | | `ingeborg789staff` | Ingeborg Gundersen | Staff | | `jakob_student` | Jakob Student Åsen | Student | | `jakob_student_2f` [1](#f1) | Jakob Student Åsen | Student | | `kari_student` | Kari Student Edvardsen | Student | | `kari_student_2f` [1](#f1) | Kari Student Edvardsen | Student | | `kjell789faculty` | Kjell Andersen | Teacher | | `kristine789student` | Kristine Rask | Student | | `lars789staff` | Lars Johansen | Staff | | `mia789dual` | Mia Sander | Teacher/Student | | `perra789student` | Per Andreas Persen | Student | | `silje789student` | Silje Olsen | Student | | `stian789student` | Stian Stil | Student | | `svein789aff` | Svein Dahl | Affiliate | | `thomas789student` | Thomas Persen | Student | #### Lower education users with class/course information | Username | Name | School | Class/Course | Type | |----------------------------------------------|------------------------|-------------------|-------------------------------------------------------------------------|-------------| | `alf_elevg` | Alf ElevG Christiansen | Grøn barneskole | 10A, 10A-LAB1, XENS-10A, XMAS-10A, XNA-10A, XSA-10A, XSA-10TEST | Student | | `anders_elevvgs` [2](#f2) | Anders ElevVGS Iversen | Lerk VGS | 1STA, 1STA-LAB1, 1GEO-1STA, 1MAT11-1MAP1, 1NATS-1STA, 1STB_EXP, 1STC_1Y | Student | | | | Lind VGS | | Student | | `anita_elevg` | Anita Berge | Grøn barneskole | 10A, XSA-9A, XNA-10A | Student | | `ann_elevg` | Ann ElevG Berntsen | Grøn barneskole | 10A, 10A-LAB1, XENS-10A, XMAS-10A, XNA-10A, XSA-10A | Student | | `asjborn_elevg` | Asbjørn ElevG Hansen | Grøn barneskole | 10A, 10A-LAB1, XENS-10A, XMAS-10A, XNA-10A, XSA-10A | Student | | `berit_adming` | Berit AdminG Birkeland | Hassel barneskole | | Osp kommune | | `bernt_laererg` | Bernt LærerG Halvorsen | Grøn barneskole | 10A, 10A-LAB1, XNA-10A | Teacher | | `bjorg_laererg` | Bjørg LærerG Olsen | Hassel barneskole | 8A, 8A-LAB1, 8A-LAB2, 8A-LAB3, 8MAS-8A, 8NA-8A | Teacher | | `cecilie_elevvgs` [2](#f2) | Cecilie ElevVGS Ås | Lerk VGS | 1STA, 1STA-LAB1, 1GEO-1STA, 1MAT11-1MAP1, 1STB_EXP, 1STC_1Y | Student | | | | Lind VGS | | Student | | `david_laerervgs` [2](#f2) | David LærerVGS Jonsen | Lerk VGS | 1STA, 1STA-LAB1, 1STA-LAB2, 1MAT11-1MAP1, 1MAT13-1MAT1 | Teacher | | | | Lind VGS | | Teacher | | `grp03-lise123elev` | Lise Andersen | Alna grunnskole | 3A, 3A-MAT, 3A-NOR | Student | | `grp03a-anne123teacher` [2](#f2) | Anne Istad | Alna grunnskole | 3A, 3A-NOR, 3B-NOR | Teacher | | | | Bjerke grunnskole | 3A-NOR, 3B-NOR | Teacher | | `grp03a-liv123teacher` [2](#f2) | Liv Berg | Alna grunnskole | 3B, 3A-MAT, 3B-MAT | Teacher | | | | Bjerke grunnskole | 3A-MAT, 3B-MAT | Teacher | | `grp03a-markus123elev` | Markus Andersen | Alna grunnskole | 3A, 3A-MAT, 3A-NOR | Student | | `grp03a-irene123elev` | Irene Vik | Alna grunnskole | 3A, 3A-MAT, 3A-NOR | Student | | `grp04a-anne123teacher` [2](#f2) | Anne Istad | Alna grunnskole | 4A, 4A-NOR, 4B-NOR | Teacher | | | | Bjerke grunnskole | 4A-NOR, 4B-NOR | Teacher | | `grp04a-markus123elev` | Markus Andersen | Alna grunnskole | 4A, 4A-MAT, 4A-NOR | Student | | `grp11a-inger456teacher` [2](#f2) | Inger Karlsen | Frogner VGS | 1SFA, 1PA-MAT1011, 1PB-MAT1011, 1TA-MAT1013, 1TB-MAT1013 | Teacher | | | | Grorud VGS | 1TA-MAT1013 | Teacher | | `grp11a-thea456elev` | Thea Eide | Frogner VGS | 1SFA, 1SFA-ENG1002, 1TA-MAT1013, 1SFA-NOR1201 | Student | | `maja_laererg` | Maja LærerG Hansen | Hassel barneskole | 9A, 9MAS-9A, 9NA-9A | Teacher | ## Test users that work with provisioning APIs These users (and their organizations) map to fictional entities used in the national service [Tenor testdata](https://www.skatteetaten.no/skjema/testdata/). This makes them useful for testing services that also involve ID-porten. They can also be used to test provisioning APIs. All these users belong to the organization “URIMELIG STABIL BJØRN KOMMUNE” and their structure is meant to correspond to the structure used by schools and school owners in lower education. #### Generic users | Username | Name | School | Class/Course | Type | |-----------------------------------------------|-----------------------------|---------------------------|------------------------------------------------|---------| | `no310550795_elev_1_10a` | SPED AGENT | GLOVARM IVRIG PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no310550795_elev_1_10b` | FILOSOFISK LISTE | GLOVARM IVRIG PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no310550795_elev_1_5a` | ANSTENDIG LEGE | GLOVARM IVRIG PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no310550795_elev_1_5b` | ROBUST SKATOLL | GLOVARM IVRIG PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no310550795_elev_1_6a` | NONFIGURATIV TJA | GLOVARM IVRIG PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no310550795_elev_1_6b` | OVEREKSPONERT STOKK | GLOVARM IVRIG PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no310550795_elev_1_7a` | DISTINGVERT DRAGE | GLOVARM IVRIG PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no310550795_elev_1_7b` | FYLDIG REVEBJELLE | GLOVARM IVRIG PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no310550795_elev_1_8a` | KOMFORTABEL HUNKATT | GLOVARM IVRIG PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no310550795_elev_1_8b` | LYS KAMERA | GLOVARM IVRIG PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no310550795_elev_1_9a` | NØYTRAL BUSSTOPP | GLOVARM IVRIG PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no310550795_elev_1_9b` | KRANGLETE VEVSTOL | GLOVARM IVRIG PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no310550795_elev_2_10a` | FORMBAR JUICE | GLOVARM IVRIG PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no310550795_elev_2_10b` | KONKRET FOBI | GLOVARM IVRIG PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no310550795_elev_2_5a` | UROMANTISK PLASMA | GLOVARM IVRIG PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no310550795_elev_2_5b` | SKAPENDE HUND | GLOVARM IVRIG PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no310550795_elev_2_6a` | ØVRIGE EDELSTEIN | GLOVARM IVRIG PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no310550795_elev_2_6b` | SMART GLOSE | GLOVARM IVRIG PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no310550795_elev_2_7a` | KLOK NETTHINNE | GLOVARM IVRIG PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no310550795_elev_2_7b` | TRIST MUFFINS | GLOVARM IVRIG PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no310550795_elev_2_8a` | MISFORNØYD AMBASSADE | GLOVARM IVRIG PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no310550795_elev_2_8b` | LANG BUKT | GLOVARM IVRIG PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no310550795_elev_2_9a` | OPPRETT KONE | GLOVARM IVRIG PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no310550795_elev_2_9b` | GILD GALLERI | GLOVARM IVRIG PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no310550795_elev_3_10a` | KRY OMELETT | GLOVARM IVRIG PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no310550795_elev_3_10b` | KONSENTRISK ØY | GLOVARM IVRIG PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no310550795_elev_3_5a` | RAFFINERT FØLL | GLOVARM IVRIG PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no310550795_elev_3_5b` | TRIST RYGG | GLOVARM IVRIG PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no310550795_elev_3_6a` | UEMOSJONELL BETALING | GLOVARM IVRIG PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no310550795_elev_3_6b` | OPPJAGET BAS | GLOVARM IVRIG PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no310550795_elev_3_7a` | STRAFFET TRAPP | GLOVARM IVRIG PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no310550795_elev_3_7b` | RAVGUL KATEDRAL | GLOVARM IVRIG PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no310550795_elev_3_8a` | VERTIKAL BRANNGATE | GLOVARM IVRIG PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no310550795_elev_3_8b` | KUNST KLISJÉ | GLOVARM IVRIG PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no310550795_elev_3_9a` | STA JUKEBOKS | GLOVARM IVRIG PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no310550795_elev_3_9b` | FIOLETT BOKHYLLE | GLOVARM IVRIG PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no310550795_elev_4_10a` | ØKOLOGISK BADERING | GLOVARM IVRIG PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no310550795_elev_4_10b` | FIKTIV MOTVIND | GLOVARM IVRIG PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no310550795_elev_4_5a` | INNESLUTTET TURISTBY | GLOVARM IVRIG PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no310550795_elev_4_5b` | UVITENDE BJØRNUNGE | GLOVARM IVRIG PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no310550795_elev_4_6a` | OBSERVANT VEVSTOL | GLOVARM IVRIG PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no310550795_elev_4_6b` | KOMFORTABEL HUNKATT | GLOVARM IVRIG PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no310550795_elev_4_7a` | MUNTER JORDBÆR | GLOVARM IVRIG PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no310550795_elev_4_7b` | MOTVILLIG BRØKDEL | GLOVARM IVRIG PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no310550795_elev_4_8a` | UNYTTIG FISKEBOLLE | GLOVARM IVRIG PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no310550795_elev_4_8b` | VIS SERVISE | GLOVARM IVRIG PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no310550795_elev_4_9a` | TOÅRIG PÅKJENNING | GLOVARM IVRIG PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no310550795_elev_4_9b` | RØD NATTERGAL | GLOVARM IVRIG PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no310550795_elev_5_10a` | UKONTROVERSIELL ORIDÉ | GLOVARM IVRIG PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no310550795_elev_5_10b` | AKUSTISK ELG | GLOVARM IVRIG PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no310550795_elev_5_5a` | NERVØS ROSIN | GLOVARM IVRIG PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no310550795_elev_5_5b` | AKADEMISK GALLIUM | GLOVARM IVRIG PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no310550795_elev_5_6a` | LATTERMILD ALTMULIGMANN | GLOVARM IVRIG PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no310550795_elev_5_6b` | PLUTSELIG MANDAG | GLOVARM IVRIG PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no310550795_elev_5_7a` | GRETTEN PEDAL | GLOVARM IVRIG PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no310550795_elev_5_7b` | SOLID SVERM | GLOVARM IVRIG PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no310550795_elev_5_8a` | UNØYAKTIG GALLIUM | GLOVARM IVRIG PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no310550795_elev_5_8b` | ROLIG FASTLANDSFORBINDELSE | GLOVARM IVRIG PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no310550795_elev_5_9a` | FUNKSJONELL MENY | GLOVARM IVRIG PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no310550795_elev_5_9b` | ALFABETISK GLOBUS | GLOVARM IVRIG PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no310550795_laerer_10a` | AKTUELL KJEPPHEST | GLOVARM IVRIG PIGGSVIN | 10A, 10A-NOR | Teacher | | `no310550795_laerer_10b` [2](#f2) | TALEFØR ELV | GLOVARM IVRIG PIGGSVIN | 10B, 10B-NOR | Teacher | | | | UTÅLMODIG TREG PIGGSVIN | 3SF1, 3SF1-NOR1211, 3SF1-REA3028 | Student | | `no310550795_laerer_5a` | IDIOTSIKKER MATTE | GLOVARM IVRIG PIGGSVIN | 5A, 5A-MAT, 5B-MAT | Teacher | | `no310550795_laerer_5b` | EKSPLOSIV HEI | GLOVARM IVRIG PIGGSVIN | 5B, 5A-NOR, 5B-NOR | Teacher | | `no310550795_laerer_6a` | RU BRØDSKIVE | GLOVARM IVRIG PIGGSVIN | 6A, 6A-NOR, 6B-NOR | Teacher | | `no310550795_laerer_6b` | SLITEN MUNN | GLOVARM IVRIG PIGGSVIN | 6B, 6A-MAT, 6B-MAT, 7A-MAT, 7B-MAT | Teacher | | `no310550795_laerer_7a` | REFLEKSIV SOMMERFERIE | GLOVARM IVRIG PIGGSVIN | 7A, 7A-NOR | Teacher | | `no310550795_laerer_7b` | UKLAR ARTIKKEL | GLOVARM IVRIG PIGGSVIN | 7B, 7B-NOR | Teacher | | `no310550795_laerer_8a` | AKTIV BACON | GLOVARM IVRIG PIGGSVIN | 8A, 8A-NOR, 8B-NOR | Teacher | | `no310550795_laerer_8b` | VOKAL ADRESSAT | GLOVARM IVRIG PIGGSVIN | 8B, 8B-MAT, 9B-MAT, 10B-MAT | Teacher | | `no310550795_laerer_2_8b` | FANTASIFULL LINJAL | GLOVARM IVRIG PIGGSVIN | 8B, 8B-NOR | Teacher | | `no310550795_laerer_9a` | JUSTERBAR PRØVE | GLOVARM IVRIG PIGGSVIN | 9A, 8A-MAT, 9A-MAT, 10A-MAT | Teacher | | `no310550795_laerer_9b` | OVERBEVISENDE ABBOR | GLOVARM IVRIG PIGGSVIN | 9B, 9A-NOR, 9B-NOR | Teacher | | `no313839850_elev_1_10a` | FIN SÅPE | RESERVERT SLITEN PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no313839850_elev_1_10b` | TRU KJETTING | RESERVERT SLITEN PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no313839850_elev_1_5a` | FAMØS TUNGE | RESERVERT SLITEN PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no313839850_elev_1_5b` | FAMILIÆR BANE | RESERVERT SLITEN PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no313839850_elev_1_6a` | KVADRATISK OPPLAG | RESERVERT SLITEN PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no313839850_elev_1_6b` | TØRST HALVKULE | RESERVERT SLITEN PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no313839850_elev_1_7a` | NORMAL KONJUNKSJON | RESERVERT SLITEN PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no313839850_elev_1_7b` | KRANGLETE ARTISJOKK | RESERVERT SLITEN PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no313839850_elev_1_8a` | MISFORNØYD SKRIVEMASKIN | RESERVERT SLITEN PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no313839850_elev_1_8b` | EKSEMPLARISK BEVEGELSE | RESERVERT SLITEN PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no313839850_elev_1_9a` | OPPKLARENDE FOBI | RESERVERT SLITEN PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no313839850_elev_1_9b` | VELKOMMEN DESIMAL | RESERVERT SLITEN PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no313839850_elev_2_10a` | TOPP SAVANNE | RESERVERT SLITEN PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no313839850_elev_2_10b` | BETYDELIG OPSJON | RESERVERT SLITEN PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no313839850_elev_2_5a` | OPPRETT FJELLKJEDE | RESERVERT SLITEN PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no313839850_elev_2_5b` | FYSISK DELMENGDE | RESERVERT SLITEN PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no313839850_elev_2_6a` | ÅPEN GRENSE | RESERVERT SLITEN PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no313839850_elev_2_6b` | USIKKER KJEDE | RESERVERT SLITEN PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no313839850_elev_2_7a` | EPISK RÅVARE | RESERVERT SLITEN PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no313839850_elev_2_7b` | GØYAL GLEDE | RESERVERT SLITEN PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no313839850_elev_2_8a` | RETTFERDIG MYRSNIPE | RESERVERT SLITEN PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no313839850_elev_2_8b` | MASSE AMBISJON | RESERVERT SLITEN PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no313839850_elev_2_9a` | HENSIKTSMESSIG INFORMASJON | RESERVERT SLITEN PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no313839850_elev_2_9b` | TYDELIG KALKULATOR | RESERVERT SLITEN PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no313839850_elev_3_10a` | MOMENTAN HALVSØSKEN | RESERVERT SLITEN PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no313839850_elev_3_10b` | OPPFARENDE GALTE | RESERVERT SLITEN PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no313839850_elev_3_5a` | STOLT BAGASJETRALLE | RESERVERT SLITEN PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no313839850_elev_3_5b` | FERSK OVERGANG | RESERVERT SLITEN PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no313839850_elev_3_6a` | TILLITSFULL ORIENTERING | RESERVERT SLITEN PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no313839850_elev_3_6b` | LYSEGUL LØVINNE | RESERVERT SLITEN PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no313839850_elev_3_7a` | KANTETE LERKEFUGL | RESERVERT SLITEN PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no313839850_elev_3_7b` | TØRR HERBARIUM | RESERVERT SLITEN PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no313839850_elev_3_8a` | TROVERDIG MOSKUS | RESERVERT SLITEN PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no313839850_elev_3_8b` | RØD JULEFERIE | RESERVERT SLITEN PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no313839850_elev_3_9a` | GRÅDIG ELV | RESERVERT SLITEN PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no313839850_elev_3_9b` | SPED SØYLE | RESERVERT SLITEN PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no313839850_elev_4_10a` | LIDENSKAPELIG ORM | RESERVERT SLITEN PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no313839850_elev_4_10b` | NETT PARTIKKEL | RESERVERT SLITEN PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no313839850_elev_4_5a` | NORMAL HYPOTESE | RESERVERT SLITEN PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no313839850_elev_4_5b` | VRIEN LERKEFUGL | RESERVERT SLITEN PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no313839850_elev_4_6a` | PARODISK MUTTER | RESERVERT SLITEN PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no313839850_elev_4_6b` | PESSIMISTISK FJES | RESERVERT SLITEN PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no313839850_elev_4_7a` | REALISTISK PIONER | RESERVERT SLITEN PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no313839850_elev_4_7b` | FALSK KUSINE | RESERVERT SLITEN PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no313839850_elev_4_8a` | ALTERNATIV FAGOTT | RESERVERT SLITEN PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no313839850_elev_4_8b` | ØDE KYST | RESERVERT SLITEN PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no313839850_elev_4_9a` | ORDKNAPP ETASJE | RESERVERT SLITEN PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no313839850_elev_4_9b` | LEKKER TRADISJON | RESERVERT SLITEN PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no313839850_elev_5_10a` | RAFFINERT MOTVIND | RESERVERT SLITEN PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no313839850_elev_5_10b` | AKTUELL BUSK | RESERVERT SLITEN PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no313839850_elev_5_5a` | RAVGUL VARE | RESERVERT SLITEN PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no313839850_elev_5_5b` | IMPULSIV KRABBE | RESERVERT SLITEN PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no313839850_elev_5_6a` | USIKKER SJESELONG | RESERVERT SLITEN PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no313839850_elev_5_6b` | HARDHUDET DØR | RESERVERT SLITEN PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no313839850_elev_5_7a` | SMART EGGEPLOMME | RESERVERT SLITEN PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no313839850_elev_5_7b` | TYDELIG BENK | RESERVERT SLITEN PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no313839850_elev_5_8a` | UPOPULÆR ARTERIE | RESERVERT SLITEN PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no313839850_elev_5_8b` | HEMMELIGHETSFULL FLAGGERMUS | RESERVERT SLITEN PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no313839850_elev_5_9a` | SPRUDLENDE FOTBALL | RESERVERT SLITEN PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no313839850_elev_5_9b` | ORIENTAL PLANET | RESERVERT SLITEN PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no313839850_elev_d_8b` [4](#f4) | EGOISTISK FAKTURA | RESERVERT SLITEN PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no313839850_elev_d_9a` [4](#f4) | SUBTIL SKÅL | RESERVERT SLITEN PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no313839850_laerer_10a` | UFORNUFTIG GRAF | RESERVERT SLITEN PIGGSVIN | 10A, 9A-NOR, 10A-NOR, 10B-NOR | Teacher | | `no313839850_laerer_10b` | NORMAL DIVA | RESERVERT SLITEN PIGGSVIN | 10B, 10B-MAT | Teacher | | `no313839850_laerer_5a` | FORSIKTIG KONTRADIKSJON | RESERVERT SLITEN PIGGSVIN | 5A, 5A-NOR, 5B-NOR | Teacher | | `no313839850_laerer_5b` | SUNN DESIMAL | RESERVERT SLITEN PIGGSVIN | 5B, 5A-MAT, 5B-MAT, 6A-MAT | Teacher | | `no313839850_laerer_6a` | OPPLYST FRITID | RESERVERT SLITEN PIGGSVIN | 6A, 6A-MAT | Teacher | | `no313839850_laerer_6b` | NYTTIG REGLE | RESERVERT SLITEN PIGGSVIN | 6B, 6A-NOR, 6B-NOR | Teacher | | `no313839850_laerer_7a` | ARITMETISK ALMISSE | RESERVERT SLITEN PIGGSVIN | 7A, 7A-NOR, 7B-NOR | Teacher | | `no313839850_laerer_7b` | SMIDIG KALORI | RESERVERT SLITEN PIGGSVIN | 7B, 6B-MAT, 7A-MAT, 7B-MAT | Teacher | | `no313839850_laerer_2_7b` | KUNSTIG ANATOMI | RESERVERT SLITEN PIGGSVIN | 7B, 7B-NOR | Teacher | | `no313839850_laerer_8a` | PRESIS RYNKE | RESERVERT SLITEN PIGGSVIN | 8A, 8A-NOR, 8B-NOR | Teacher | | `no313839850_laerer_8b` | FANTASTISK FANTAST | RESERVERT SLITEN PIGGSVIN | 8B, 8A-MAT, 8B-MAT | Teacher | | `no313839850_laerer_9a` | DEDIKERT GLADIATOR | RESERVERT SLITEN PIGGSVIN | 9A, 9A-MAT, 9B-MAT, 10A-MAT | Teacher | | `no313839850_laerer_9b` | SJOKKERT ANDAKT | RESERVERT SLITEN PIGGSVIN | 9B, 9B-NOR | Teacher | | `no310360570_elev_1_10a` | ARTIG POESI | OMSORGSFULL NETT PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no310360570_elev_1_10b` | VIS BABYBAG | OMSORGSFULL NETT PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no310360570_elev_1_5a` | UTHOLDEN VOLLEYBALL | OMSORGSFULL NETT PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no310360570_elev_1_5b` | UPRAKTISK GRAPEFRUKT | OMSORGSFULL NETT PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no310360570_elev_1_6a` | LOJAL STOKK | OMSORGSFULL NETT PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no310360570_elev_1_6b` | SKJØNN BANKE | OMSORGSFULL NETT PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no310360570_elev_1_7a` | KONSENTRISK KONSERT | OMSORGSFULL NETT PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no310360570_elev_1_7b` | MINKENDE SVIGERSØNN | OMSORGSFULL NETT PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no310360570_elev_1_8a` | LYDIG BALANSE | OMSORGSFULL NETT PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no310360570_elev_1_8b` | ETTERPÅKLOK PUMPE | OMSORGSFULL NETT PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no310360570_elev_1_9a` | FORNØYD BIT | OMSORGSFULL NETT PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no310360570_elev_1_9b` | HELLIG ELV | OMSORGSFULL NETT PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no310360570_elev_2_10a` | SUNN GJERRIGKNARK | OMSORGSFULL NETT PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no310360570_elev_2_10b` | VENSTRE JORDSMONN | OMSORGSFULL NETT PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no310360570_elev_2_5a` | FRYKTSOM MASKIN | OMSORGSFULL NETT PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no310360570_elev_2_5b` | KLASSISK KANT | OMSORGSFULL NETT PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no310360570_elev_2_6a` | INTRIKAT FLASKEHALS | OMSORGSFULL NETT PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no310360570_elev_2_6b` | DYR SEREMONI | OMSORGSFULL NETT PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no310360570_elev_2_7a` | GILD SUPPORTER | OMSORGSFULL NETT PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no310360570_elev_2_7b` | TILFELDIG JOURNAL | OMSORGSFULL NETT PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no310360570_elev_2_8a` | KOMPLISERT HARE | OMSORGSFULL NETT PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no310360570_elev_2_8b` | PUSLETE OPPVASKMASKIN | OMSORGSFULL NETT PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no310360570_elev_2_9a` | KONTROLLERT ADMIRAL | OMSORGSFULL NETT PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no310360570_elev_2_9b` | STØYFRI HIMMEL | OMSORGSFULL NETT PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no310360570_elev_3_10a` | UKLAR MØBELFORRETNING | OMSORGSFULL NETT PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no310360570_elev_3_10b` | KOMFORTABEL TELEFONNUMMER | OMSORGSFULL NETT PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no310360570_elev_3_5a` | BESKJEDEN LEGG | OMSORGSFULL NETT PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no310360570_elev_3_5b` | LEKKER PAPEGØYE | OMSORGSFULL NETT PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no310360570_elev_3_6a` | UVANLIG MYNT | OMSORGSFULL NETT PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no310360570_elev_3_6b` | LEDENDE GLOBUS | OMSORGSFULL NETT PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no310360570_elev_3_7a` | STOR HJELP | OMSORGSFULL NETT PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no310360570_elev_3_7b` | ANALYSERENDE TELEFONKATALOG | OMSORGSFULL NETT PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no310360570_elev_3_8a` | KJÆRLIG ÆRESDOKTOR | OMSORGSFULL NETT PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no310360570_elev_3_8b` | INNSIKTSFULL KVELD | OMSORGSFULL NETT PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no310360570_elev_3_9a` | LYSTIG BOLERO | OMSORGSFULL NETT PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no310360570_elev_3_9b` | RYDDIG BAD | OMSORGSFULL NETT PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no310360570_elev_4_10a` | PRIKKETE VANDREFALK | OMSORGSFULL NETT PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no310360570_elev_4_10b` | RESERVERT BJELKE | OMSORGSFULL NETT PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no310360570_elev_4_5a` | ANALYSERENDE KARTLEGGING | OMSORGSFULL NETT PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no310360570_elev_4_5b` | ULLEN SOFA | OMSORGSFULL NETT PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no310360570_elev_4_6a` | AVANSERT TRAKTOREGG | OMSORGSFULL NETT PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no310360570_elev_4_6b` | FIN KONE | OMSORGSFULL NETT PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no310360570_elev_4_7a` | SLAPP FUGLEKASSE | OMSORGSFULL NETT PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no310360570_elev_4_7b` | VERD FILOSOF | OMSORGSFULL NETT PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no310360570_elev_4_8a` | MOTLØS BOBLE | OMSORGSFULL NETT PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no310360570_elev_4_8b` | SMUL BØRSTE | OMSORGSFULL NETT PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no310360570_elev_4_9a` | AUTONOM KONTAKT | OMSORGSFULL NETT PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no310360570_elev_4_9b` | STORARTET BRUD | OMSORGSFULL NETT PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no310360570_elev_5_10a` | ALMINNELIG PÅSKEEGG | OMSORGSFULL NETT PIGGSVIN | 10A, 10A-MAT, 10A-NOR | Student | | `no310360570_elev_5_10b` | PUNKTLIG LABYRINT | OMSORGSFULL NETT PIGGSVIN | 10B, 10B-MAT, 10B-NOR | Student | | `no310360570_elev_5_5a` | ORDKNAPP GRAF | OMSORGSFULL NETT PIGGSVIN | 5A, 5A-MAT, 5A-NOR | Student | | `no310360570_elev_5_5b` | HENSIKTSMESSIG BLYANT | OMSORGSFULL NETT PIGGSVIN | 5B, 5B-MAT, 5B-NOR | Student | | `no310360570_elev_5_6a` | TALEFØR BEFAL | OMSORGSFULL NETT PIGGSVIN | 6A, 6A-MAT, 6A-NOR | Student | | `no310360570_elev_5_6b` | SAKTE TOMT | OMSORGSFULL NETT PIGGSVIN | 6B, 6B-MAT, 6B-NOR | Student | | `no310360570_elev_5_7a` | HUMORISTISK TRAKT | OMSORGSFULL NETT PIGGSVIN | 7A, 7A-MAT, 7A-NOR | Student | | `no310360570_elev_5_7b` | FRUKTBAR DRIKKE | OMSORGSFULL NETT PIGGSVIN | 7B, 7B-MAT, 7B-NOR | Student | | `no310360570_elev_5_8a` | FORNEM BOKKLUBB | OMSORGSFULL NETT PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no310360570_elev_5_8b` | KUL GITAR | OMSORGSFULL NETT PIGGSVIN | 8B, 8B-MAT, 8B-NOR | Student | | `no310360570_elev_5_9a` | INKLUDERENDE KUTTE | OMSORGSFULL NETT PIGGSVIN | 9A, 9A-MAT, 9A-NOR | Student | | `no310360570_elev_5_9b` | BLØT FJORDING | OMSORGSFULL NETT PIGGSVIN | 9B, 9B-MAT, 9B-NOR | Student | | `no310360570_elev_x_8a` [3](#f3) | KNUSLETE HANDEL | OMSORGSFULL NETT PIGGSVIN | 8A, 8A-MAT, 8A-NOR | Student | | `no310360570_laerer_10a` | UGLESETT BRØKSTREK | OMSORGSFULL NETT PIGGSVIN | 10A, 10A-MAT, 10B-MAT | Teacher | | `no310360570_laerer_10b` | SØVNING RETORIKK | OMSORGSFULL NETT PIGGSVIN | 10B, 10A-NOR, 10B-NOR | Teacher | | `no310360570_laerer_5a` | TRIST LUKT | OMSORGSFULL NETT PIGGSVIN | 5A, 5A-MAT, 5B-MAT, 6A-MAT, 6B-MAT | Teacher | | `no310360570_laerer_5b` | ALTERNATIV DUSJ | OMSORGSFULL NETT PIGGSVIN | 5B, 5A-NOR, 5B-NOR | Teacher | | `no310360570_laerer_6a` | GEOMETRISK KRÅKE | OMSORGSFULL NETT PIGGSVIN | 6A, 6A-NOR | Teacher | | `no310360570_laerer_6b` | MINKENDE LISTE | OMSORGSFULL NETT PIGGSVIN | 6B, 6B-NOR | Teacher | | `no310360570_laerer_7a` | UTYDELIG TUNFISK | OMSORGSFULL NETT PIGGSVIN | 7A, 7A-MAT, 7B-MAT | Teacher | | `no310360570_laerer_7b` | SNILL AGURK | OMSORGSFULL NETT PIGGSVIN | 7B, 7A-NOR, 7B-NOR | Teacher | | `no310360570_laerer_8a` | POPULÆR BREIFLABB | OMSORGSFULL NETT PIGGSVIN | 8A, 8A-NOR | Teacher | | `no310360570_laerer_8b` | ALLMEKTIG FUGL | OMSORGSFULL NETT PIGGSVIN | 8B, 8B-NOR | Teacher | | `no310360570_laerer_9a` | MORSK SOLOPPGANG | OMSORGSFULL NETT PIGGSVIN | 9A, 9A-NOR | Teacher | | `no310360570_laerer_2_9a` | MASSE INFORMASJON | OMSORGSFULL NETT PIGGSVIN | 9A, 8A-MAT, 8B-MAT, 9A-MAT, 9B-MAT | Teacher | | `no310360570_laerer_9b` | BESKJEDEN ROSIN | OMSORGSFULL NETT PIGGSVIN | 9B, 9B-NOR | Teacher | | `no310360570_rektor` [9](#f9) | TRYGG PÆRE | OMSORGSFULL NETT PIGGSVIN | | Staff | | `no213656732_elev_1_1sf1` | TILBAKEHOLDEN ERIDOFOBI | UTÅLMODIG TREG PIGGSVIN | 1SF1, 1SF1-MAT1011, 1SF1-NOR1201 | Student | | `no213656732_elev_2_1sf1` | LATTERMILD HATT | UTÅLMODIG TREG PIGGSVIN | 1SF1, 1SF1-MAT1011, 1SF1-NOR1201 | Student | | `no213656732_elev_3_1sf1` | TILGIVENDE JUNGEL | UTÅLMODIG TREG PIGGSVIN | 1SF1, 1SF1-MAT1011, 1SF1-NOR1201 | Student | | `no213656732_elev_4_1sf1` | FRYKTSOM GJÆR | UTÅLMODIG TREG PIGGSVIN | 1SF1, 1SF1-MAT1011, 1SF1-NOR1201 | Student | | `no213656732_elev_5_1sf1` | LENGRE APRIL | UTÅLMODIG TREG PIGGSVIN | 1SF1, 1SF1-MAT1011, 1SF1-NOR1201 | Student | | `no213656732_elev_1_1md1` | USELVSTENDIG MALSTRØM | UTÅLMODIG TREG PIGGSVIN | 1MD1, 1MD1-MAT1011, 1MD1-NOR1201 | Student | | `no213656732_elev_2_1md1` | ANONYM FANE | UTÅLMODIG TREG PIGGSVIN | 1MD1, 1MD1-MAT1011, 1MD1-NOR1201 | Student | | `no213656732_elev_3_1md1` | MEMORERENDE TREGRENSE | UTÅLMODIG TREG PIGGSVIN | 1MD1, 1MD1-MAT1011, 1MD1-NOR1201 | Student | | `no213656732_elev_4_1md1` | ULYDIG KOKKEKNIV | UTÅLMODIG TREG PIGGSVIN | 1MD1, 1MD1-MAT1011, 1MD1-NOR1201 | Student | | `no213656732_elev_5_1md1` | SPENNENDE FAGRESSURS | UTÅLMODIG TREG PIGGSVIN | 1MD1, 1MD1-MAT1011, 1MD1-NOR1201 | Student | | `no213656732_elev_d_1md1` [4](#f4) | SKÅNSOM VÅGHALS | UTÅLMODIG TREG PIGGSVIN | 1MD1, 1MD1-MAT1011, 1MD1-NOR1201 | Student | | `no213656732_elev_1_2sf1` | VOKAL FROSTNATT | UTÅLMODIG TREG PIGGSVIN | 2SF1, 2SF1-NOR1208, 2SF1-REA3026 | Student | | `no213656732_elev_2_2sf1` | PRIKKETE DROSJE | UTÅLMODIG TREG PIGGSVIN | 2SF1, 2SF1-NOR1208, 2SF1-REA3026 | Student | | `no213656732_elev_3_2sf1` | ELEKTRONISK BAD | UTÅLMODIG TREG PIGGSVIN | 2SF1, 2SF1-NOR1208, 2SF1-REA3026 | Student | | `no213656732_elev_4_2sf1` | PEN FAKIR | UTÅLMODIG TREG PIGGSVIN | 2SF1, 2SF1-NOR1208, 2SF1-REA3026 | Student | | `no213656732_elev_5_2sf1` | ØVRIGE FANT | UTÅLMODIG TREG PIGGSVIN | 2SF1, 2SF1-NOR1208, 2SF1-REA3026 | Student | | `no213656732_elev_x_2sf1` [3](#f3) | GYLDEN BARBERSKUM | UTÅLMODIG TREG PIGGSVIN | 2SF1, 2SF1-NOR1208, 2SF1-REA3026 | Student | | `no213656732_elev_1_2md1` | SIVILISERT BUTIKK | UTÅLMODIG TREG PIGGSVIN | 2MD1, 2MD1-NOR1208, 2MD1-REA3026 | Student | | `no213656732_elev_2_2md1` | VISSEN FAMILIE | UTÅLMODIG TREG PIGGSVIN | 2MD1, 2MD1-NOR1208, 2MD1-REA3026 | Student | | `no213656732_elev_3_2md1` | LEKKER MORFAR | UTÅLMODIG TREG PIGGSVIN | 2MD1, 2MD1-NOR1208, 2MD1-REA3026 | Student | | `no213656732_elev_4_2md1` | LYSELILLA ÅKER | UTÅLMODIG TREG PIGGSVIN | 2MD1, 2MD1-NOR1208, 2MD1-REA3026 | Student | | `no213656732_elev_5_2md1` | PROAKTIV KARUSELL | UTÅLMODIG TREG PIGGSVIN | 2MD1, 2MD1-NOR1208, 2MD1-REA3026 | Student | | `no213656732_elev_1_3sf1` | VIKTIG MATTE | UTÅLMODIG TREG PIGGSVIN | 3SF1, 3SF1-NOR1211, 3SF1-REA3028 | Student | | `no213656732_elev_2_3sf1` | KONSEKVENT DROTT | UTÅLMODIG TREG PIGGSVIN | 3SF1, 3SF1-NOR1211, 3SF1-REA3028 | Student | | `no213656732_elev_3_3sf1` | MOBIL BADESTRAND KONSONANT | UTÅLMODIG TREG PIGGSVIN | 3SF1, 3SF1-NOR1211, 3SF1-REA3028 | Student | | `no213656732_elev_4_3sf1` | VÅKEN SVAMP | UTÅLMODIG TREG PIGGSVIN | 3SF1, 3SF1-NOR1211, 3SF1-REA3028 | Student | | `no213656732_elev_5_3sf1` | RAKRYGGET ADELSMANN | UTÅLMODIG TREG PIGGSVIN | 3SF1, 3SF1-NOR1211, 3SF1-REA3028 | Student | | `no213656732_elev_d_3sf1` [4](#f4) | TURKIS MANDOLIN | UTÅLMODIG TREG PIGGSVIN | 3SF1, 3SF1-NOR1211, 3SF1-REA3028 | Student | | `no213656732_elev_1_3md1` | HEMMELIGHETSFULL KÅLRABI | UTÅLMODIG TREG PIGGSVIN | 3MD1, 3MD1-NOR1211, 3MD1-REA3028 | Student | | `no213656732_elev_2_3md1` | ORDENTLIG DIAMETER | UTÅLMODIG TREG PIGGSVIN | 3MD1, 3MD1-NOR1211, 3MD1-REA3028 | Student | | `no213656732_elev_3_3md1` | DISKRET BALANSE | UTÅLMODIG TREG PIGGSVIN | 3MD1, 3MD1-NOR1211, 3MD1-REA3028 | Student | | `no213656732_elev_4_3md1` | UFRUKTBAR TURBIN | UTÅLMODIG TREG PIGGSVIN | 3MD1, 3MD1-NOR1211, 3MD1-REA3028 | Student | | `no213656732_elev_5_3md1` | SPRUDLENDE TIMEBU | UTÅLMODIG TREG PIGGSVIN | 3MD1, 3MD1-NOR1211, 3MD1-REA3028 | Student | | `no213656732_laerer_1sf1` | KONSENTRISK KJEKS | UTÅLMODIG TREG PIGGSVIN | 1SF1, 1SF1-MAT1011, 1MD1-NOR1201, 1SF1-NOR1201 | Teacher | | `no213656732_laerer_1md1` | KONSERVATIV RAMME | UTÅLMODIG TREG PIGGSVIN | 1MD1, 1MD1-MAT1011 | Teacher | | `no213656732_laerer_2sf1` | ALLSLAGS KÅLRABI | UTÅLMODIG TREG PIGGSVIN | 2SF1, 2MD1-NOR1208, 2SF1-NOR1208 | Teacher | | `no213656732_laerer_2md1` | OPPRETTHOLDENDE BOBLE | UTÅLMODIG TREG PIGGSVIN | 2MD1, 2MD1-REA3026, 2SF1-REA3026 | Teacher | | `no213656732_laerer_3sf1` | STORARTET GITAR | UTÅLMODIG TREG PIGGSVIN | 3SF1, 3SF1-NOR1211, 3SF1-REA3028 | Teacher | | `no213656732_laerer_3md1` | INNBRINGENDE STRØMPEBUKSE | UTÅLMODIG TREG PIGGSVIN | 3MD1, 3MD1-NOR1211, 3MD1-REA3028 | Teacher | | `no213656732_ansatt_1` | MARITIM VARIASJON | UTÅLMODIG TREG PIGGSVIN | | Staff | | `no213656732_ansatt_2` | LIVSTRETT KØYESENG | UTÅLMODIG TREG PIGGSVIN | | Staff | #### Users with guardian information | Username | Name | School | Guardians | Class/Course | Type | |---------------------------------------------|-----------------------|-------------------------|--------------------------|------------------------------------|---------| | `no212558702_elev_1_5a` | FASCINERENDE VERANDA | SMAL FYSISK PIGGSVIN | 18848599901, 30818199836 | 5A, 5A-MAT, 5A-NOR | Student | | `no212558702_elev_1_5b` [5](#f5) | ÅPEN GLOBUS | SMAL FYSISK PIGGSVIN | 10877796502, 15817997888 | 5B, 5B-MAT, 5B-NOR | Student | | `no212558702_elev_1_7a` | HARDHUDET SAUS | SMAL FYSISK PIGGSVIN | 15928798787, 20878898886 | 7A, 7A-MAT, 7A-NOR | Student | | `no212558702_elev_1_7b` | GRØNN BAKKEKLARING | SMAL FYSISK PIGGSVIN | 04928898445, 12868799151 | 7B, 7B-MAT, 7B-NOR | Student | | `no212558702_elev_1_9a` [6](#f6) | FLEKSIBEL MAIS | SMAL FYSISK PIGGSVIN | 18918299331, 19838399404 | 9A, 9A-MAT, 9A-NOR | Student | | `no212558702_elev_1_9b` | UTNYTTENDE KORTSTOKK | SMAL FYSISK PIGGSVIN | 06837295465, 16817196571 | 9B, 9B-MAT, 9B-NOR | Student | | `no212558702_elev_2_5a` [6](#f6) | USTABIL INNTEKT | SMAL FYSISK PIGGSVIN | 18918299331, 19838399404 | 5A, 5A-MAT, 5A-NOR | Student | | `no212558702_elev_2_5b` [7](#f7) | UPERSONLIG KONTRAST | SMAL FYSISK PIGGSVIN | 18898598663, 23928399338 | 5B, 5B-MAT, 5B-NOR | Student | | `no212558702_elev_2_7a` | ØKOLOGISK PRODUKSJON | SMAL FYSISK PIGGSVIN | 02847697493, 20817695729 | 7A, 7A-MAT, 7A-NOR | Student | | `no212558702_elev_2_7b` | LETT PRÆRIEULV | SMAL FYSISK PIGGSVIN | 21818099107, 31817898222 | 7B, 7B-MAT, 7B-NOR | Student | | `no212558702_elev_2_9a` | GÅEN GJERDE | SMAL FYSISK PIGGSVIN | 03848499268, 23888499784 | 9A, 9A-MAT, 9A-NOR | Student | | `no212558702_elev_2_9b` | SKJØR GANG | SMAL FYSISK PIGGSVIN | 05897497257, 20857298781 | 9B, 9B-MAT, 9B-NOR | Student | | `no212558702_laerer_5a` | FREIDIG KONTRADIKSJON | SMAL FYSISK PIGGSVIN | | 5A, 5A-MAT, 5B-MAT, 6A-MAT, 6B-MAT | Teacher | | `no212558702_laerer_5b` | FAST TOMAT | SMAL FYSISK PIGGSVIN | | 5B, 5A-NOR, 5B-NOR | Teacher | | `no212558702_laerer_7a` | INTEGRERT HIMMEL | SMAL FYSISK PIGGSVIN | | 7A, 7A-MAT, 7B-MAT, 9A-MAT, 9B-MAT | Teacher | | `no212558702_laerer_7b` | UTNYTTENDE LARVE | SMAL FYSISK PIGGSVIN | | 7B, 7A-NOR, 7B-NOR | Teacher | | `no212558702_laerer_9a` | FAMILIÆR PEDAGOG | SMAL FYSISK PIGGSVIN | | 9A, 9A-NOR | Teacher | | `no212558702_laerer_9b` | UTØRST NEVE | SMAL FYSISK PIGGSVIN | | 9B, 9B-NOR | Teacher | | `no212558702_rektor` | PARODISK HALE | SMAL FYSISK PIGGSVIN | | | Staff | | `no214215942_elev_1_2a` [7](#f7) | USIKKER NATT | ULLEN EFFEKTIV PIGGSVIN | 18898598663, 23928399338 | 2A, 2A-MAT, 2A-NOR | Student | | `no214215942_elev_1_2b` | EFFEKTIV MUTTER | ULLEN EFFEKTIV PIGGSVIN | 25829297798, 26849498451 | 2B, 2B-MAT, 2B-NOR | Student | | `no214215942_elev_1_4a` | SIVILISERT RESTAURANT | ULLEN EFFEKTIV PIGGSVIN | 03827698902, 15877799635 | 4A, 4A-MAT, 4A-NOR | Student | | `no214215942_elev_1_4b` | UTØRST PEDAL | ULLEN EFFEKTIV PIGGSVIN | 01927695320, 22857795435 | 4B, 4B-MAT, 4B-NOR | Student | | `no214215942_elev_1_6a` | FANTASILØS PYRAMIDE | ULLEN EFFEKTIV PIGGSVIN | 15918397768, 18928397099 | 6A, 6A-MAT, 6A-NOR | Student | | `no214215942_elev_1_6b` | EKSPLOSIV DRAGE | ULLEN EFFEKTIV PIGGSVIN | 14878099355, 14887698881 | 6B, 6B-MAT, 6B-NOR | Student | | `no214215942_elev_2_2a` | SPED BOMULL | ULLEN EFFEKTIV PIGGSVIN | 06828699812, 19849099984 | 2A, 2A-MAT, 2A-NOR | Student | | `no214215942_elev_2_2b` [8](#f8) | UPOPULÆR LOGARITME | ULLEN EFFEKTIV PIGGSVIN | 17868196084, 25908297132 | 2B, 2B-MAT, 2B-NOR | Student | | `no214215942_elev_2_4a` | FYLDIG FJORD | ULLEN EFFEKTIV PIGGSVIN | 10827999208, 16848096982 | 4A, 4A-MAT, 4A-NOR | Student | | `no214215942_elev_2_4b` [8](#f8) | GRØNN OLIVENOLJE | ULLEN EFFEKTIV PIGGSVIN | 17868196084, 25908297132 | 4B, 4B-MAT, 4B-NOR | Student | | `no214215942_elev_2_6a` | PESSIMISTISK DEL | ULLEN EFFEKTIV PIGGSVIN | 06898999996, 13828999405 | 6A, 6A-MAT, 6A-NOR | Student | | `no214215942_elev_2_6b` | PARODISK FIL | ULLEN EFFEKTIV PIGGSVIN | 20857896433, 29818098578 | 6B, 6B-MAT, 6B-NOR | Student | | `no214215942_laerer_2a` | USTABIL BANK | ULLEN EFFEKTIV PIGGSVIN | | 2A, 2A-MAT, 2A-MAT | Teacher | | `no214215942_laerer_2b` | MÅTEHOLDEN VURDERING | ULLEN EFFEKTIV PIGGSVIN | | 2B, 2A-NOR, 2B-NOR | Teacher | | `no214215942_laerer_4a` | FRISK ABAKUS | ULLEN EFFEKTIV PIGGSVIN | | 4A, 4A-NOR, 4A-NOR | Teacher | | `no214215942_laerer_4b` | ULOGISK OPPSKRIFT | ULLEN EFFEKTIV PIGGSVIN | | 4B, 4A-MAT, 4B-MAT, 6A-MAT, 6B-MAT | Teacher | | `no214215942_laerer_6a` | HUMORISTISK JUKEBOKS | ULLEN EFFEKTIV PIGGSVIN | | 6A, 6A-NOR | Teacher | | `no214215942_laerer_6b` | KLOK ENGEL | ULLEN EFFEKTIV PIGGSVIN | | 6B, 6B-NOR | Teacher | | `no214215942_rektor` | FREIDIG BRIS | ULLEN EFFEKTIV PIGGSVIN | | | Staff | ### Footnotes * **[1]** These users can use MFA through authenticator codes from [https://totp.danhersam.com/](https://totp.danhersam.com/). * **[2]** These users are affiliated with multiple schools, thus their information spans several rows. * **[3]** The matching person in Tenor has an address of type “fortrolig” * **[4]** The matching person in Tenor has status “doed” * **[5]** The guardian FAMILIÆR PEDAGOG is a teacher for 9A at the same school * **[6]** These students have the same guardians * **[7]** These students have the same guardians * **[8]** These students have the same guardians * **[9]** This user is also the principal of the GLOVARM IVRIG PIGGSVIN, RESERVERT SLITEN PIGGSVIN, and UTÅLMODIG TREG PIGGSVIN schools