KNF:Hoe werkt Entree Federatie?/en

Nederlands

English

Entree Federation enables Dutch educational users to access a large number of educational services using a single login (als known as Single Sign On or SSO). The federation consists of parties providing educational services or content (Service Providers), administrators of identities (Identity Providers) and the Kennisnet application (Entree Federation).

An Identity Provider is an application that carries out the communication with Entree Federation on behalf of the school. Some examples of Identity Provider applications are:

• Virtual learning environment or VLE (a web-based platform, often used by multiple educational institutions)
• Active Directory Federation Service (ADFS)
• Google Apps for Education
• Azure AD

The Entree Federation application serves as a federative intermediary (or hub) in the authenticationprocess.

Federative Single Sign On has the following advantages:

1. User friendliness: users are enabled to get access to multiple educational web applications with a single username/password combination.
2. Connected organisations only have to develop and maintain the interface with Entree Federation, instead of multiple interfaces.
3. The secure exchange of messages is based on a trust relation between Entree Federation and the connected organisations.
4. Just one connection to Entree Federation provides Service Providers with the opportunity to unlock their application to thousands of schools based on reliable identities.
5. The educational institutes stay in control over the personal data of its users.

In order to authenticate a user, XML messages are exchanged between the various parties based on the open SAML 2.0 standard (Security Assertion Markup Language). This authenticationprocess is described in more detail below.

Step 1: A user wants to access protected content

A user wants to access protected content of a Service Provider. The latter will request Entree Federation to establish the identity of the user. This identity enables the Service Provider to determine whether or not the user is allowed to access the content.

Step 2: The Service Provider sends an authentication request to Entree Federation

The Service Provider sends an authentication request to the server of Entree Federation. This request contains among other things, the Service Provider's unique identifier in the <Issuer>-element.

<AuthnRequest>
   ...
   <Issuer>https://wikiwijs.nl</Issuer>
   ...
</AuthnRequest>

During the initial configuration of the connection the Service Provider and Entree Federation exchanged metadata. These files contain the unique identifiers, endpoints and information about the encryption that is used.

The Service Provider will send the authentication request to the endpoint that is described in the <SingleSignOnService>-element within the Entree Federation metadata.

<EntityDescriptor entityID="aselect.entree.kennisnet.nl">
   ...
   <IDPSSODescriptor>
      ...
      <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
         Location="https://aselect.entree.kennisnet.nl/openaselect/profiles/saml2/sso/web"/>
      ...
   </IDPSSODescriptor>
</EntityDescriptor>

In this example HTTP-POST will be used as the communications protocol (also called binding). Each entity can support several bindings, each one of these bindings will be listed in it's metadata. Entree Federation also supports the HTTP-Redirect and HTTP-Artifact bindings.

Step 3: Entree Federation validates the athentication request

The Entree Federation application will validate the authentication request on the basis of the Service Provider's metadata. For example it will check if the entityID in the metadata matches the value in the <Issuer> element of the authentication request.

Step 4: The user selects the Identity Provider

The user will be redirected to the Entree Federation's WAYF-screen (Where Are You From). The user will select his school and with that the corresponding Identity Provider.