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 from the Service Provider

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.

Step 5: Entree Federation sends an authentication request to the Identity Provider

Entree Federation sends an authentication request to the Identity Provider, similar to the request that was send to Entree Federation by the Service Provider. However the element <Issuer> will contain the identifier of Entree Federation, since in this instance Entree Federation is the issuer of the request.

<AuthnRequest>
   ...
   <Issuer>aselect.entree.kennisnet.nl</Issuer>
   ...
</AuthnRequest>

Step 6: The Identity Provider validates the authentication request from Entree Federation

Just like Entree Federation validated the authentication request send by the Service Provider, the Identity Provider will now validate the autentication request made by Entree Federation. This is also based on the metadata both parties have exchanged during the initial configuration of the connection.

Step 7: The Identity Provider authenticates the user

The Identity Provider will require the user to log in, unless the user already has a current session with the Identity Provider. In that case the authentication will occur automatic.

Step 8: The Identity Provider sends a response to Entree Federation

The Identity Provider sends a SAML response message to Entree Federation. This message contains an assertion about the identity of the user. The message will be send to the endpoint listed in the <AssertionConsumerService>-element in the metadata of Entree Federation:

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

Key elements in the SAML resonse are:

• The <Issuer> of the message, in this case the Identity Provider.
• The <StatusCode> indicating the result of the authentication with the Identity Provider.
• The <NameID>-element containing the subject (in this case the user) the authentication applies to.
• <AttributeStatement> contains the attributes with the personal data. The values in the uid-attribute and the <NameID>-element have to be similar.

<Response>
   ...
   <Issuer>petteflatcollege.nl</Issuer>
   <Status>
      <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
   </Status>
   ...
   <Assertion>
      <Subject>
         <NameID>pietjepukkelen@petteflatcollege</NameID>
         ...
      </Subject>
      ...
      <AttributeStatement>
         <Attribute Name="uid">
            <AttributeValue>pietjepukkelen@petteflatcollege</AttributeValue>
         </Attribute>
         <Attribute Name="employeeNumber">
            <AttributeValue>1234</AttributeValue>
         </Attribute>
         <Attribute Name="givenName">
            <AttributeValue>Pietje</AttributeValue>
         </Attribute>
         <Attribute Name="mail">
            <AttributeValue>p.pukkelen@petteflatcollege.nl</AttributeValue>
         </Attribute>
         <Attribute Name="nlEduPersonHomeOrganizationId">
            <AttributeValue>99ZZ03</AttributeValue>
         </Attribute>
         ...
      </AttributeStatement>
      ...
   </Assertion>
</Response>