KNF:Hoe werkt Entree Federatie?: verschil tussen versies

Uit Kennisnet Developers Documentatie
Naar navigatie springen Naar zoeken springen
 
(15 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 11: Regel 11:
 
*Azure AD
 
*Azure AD
   
De applicatie van Entree Federatie fungeert als een federatieve intermediair (of hub) voor authenticatie. Het is dus het centrale knooppunt waarlangs alle federatieve inlogverzoeken worden afgehandeld.
+
De applicatie van Entree Federatie fungeert als een federatieve intermediair (of hub) in het authenticatieproces. Het is dus het centrale knooppunt waarlangs alle federatieve authenticatie berichten worden afgehandeld.
 
[[File:Entree_Federatie_overview.png|600px|left]]<br clear="all">
 
[[File:Entree_Federatie_overview.png|600px|left]]<br clear="all">
   
Regel 21: Regel 21:
 
# De onderwijsinstelling houdt de controle over de persoonsgegevens van haar gebruikers.
 
# De onderwijsinstelling houdt de controle over de persoonsgegevens van haar gebruikers.
   
Om een gebruiker te authenticeren worden berichten tussen de verschillende partijen uitgewisseld op basis van het SAML 2.0 protocol ('''S'''ecurity '''A'''ssertion '''M'''arkup '''L'''anguage). Dit authenticatieproces staat hieronder beschreven.
+
Om een gebruiker te authenticeren worden XML berichten tussen de verschillende partijen uitgewisseld op basis van [https://wiki.oasis-open.org/security de open SAML 2.0 standaard] ('''S'''ecurity '''A'''ssertion '''M'''arkup '''L'''anguage). Dit authenticatieproces staat hieronder beschreven.
   
 
==Stap 1: Gebruiker wil toegang tot afgeschermde content==
 
==Stap 1: Gebruiker wil toegang tot afgeschermde content==
 
[[File:saml_step_01.png|350px|left]]<br clear="all">
 
[[File:saml_step_01.png|350px|left]]<br clear="all">
Een gebruiker wil toegang tot afgeschermde content van de Service Provider. Deze laatste vraagt nu aan Entree Federatie de identiteit van de gebruiker, om daarmee te bepalen of de gebruiker toegang krijgt.
+
Een gebruiker wil toegang tot afgeschermde content van de Service Provider. Deze laatste vraagt nu aan Entree Federatie om de identiteit van de gebruiker vast te stellen. Aan de hand van die identiteit kan de Service Provider bepalen of de gebruiker toegang krijgt.
 
<br/><br/>
 
<br/><br/>
   
Regel 41: Regel 41:
 
Bij de initiële configuratie van de koppeling tussen Entree Federatie en de Service Provider hebben deze metadata bestanden met elkaar uitgewisseld. Hierin staan onder andere de unieke identifiers, endpoints en informatie over de gebruikte versleuteling van beide partijen.
 
Bij de initiële configuratie van de koppeling tussen Entree Federatie en de Service Provider hebben deze metadata bestanden met elkaar uitgewisseld. Hierin staan onder andere de unieke identifiers, endpoints en informatie over de gebruikte versleuteling van beide partijen.
   
Het verzoek wordt verstuurd naar het endpoint dat in het element ''<SingleSignOnService>'' in de metadata van Entree Federatie staat.
+
Het verzoek wordt door de Service Provider gestuurd naar het endpoint dat in het element ''<SingleSignOnService>'' in de metadata van Entree Federatie staat.
 
<syntaxhighlight lang="xml">
 
<syntaxhighlight lang="xml">
 
<EntityDescriptor entityID="aselect.entree.kennisnet.nl">
 
<EntityDescriptor entityID="aselect.entree.kennisnet.nl">
Regel 53: Regel 53:
 
</EntityDescriptor>
 
</EntityDescriptor>
 
</syntaxhighlight>
 
</syntaxhighlight>
In dit voorbeeld zal gebruik gemaakt worden van ''HTTP-POST''. Een partij kan meerdere bindings ondersteunen, deze zullen ieder dan vermeld staan in de metadata. Entree Federatie ondersteund ook ''HTTP-Redirect'' en ''HTTP-Artifact'' als binding.
+
In dit voorbeeld zal gebruik gemaakt worden van ''HTTP-POST'' als coomunicatie protocol (ook wel ''binding'' genoemd). Een partij kan meerdere bindings ondersteunen, deze zullen ieder dan vermeld staan in de metadata. Entree Federatie ondersteund ook ''HTTP-Redirect'' en ''HTTP-Artifact'' als binding.
 
<br/><br/>
 
<br/><br/>
   
==Stap 3: Entree Federatie valideert het authenticatie verzoek==
+
==Stap 3: Entree Federatie valideert het authenticatie verzoek van de Service Provider==
 
[[File:saml_step_03.png|350px|left]]<br clear="all">
 
[[File:saml_step_03.png|350px|left]]<br clear="all">
 
Entree Federatie valideert het authenticatie verzoek aan de hand van metadata van de Service Provider. Zo wordt gecontroleerd het ''entityID'' in de metadata overeenkomt met de waarde in het ''<Issuer>'' element in het authenticatie verzoek.
 
Entree Federatie valideert het authenticatie verzoek aan de hand van metadata van de Service Provider. Zo wordt gecontroleerd het ''entityID'' in de metadata overeenkomt met de waarde in het ''<Issuer>'' element in het authenticatie verzoek.
Regel 68: Regel 68:
 
==Stap 5: Entree Federatie verstuurt een authenticatie verzoek naar de Identity Provider==
 
==Stap 5: Entree Federatie verstuurt een authenticatie verzoek naar de Identity Provider==
 
[[File:saml_step_05.png|350px|left]]<br clear="all">
 
[[File:saml_step_05.png|350px|left]]<br clear="all">
[[Categorie:Entree Federatie]]
 
 
Entree Federatie verstuurt nu een authenticatie verzoek naar de Identity Provider, net zoals de Service Provider eerder in het proces een authenticatie verzoek naar Entree Federatie verstuurde. In het element ''<Issuer>'' staat nu de identifier van Entree Federatie.
 
Entree Federatie verstuurt nu een authenticatie verzoek naar de Identity Provider, net zoals de Service Provider eerder in het proces een authenticatie verzoek naar Entree Federatie verstuurde. In het element ''<Issuer>'' staat nu de identifier van Entree Federatie.
 
<syntaxhighlight lang="xml">
 
<syntaxhighlight lang="xml">
Regel 84: Regel 83:
 
<br/><br/>
 
<br/><br/>
   
==Stap 7: Indien nodig verzorgt de Identity Provider het inloggen van de gebruiker==
+
==Stap 7: De Identity Provider authenticeert de gebruiker==
 
[[File:saml_step_07.png|350px|left]]<br clear="all">
 
[[File:saml_step_07.png|350px|left]]<br clear="all">
 
De Identity Provider toont de gebruiker het eigen inlogscherm tenzij de gebruiker al een sessie heeft bij de Identity Provider. In dat laatste geval zal deze stap in de authenticatie automatisch verlopen.
 
De Identity Provider toont de gebruiker het eigen inlogscherm tenzij de gebruiker al een sessie heeft bij de Identity Provider. In dat laatste geval zal deze stap in de authenticatie automatisch verlopen.
Regel 91: Regel 90:
 
==Stap 8: De Identity Provider stuurt een antwoord naar Entree Federatie==
 
==Stap 8: De Identity Provider stuurt een antwoord naar Entree Federatie==
 
[[File:saml_step_08.png|350px|left]]<br clear="all">
 
[[File:saml_step_08.png|350px|left]]<br clear="all">
De Identity Provider verstuurt nu een antwoord naar Entree Federatie in de vorm van een SAML response bericht. Dit bericht wordt gestuurd naar het endpoint dat in het element ''<AssertionConsumerService>'' in de metadata van Entree Federatie staat.
+
De Identity Provider verstuurt nu een antwoord naar Entree Federatie in de vorm van een SAML response bericht. Het bericht bevat een verklaring (of assertion) over de identiteit van de gebruiker. Het antwoord wordt gestuurd naar het endpoint dat in het element ''<AssertionConsumerService>'' in de metadata van Entree Federatie staat:
 
<syntaxhighlight lang="xml">
 
<syntaxhighlight lang="xml">
 
<EntityDescriptor entityID="aselect.entree.kennisnet.nl">
 
<EntityDescriptor entityID="aselect.entree.kennisnet.nl">
Regel 103: Regel 102:
 
</EntityDescriptor>
 
</EntityDescriptor>
 
</syntaxhighlight>
 
</syntaxhighlight>
  +
<br/>
 
Een aantal belangrijke elementen in de SAML response zijn:
 
Een aantal belangrijke elementen in de SAML response zijn:
 
* De ''<Issuer>'' van het bericht, ditmaal is dat de Identity Provider. Entree Federatie zal de waarde ook weer valideren tegen de metadata die bekend is van de Identity Provider.
 
* De ''<Issuer>'' van het bericht, ditmaal is dat de Identity Provider. Entree Federatie zal de waarde ook weer valideren tegen de metadata die bekend is van de Identity Provider.
Regel 149: Regel 149:
 
[[File:saml_step_09.png|350px|left]]<br clear="all">
 
[[File:saml_step_09.png|350px|left]]<br clear="all">
 
Voordat de gegevens worden doorgestuurd naar de Service Provider worden er nog een aantal bewerkingen en controles door Entree Federatie uitgevoerd:
 
Voordat de gegevens worden doorgestuurd naar de Service Provider worden er nog een aantal bewerkingen en controles door Entree Federatie uitgevoerd:
* De waarde in het attribuut ''employeeNumber'' en het gedeelte voor de ''@'' in het attribuut ''uid'' worden versleuteld. De realm uit het ''uid'' (in dit geval ''@petteflatcollege'') wordt daar vervolgens weer aan toegevoegd. Dit is het uniek ID waaraan Service Providers de gebruiker herkennen.
+
* De waarde in het attribuut ''employeeNumber'' en het gedeelte voor de ''@'' in het attribuut ''uid'' worden samengevoegd en versleuteld. De realm uit het ''uid'' (in dit geval ''@petteflatcollege'') wordt daar vervolgens weer aan toegevoegd. Dit is het uniek ID waaraan Service Providers de gebruiker herkennen.
 
* Er wordt gecontroleerd of er binnen de applicatie van Entree Federatie aan de Identity Provider een school gekoppeld is met een BRIN nummer dat overeenkomt met de waarde in het ''nlEduPersonHomeOrganizationId'' attribuut.
 
* Er wordt gecontroleerd of er binnen de applicatie van Entree Federatie aan de Identity Provider een school gekoppeld is met een BRIN nummer dat overeenkomt met de waarde in het ''nlEduPersonHomeOrganizationId'' attribuut.
 
* Er wordt bepaald voor welke attributen de school toestemming heeft gegeven om door te geven aan de Service Provider.
 
* Er wordt bepaald voor welke attributen de school toestemming heeft gegeven om door te geven aan de Service Provider.
Regel 160: Regel 160:
 
Entree Federatie verstuurt nu het aangepaste SAML response bericht door naar de Service Provider. Dit bericht wordt gestuurd naar het endpoint dat in het element ''<AssertionConsumerService>'' in de metadata van de Service Provider staat.
 
Entree Federatie verstuurt nu het aangepaste SAML response bericht door naar de Service Provider. Dit bericht wordt gestuurd naar het endpoint dat in het element ''<AssertionConsumerService>'' in de metadata van de Service Provider staat.
   
In het voorbeeld wijkt dit bericht op een aantal punten af van de SAML response uit stap 9:
+
In het voorbeeld wijkt dit bericht op een aantal punten af van de SAML response uit stap 8:
 
* Aangezien de applicatie van Entree Federatie dit bericht naar de Service Provider verstuurt, bevat het element ''<Issuer>'' nu de waarde ''aselect.entree.kennisnet.nl''.
 
* Aangezien de applicatie van Entree Federatie dit bericht naar de Service Provider verstuurt, bevat het element ''<Issuer>'' nu de waarde ''aselect.entree.kennisnet.nl''.
 
* Het element ''<NameID>'' en het attribuut ''uid'' bevatten nu de versleutelde waarde van de attributen ''uid'' en ''employeeNumber''.
 
* Het element ''<NameID>'' en het attribuut ''uid'' bevatten nu de versleutelde waarde van de attributen ''uid'' en ''employeeNumber''.
 
* Het attribuut ''employeeNumber'' wordt nooit doorgestuurd naar een Service Provider en is uit het SAML response bericht gefilterd.
 
* Het attribuut ''employeeNumber'' wordt nooit doorgestuurd naar een Service Provider en is uit het SAML response bericht gefilterd.
* In het voorbeeld gaan we er vanuit dat de school geen toestemming heeft gegeven om het attribuut ''mail'' door te sturen naar deze Service Provider. Dit attribuut is dan ook verwijderd uit het SAML response bericht.
+
* In het voorbeeld gaan we ervan uit dat de school geen toestemming heeft gegeven om het attribuut ''mail'' door te sturen naar deze Service Provider. Dit attribuut is dan ook verwijderd uit het SAML response bericht.
* In dit voorbeeld heeft de gebruiker een digicode voor deze Service Provider geactiveerd en dit is als het attribuut ''DL_IDSP_Licentiecode2017'' toegevoegd.
+
* In dit voorbeeld heeft de gebruiker een geactiveerde digicode voor deze Service Provider en deze is als het attribuut ''DL_IDSP_Licentiecode2017'' toegevoegd.
   
 
<syntaxhighlight lang="xml">
 
<syntaxhighlight lang="xml">
Regel 211: Regel 211:
   
 
Aangezien het afhandelen van de autorisatie bij de Service Provider ligt heeft die ook de controle over welke gegevens er gebruikt worden om te bepalen of een gebruiker toegang krijgt.
 
Aangezien het afhandelen van de autorisatie bij de Service Provider ligt heeft die ook de controle over welke gegevens er gebruikt worden om te bepalen of een gebruiker toegang krijgt.
  +
 
[[Categorie:Entree Federatie]]

Huidige versie van 25 feb 2017 om 22:42

Nl.gif Nederlands En.gif English


Entree Federatie geeft gebruikers in het po, vo en mbo toegang tot een groot aantal educatieve diensten met slechts één login (ook wel bekend als Single Sign On of SSO). De federatie wordt gevormd door aanbieders van een educatieve dienst of content (Service Providers), beheerders van identiteiten (Identity Providers) en de applicatie van Kennisnet (Entree Federatie).

Een Identity Provider is de applicatie die voor de school de communicatie met Entree Federatie verzorgt. Voorbeelden van Identity Providers zijn:

  • Elektronische Leeromgevingen (een centrale digitale omgeving die meestal door meerdere scholen wordt gebruikt)
  • Active Directory Federation Service (ADFS)
  • Google Apps for Education
  • Azure AD

De applicatie van Entree Federatie fungeert als een federatieve intermediair (of hub) in het authenticatieproces. Het is dus het centrale knooppunt waarlangs alle federatieve authenticatie berichten worden afgehandeld.

Entree Federatie overview.png


Federatieve Single Sign On heeft een aantal voorbeelden:

  1. Gemak voor gebruikers: met slecht één login hebben zij toegang tot een groot aantal educatieve websites.
  2. Aangesloten partijen hoeven slechts één koppelvlak te ontwikkelen en te onderhouden, namelijk die met Entree Federatie.
  3. Uitwisseling van berichten gebeurt op een veilige manier gebaseerd op vertrouwensrelaties tussen Entree Federatie en de aangesloten partijen.
  4. Service Providers ontsluiten hun dienst of content met één koppeling voor duizenden scholen op basis van betrouwbare identiteiten.
  5. De onderwijsinstelling houdt de controle over de persoonsgegevens van haar gebruikers.

Om een gebruiker te authenticeren worden XML berichten tussen de verschillende partijen uitgewisseld op basis van de open SAML 2.0 standaard (Security Assertion Markup Language). Dit authenticatieproces staat hieronder beschreven.

Stap 1: Gebruiker wil toegang tot afgeschermde content

Saml step 01.png


Een gebruiker wil toegang tot afgeschermde content van de Service Provider. Deze laatste vraagt nu aan Entree Federatie om de identiteit van de gebruiker vast te stellen. Aan de hand van die identiteit kan de Service Provider bepalen of de gebruiker toegang krijgt.

Stap 2: De Service Provider verstuurt een authenticatie verzoek naar Entree Federatie

Saml step 02.png


De Service Provider verstuurt een authenticatie verzoek naar de server van Entree Federatie. Dit verzoek bevat onder andere een unieke identifier van de Service Provider in het element <Issuer>.

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

Bij de initiële configuratie van de koppeling tussen Entree Federatie en de Service Provider hebben deze metadata bestanden met elkaar uitgewisseld. Hierin staan onder andere de unieke identifiers, endpoints en informatie over de gebruikte versleuteling van beide partijen.

Het verzoek wordt door de Service Provider gestuurd naar het endpoint dat in het element <SingleSignOnService> in de metadata van Entree Federatie staat.

<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 dit voorbeeld zal gebruik gemaakt worden van HTTP-POST als coomunicatie protocol (ook wel binding genoemd). Een partij kan meerdere bindings ondersteunen, deze zullen ieder dan vermeld staan in de metadata. Entree Federatie ondersteund ook HTTP-Redirect en HTTP-Artifact als binding.

Stap 3: Entree Federatie valideert het authenticatie verzoek van de Service Provider

Saml step 03.png


Entree Federatie valideert het authenticatie verzoek aan de hand van metadata van de Service Provider. Zo wordt gecontroleerd het entityID in de metadata overeenkomt met de waarde in het <Issuer> element in het authenticatie verzoek.

Stap 4: De gebruiker selecteert de Identity Provider

Saml step 04.png


De gebruiker wordt geredirect naar het WAYF-scherm (Where Are You From) van Entree Federatie. Hier kan hij zijn school opzoeken en kiezen. Daarmee wordt gelijk de Identity Provider van de school geselecteerd.

Stap 5: Entree Federatie verstuurt een authenticatie verzoek naar de Identity Provider

Saml step 05.png


Entree Federatie verstuurt nu een authenticatie verzoek naar de Identity Provider, net zoals de Service Provider eerder in het proces een authenticatie verzoek naar Entree Federatie verstuurde. In het element <Issuer> staat nu de identifier van Entree Federatie.

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



Stap 6: De Identity Provider valideert het authenticatie verzoek van Entree Federatie

Saml step 06.png


Net zoals Entree Federatie het authenticatie verzoek van de Service Provider heeft gevalideerd, zal ook de Identity Provider het authenticatie verzoek van Entree Federatie valideren. Ook dit gebeurt op basis van de metadata die de partijen hebben uitgewisseld bij het aanmaken van de koppeling.

Stap 7: De Identity Provider authenticeert de gebruiker

Saml step 07.png


De Identity Provider toont de gebruiker het eigen inlogscherm tenzij de gebruiker al een sessie heeft bij de Identity Provider. In dat laatste geval zal deze stap in de authenticatie automatisch verlopen.

Stap 8: De Identity Provider stuurt een antwoord naar Entree Federatie

Saml step 08.png


De Identity Provider verstuurt nu een antwoord naar Entree Federatie in de vorm van een SAML response bericht. Het bericht bevat een verklaring (of assertion) over de identiteit van de gebruiker. Het antwoord wordt gestuurd naar het endpoint dat in het element <AssertionConsumerService> in de metadata van Entree Federatie staat:

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


Een aantal belangrijke elementen in de SAML response zijn:

  • De <Issuer> van het bericht, ditmaal is dat de Identity Provider. Entree Federatie zal de waarde ook weer valideren tegen de metadata die bekend is van de Identity Provider.
  • De <StatusCode> geeft aan wat het resultaat van de authenticatie bij de Identity Provider is.
  • In <NameID> staat het onderwerp (in dit geval de persoon) waarvoor een authenticatie heeft plaatsgevonden.
  • <AttributeStatement> bevat de attributen met de persoonsgegevens. De waarde in het attribuut uid moet gelijk zijn aan de waarde in het element <NameID>.
<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>



Stap 9: Entree Federatie filtert de attributen en versleutelt het uid

Saml step 09.png


Voordat de gegevens worden doorgestuurd naar de Service Provider worden er nog een aantal bewerkingen en controles door Entree Federatie uitgevoerd:

  • De waarde in het attribuut employeeNumber en het gedeelte voor de @ in het attribuut uid worden samengevoegd en versleuteld. De realm uit het uid (in dit geval @petteflatcollege) wordt daar vervolgens weer aan toegevoegd. Dit is het uniek ID waaraan Service Providers de gebruiker herkennen.
  • Er wordt gecontroleerd of er binnen de applicatie van Entree Federatie aan de Identity Provider een school gekoppeld is met een BRIN nummer dat overeenkomt met de waarde in het nlEduPersonHomeOrganizationId attribuut.
  • Er wordt bepaald voor welke attributen de school toestemming heeft gegeven om door te geven aan de Service Provider.
  • De blacklist wordt geraadpleegd om vast te stellen of gebruikers van de school toegang tot de dienst hebben.
  • Als de gebruiker een geactiveerde digicode voor de Service Provider heeft dan wordt deze aan de attributenset toegevoegd.



Stap 10: Entree Federatie stuurt een antwoord naar de Service Provider

Saml step 10.png


Entree Federatie verstuurt nu het aangepaste SAML response bericht door naar de Service Provider. Dit bericht wordt gestuurd naar het endpoint dat in het element <AssertionConsumerService> in de metadata van de Service Provider staat.

In het voorbeeld wijkt dit bericht op een aantal punten af van de SAML response uit stap 8:

  • Aangezien de applicatie van Entree Federatie dit bericht naar de Service Provider verstuurt, bevat het element <Issuer> nu de waarde aselect.entree.kennisnet.nl.
  • Het element <NameID> en het attribuut uid bevatten nu de versleutelde waarde van de attributen uid en employeeNumber.
  • Het attribuut employeeNumber wordt nooit doorgestuurd naar een Service Provider en is uit het SAML response bericht gefilterd.
  • In het voorbeeld gaan we ervan uit dat de school geen toestemming heeft gegeven om het attribuut mail door te sturen naar deze Service Provider. Dit attribuut is dan ook verwijderd uit het SAML response bericht.
  • In dit voorbeeld heeft de gebruiker een geactiveerde digicode voor deze Service Provider en deze is als het attribuut DL_IDSP_Licentiecode2017 toegevoegd.
<Response>
   ...
   <Issuer>aselect.entree.kennisnet.nl</Issuer>
   <Status>
      <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
   </Status>
   ...
   <Assertion>
      <Subject>
         <NameID>3bf03m4ea2kfe457c6@petteflatcollege</NameID>
         ...
      </Subject>
      ...
      <AttributeStatement>
         <Attribute Name="uid">
            <AttributeValue>3bf03m4ea2kfe457c6@petteflatcollege</AttributeValue>
         </Attribute>
         <Attribute Name="givenName">
            <AttributeValue>Pietje</AttributeValue>
         </Attribute>
         <Attribute Name="nlEduPersonHomeOrganizationId">
            <AttributeValue>99ZZ03</AttributeValue>
         </Attribute>
         <Attribute Name="DL_IDSP_Licentiecode2017">
            <AttributeValue>1234-abcd-5678</AttributeValue>
         </Attribute>

         ...
      </AttributeStatement>
      ...
   </Assertion>
</Response>



Stap 11: De Service Provider autoriseert de gebruiker

Saml step 11.png


Het SAML response bericht dat de Service Provider van Entree Federatie ontvangt zal ook weer worden gevalideerd aan de hand van de waarde in het <Issuer> element en de metadata van Entree Federatie. De Service Provider kan nu op basis van de inhoud van de attributen bepalen of de gebruiker toegang krijgt tot de afgeschermde content. Enkeler voorbeelden hiervan zijn:

  • De Service Provider maakt gebruik van schoollicenties en autoriseert op basis van het BRIN-nummer (de waarde in het attribuut nlEduPersonHomeOrganizationId).
  • Individuele gebruikers hebben een licentie en krijgen toegang op basis van hun uid.
  • De Service Provider maakt gebruik van digicodes en bepaalt op basis van het bijbehorende attribuut of de gebruiker toegang krijgt.

Aangezien het afhandelen van de autorisatie bij de Service Provider ligt heeft die ook de controle over welke gegevens er gebruikt worden om te bepalen of een gebruiker toegang krijgt.