Ctrl+K

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.

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 and supports the Interoperable SAML 2.0 Web Browser SSO Deployment Profile. For more information about Feide as well as technical details for the integration, please refer to the Feide Integration Guide and the Feide Technical Guide.

SAML 2.0 Web SSO Profile#

Feide uses the Web Browser SSO Profile defined by SAML 2.0. 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 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. 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:

  • 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:

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 feideSchoolList4 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.

On this page