KNF:SAML-sp: verschil tussen versies
Regel 35: | Regel 35: | ||
===Aanvullende functionaliteit=== |
===Aanvullende functionaliteit=== |
||
+ | In bepaalde use cases kan een dienstaanbieder een aantal aanvullende functionaliteiten implementeren. Deze kunnen het authenticatieproces verbeteren en/of vereenvoudigen. |
||
− | Dienstaanbieders kunnen indien gewenst gebruik maken van een aantal |
||
====SSO query==== |
====SSO query==== |
||
Regel 41: | Regel 41: | ||
====Scoping==== |
====Scoping==== |
||
+ | |||
====Forced authentication==== |
====Forced authentication==== |
Versie van 8 jan 2018 14:54
![]() |
![]() |
Inleiding
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.
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.
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). Een technische beschrijving van het authenticatie proces door middel van het SAML 2.0 protocol staat beschreven op Hoe werkt Entree Federatie?
Aansluitproces
Voorbereiding
Voor het aansluiten op Entree Federatie is het belangrijk om de volgende punten te overwegen:
- Welke attributen (persoonsgegevens) heb ik nodig om een gebruiker te kunnen autoriseren?
- Welke software library ga ik gebruiken voor het implementeren van de SAML functionaliteit?
- Wil ik gebruik maken van aanvullende functionaliteit als: SSO query, scoping of forced authentication?
Attributenbeleid
Tijdens het authenticatieproces ontvangt de applicatie van de Service Provider persoonsgegevens van de gebruiker in de vorm van attributen. Dit heeft als doel het identificeren en autoriseren van de persoon die gebruik wil maken van jouw applicatie. Binnen Entree Federatie wordt onderscheid gemaakt tussen twee typen attributen:
- Standaard attributen: worden door alle Service Providers ontvangen
- Aanvullende attributen: worden alleen ontvangen na expliciete toestemming van de onderwijsinstelling
Een overzicht van de attributen is te vinden op de pagina Attributen overzicht voor Service Providers.
Per 25 mei 2018 is de Algemene verordening gegevensbescherming (AVG) van toepassing. Hiermee worden de privacyrechten van gebruikers versterkt en de verantwoordelijkheden van organisaties vergroot. Een belangrijk uitgangspunt binnen deze wetgeving is Privacy by default. Dit houdt in dat u technische en organisatorische maatregelen moet nemen om ervoor te zorgen dat u alléén persoonsgegevens verwerkt die noodzakelijk zijn voor het specifieke doel dat u wilt bereiken.
Gebruik dus alleen attributen die functioneel essentieel zijn voor de autorisatie van de gebruiker en de werking van de applicatie.
Software library
Voor het implementeren van authenticatie door middel van SAML 2.0 zijn verschillende software libraries beschikbaar. De keuze voor één van deze libraries is vooral afhankelijk van de gebruikte ontwikkeltaal en persoonlijke voorkeur. Voor een aantal veel gebruikte libraries staan handleidingen op deze wiki. Voor het aansluiten op Entree Federatie worden geen specifieke libraries voorgeschreven door Kennisnet. Het is dus aan de dienstaanbier / ontwikkelaar om hier een keuze in te maken.
Aanvullende functionaliteit
In bepaalde use cases kan een dienstaanbieder een aantal aanvullende functionaliteiten implementeren. Deze kunnen het authenticatieproces verbeteren en/of vereenvoudigen.
SSO query
Deze functie biedt de mogelijkheid om te controleren of een gebruiker direct ingelogd kan worden zonder het inlogscherm te tonen. Kijk voor meer informatie op: [KNF:Single_Sign_On_query SSO query]
Scoping
Forced authentication
Testen van de koppeling
Voor het testen van de koppeling kan gebruik gemaakt worden van de Referentie Identity Provider van Entree Federatie. Met behulp van deze applicatie wordt het inloggen van een gebruiker via bijvoorbeeld een Elektronische Leeromgeving gesimuleerd. Het testscenario staat beschreven op: Service provider koppeling testen.
Overeenkomst
Nadat de koppeling op staging geconfigureerd en succesvol getest is, wordt er een overeenkomst afgesloten tussen de dienstaanbieder en Entree Federatie. Kennisnet zal hiervoor contact opnemen met de administratief contactpersoon van de dienstaanbieder.
Staging en productie omgeving
De productie omgeving is alleen bedoeld voor productie omgevingen en is niet bedoeld voor test doeleinde.
De software van de staging omgeving is identiek aan de productie omgeving en kan gebruikt worden voor ontwikkelpartijen om tegen te testen.
Implementatie voorbereiding
- Bepaal hoe je wilt koppelen met Entree Federatie, op de wiki staan meerdere standaard pakketten die gebruikt kunnen worden.
- Na het installeren en configureren van de software, stuur je de metadata url van de omgeving naar Kennisnet.
- Kennisnet maakt in eerste instantie een koppeling met de staging omgeving.
- Maak een test project waarmee je een authenticatie verzoek naar Entree Federatie kunt sturen.
- Implementeer authenticatie in de software van de dienst.
- Test of het authentiseren werkt, hiervoor kun je gebruik maken van de Referentie diensten
SAML support
Een korte uitleg over het SAML protocol kun je hier vinden: https://blog.surf.nl/en/saml-for-dummies/
Op deze website kun je verschillende SAML tools en ondersteuning vinden: https://www.samltool.com/online_tools.php
Een overzicht van standaard pakketten om te koppelen kun je hier vinden: http://developers.wiki.kennisnet.nl/index.php?title=KNF:Hoofdpagina
Een volledige uitleg van het SAML protocol kun je hier vinden: http://docs.oasis-open.org/security/saml/v2.0/
Koppelen met Entree Federatie
Metadata URL's
De metadata van Entree Federatie bevat zowel SP als IdP metadata.
of https://aselect.entree.kennisnet.nl/openaselect/profiles/saml2/
of https://aselect-s.entree.kennisnet.nl/openaselect/profiles/saml2/
Protocol & bindings
Entree Federatie ondersteund de volgende bindings:
- HTTP-Redirect, HTTP-Artifact and HTTP-POST for all incoming messages,
- HTTP-Redirect and HTTP-POST for outgoing messages.
Entree Federatie stuurt alleen <AuthnRequest>’s naar IdP's. Er worden geen andere SAML requests verstuurd. Daarom bevat het antwoord een <AuthnStatement> en een <AttributeStatement>, als de authenticatie succesvol is.
Name ID Format
De Name ID (Name ID in de <AuthnStatement>) die Entree Federatie heeft de volgende eigenschappen:
- De waarde is als volgt opgebouwd (username)@(realm). De Name ID heeft hetzelfde formaat als een e-mailadres, maar is het niet.
- De waarde voor de realm is uniek binnen Entree Federatie en bevat bij voorkeur een schooldomein.
- Het SAML2 Name ID format is urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
De Name ID die Entree Federatie ontvangt van de IdP is niet gelijk aan de Name ID die wordt doorgestuurd naar de SP's:
- Entree Federatie genereert een uid door het versleutelen van de (username) en het (empoyeenumber) gevolgd door de @realm.
- Door het versleutelen is de originele Name ID die door de IdP is aangeleverd niet meer zichtbaar voor andere partijen, zodat de privacy van de gebruikers is gewaarborgd. De realm blijft wel zichtbaar.
- De uid is en blijft uniek binnen de hele Federatie voor alle partijen. De uid verwijst altijd naar dezelfde gebruiker ongeacht datum/tijd waarop het ID is gebruikt.
Gegevens van de gebruiker
Standaard stuurt Entree Federatie alleen de standaard set attributen naar de dienst. Deze attributen bevatten geen privacy gevoelige informatie over de gebruiker. Een overzicht van de attributen kun je hier vinden: http://developers.wiki.kennisnet.nl/index.php?title=KNF:Attributen_overzicht_voor_Service_Providers
Indien je als dienst meer informatie nodig hebt van een gebruiker, bijvoorbeeld voor autorisatie, dan kan de school hier schriftelijk toestemming voor geven met een ARP (Attribute Release Policy) formulier. Hiervoor hebben we templates die je kan gebruiken als dienst.
Federatieve accounts & Entree Accounts
Entree Federatie heeft 2 soorten accounts, federatieve accounts van alle aangesloten IdP's ook wel schoolaccounts genoemd. Daarnaast heeft Kennisnet een eigen IdP Entree Account, waar gebruikers zelf een individueel account kunnen aanmaken.
Het belangrijkste verschil tussen deze accounts is dat Federatieve accounts daadwerkelijk van een school komen en ook alle attributen bevatten en Entree Accounts niet gekoppeld zijn aan een school en de waardes voor de attributen eduPersonAffiliation, nlEduPersonHomeOrganization en nlEduPersonHomeOrganizationId en standaard waarde bevatten.