Uitleg werking Entree voor dienstleveranciers

Transcriptie

1 Uitleg werking Entree voor dienstleveranciers Authenticatie en autorisatie platform van Stichting Kennisnet Auteur(s) : P. Bruring Versienummer : november Kennisnet.nl

2 Inhoud 1 Inleiding 1 2 Authenticatie en autorisatie: Single Sign On Authenticatie en autorisatie scenario s A Select filter en agent Specificatie van applicatieticket attributen Federatieve Eduperson attributen Kennisnet Attribute Release Policy (ARP) 7 3 Uitleg over het gebruik van digicodes Wat kan ik met een digicode? Hoe ziet een digicode eruit? Hoe kan ik digicodes aanmaken? Toegangsbewijsprofiel: Digicode attributen aanmaken Instellen aantal digicode activaties Digicode attrbuten: Koppelcodes Hoe gebruik ik de Entree Digicode beheer omgeving? Hoe kan ik digicodes distribueren? Hoe kan een gebruiker een digicode toevoegen? 17 4 Uitgewerkte voorbeelden autorisatieregels Autorisatie op basis van toegangsbewijsattributen Identificatie op basis van koppelwaarden Voorbeeld van uitlezen van attributen 21 5 Praktische informatie 24 6 Appendix A: Entree federatie Eduperson attributen 25 7 Appendix B: Entree 1.x legacy attributen Autorisatie op basis van lidmaatschappen Autorisatie op basis van lidmaatschappen én toegangsbewijzen 28

3 1 Inleiding Dit document is bedoeld voor partijen die van plan zijn gebruik te maken van Entree authenticatie voor hun webdienst. Hiermee kunnen gebruikers afkomstig van de Entree federatie inloggen met hun eigen account op de aan te sluiten dienst. Entree zorgt er ook voor dan men maar één inlogmoment heeft (per browsersessie). Kortom, gebruikers hoeven nadat ze eenmaal ingelogd zijn niet meer hun inlognaam en wachtwoord in te vullen. Dit principe heet Single Sign On. Dit document is geschreven voor techneuten, dus degene die Entree daadwerkelijk moeten integreren in de webdienst. Het legt welke aanpassing er nodig is om een Entree inlogscherm te tonen en hoe men gebruikers kan herkennen en toegang kan verlenen (autoriseren). Maar het dient ook als achtergrond document dat de globale werking van Entree authenticatie en autorisatie met behulp van Entree uitlegt. Pagina 1

4 2 Authenticatie en autorisatie: Single Sign On Entree is de authenticatie- en autorisatiedienst van Kennisnet. Hiermee kunnen personen die gerelateerd zijn aan het onderwijs met één inlognaam en wachtwoord inloggen op afgeschermde content van verschillende dienstleveranciers. Binnen één internetsessie hoeft maar één keer te worden ingelogd, ook al wordt naar verschillende sites gesurft. Dit principe heet Single Sign On. Sinds versie 2.0 (najaar 2008) kan Entree koppelingen leggen met accounts die buiten Entree worden geadministreerd. De inlognamen, wachtwoorden en bijbehorende gebruikersattributen worden dan beheerd door scholen. Er kan een technische koppeling gemaakt worden met een portal of elektronische leeromgeving, zodat een daar ingelogde gebruiker ook direct gebruik kan maken van diensten die via Entree beschikbaar zijn. Door het leggen van deze koppelingen bouwt Kennisnet een zogenaamde federatie. Deze Entree federatie is in feite een verzameling van onderwijs identiteitsverstrekkers en diensten die direct via Entree aan elkaar gekoppeld zijn. Uiteraard is het ook mogelijk dat gebruikers zelf een Entree account aanmaken voor bijvoorbeeld meer persoonlijke doeleinden. De aanvraag en het beheer van deze Entree accounts gebeurt dan door de gebruikers zelf. Onderstaand diagram geeft aan wat de relatie is van Entree (in het paars aangegeven) met zijn directe omgeving. Entree is een schakelpunt tussen leveranciers van gebruikers (Identity Providers, afgekort als IdP s) en internet diensten voor het onderwijs die vereisen dat men inlogd. Aan een Entree- of federatieve account kan door middel van activering van digicodes het account worden voorzien van kenmerken (toegangbewijzen, identificatie eigenschappen). Deze digicodes zijn afkomstig van dienstleveranciers voor het verlenen van toegang. Entree is ontwikkeld in samenwerking met SURFnet en maakt als onderliggende techniek gebruik van A-Select, dat volledig is gebaseerd op open source software. A-Select geldt als standaard in het onderwijs en bij de overheid (DigiD) en biedt vele mogelijkheden voor verdere ontwikkeling en aansluiting bij andere (internationale) initiatieven. De mogelijkheden van Entree zullen de komende jaren dan ook steeds verder toenemen. Pagina 2

5 2.1 Authenticatie en autorisatie scenario s De volgende scenario s leggen de werking van Entree uit vanuit de optiek van de gebruiker. Het proces van inloggen tot daadwerkelijk toegang krijgen tot de afgeschermde pagina s wordt geschetst. Scenario 1: gebruiker logt in op middels Entree afgeschermde content Opmerkingen: Het startpunt van het model is in het rood aangegeven. Op de webserver van de dienstleverancier staan twee onderdelen : de A-Select componenten (bestaande uit de A-Select agent en filter) en de afgeschermde content. Dit scenario is een simplistische weergave, in de volgende scenarios wordt dieper ingegaan op het applicatieticket uitgave proces. Dit is van belang voor de autorisatie van de gebruiker. De stappen: 1. De gebruiker gaat met behulp van zijn internet browser naar de met Entree afgeschermde website. 2. De A-Select filter bepaalt welke URL (directory) is afgeschermd, vervolgens gaat de agent zijn werk doen. De A-Select agent handelt de communicatie af met het Entree platform en redirect de gebruiker naar de centrale Entree A-Select server. 3. De Entree A-Select server geeft de gebruiker een Where are you from? scherm. Dit is een scherm waar de gebruiker zijn organisatie (school) kan kiezen zodat hij/zij met zijn eigen (school)account kan inloggen. Ook is het mogelijk dat men kiest voor zijn/haar Entree account. 4. De gebruiker kiest zijn organisatie in het Entree Where are you from? scherm. 5. Entree redirect de gebruiker naar de identeits verstrekker zodat de gebruiker zich daar kan authenticeren. 6. De gebruiker voert zijn inlognaam en zijn wachtwoord in. 7. De identiteitsverstrekker authenticeert de gebruiker op basis van de ingevoerde inlognaam en wachtwoord (d.w.z. controleert of deze persoon in bij deze organisatie bekend is) en geeft aan Entree de gebruikersattributen door. 8. Indien de gebruiker geauthenticeerd is, plaatst Entree een sessie cookie in de browsersessie van de gebruiker. Dit sessie cookie bestaat uit een ticket granting ticket (TGT) dat als Single Sign On bewijs dient. Het TGT zorgt er voor dat gebruikers zich binnen een browsersessie slechts éénmaal hoeven te authenticeren. Pagina 3

6 9. Entree levert aan de A-Select agent een gefilterde set van gebruikersattributen ivm pricacy wetgeving en/of andere afspraken. 10. De A-Select agent zet bij de gebruiker een applicatieticket met de verkregen attributen er in op het domein van de webserver van de dienstleverancier. Hier kan de gebruiker aan herkend worden, ook bij een vervolg bezoek (binnen dezelfde browsersessie) 11. De A-Select agent kan optioneel autoriseren op basis van de attributen in het applicatieticket (dit wordt in nader detail behandeld in de volgende scenario s). Hierna redirect de agent de gebruiker naar de afgeschermde content. 12. De gebruiker heeft toegang tot de afgeschermde content. Het volgende scenario laat zien hoe het single sign on principe van Entree werkt. Het gaat ook dieper in op het applicatieticket. Scenario 2: gebruiker logt in op met Entree afgeschermde content, nadat hij elders al met Entree heeft ingelogd De stappen: 1. De gebruiker gaat met behulp van zijn internet browser naar de met Entree afgeschermde website nadat hij elders al met Entree heeft ingelogd. 2. De filter merkt op dat er een gebruiker naar een afgeschermde pagina wil en roept de agent aan. Deze merkt dat er een geldig TGT aanwezig is, maar nog geen applicatieticket. De benodigde gegevens hiervoor worden opgevraagd bij Entree. 3. Entree geeft aan de betreffende dienstleverancier volgens de Kennisnet Attribute Release Policy (ARP) attributen door. 4. De agent plaatst het applicatieticket in het sessie cookie bij de gebruiker. Het applicatieticket kan zijn eigen geldigheidsduur hebben onafhankelijk van het TGT. 5. Op basis van de attributen in het applicatieticket en de voor de A-Select geconfigureerde autorisatieregels, controleert de agent of de gebruiker de juiste kenmerken heeft om door te mogen (zie paragraaf 2.2 op pagina 6). Indien dit het geval is, redirect de agent de gebruiker naar de afgeschermde content. 6. De gebruiker heeft toegang tot de afgeschermde content. Opmerkingen: Als de gebruiker zijn browser sluit en weer een nieuwe opent, gaat het sessie cookie met de Ticket Granting Ticket verloren en moet de gebruiker opnieuw inloggen. De Ticket Granting Ticket is ook maar voor een bepaalde periode na de laatste authenticatie geldig (8 uur). De levensduur van het applicatieticket is apart in te stellen, afhankelijk van het beveiligingsbeleid van de afgeschermde dienst. Scenario 3: Authenticatie met Entree, autorisatie op basis van applicatieticket attributen Pagina 4

7 Soms is het wenselijk dat er binnen de webapplicatie van de dienst wordt geautoriseerd, dus niet via een autorisatiebeslissing in de agent. Voorbeelden hiervan zijn: Websites waar men extra gegevens van de gebruiker bijhoudt. Websites waar het Entree account wordt gekoppeld aan een eigen gebruikers account van de dienstleverancier. De startconditie van dit scenario is dat de gebruiker zich inmiddels succesvol via Entree heeft geauthenticeerd, waarna de gebruiker een Ticket Granting Ticket van Entree heeft gekregen. Gebruiker 1. Vraag applicatieticket op A-Select agent & filter 5. (Dynamische) content 2. Applicatieticket Webapplicatie 4. Toegangsregel 3. Applicatieticket attributen: - profiel gegegevens - lidmaatschappen - toegangsbewijzen Gebruikers / autorisatie database Webserver dienstleverancier De stappen: 1. Door code in de webapplicatie wordt het Entree A-Select applicatieticket uit het sessie cookie van de gebruiker opgevraagd. 2. Dit applicatieticket wordt uitgelezen door code in de webapplicatie. 3. De webapplicatie haalt de attributen uit het applicatieticket en vraagt hiermee aan de gebruikers/autorisatie database de toegangsregel voor de gebruiker op. 4. De gebruikers/autorisatie database van de dienstleverancier geeft een toegangsregel terug. 5. De webapplicatie geeft de gebruiker toegang tot zijn (persoonlijke) pagina op basis van de gevonden toegangsregel. Pagina 5

8 2.2 A-Select filter en agent In onderstaand plaatje zijn de A-Select componenten geschetst en hun onderlinge relatie: Figuur 1: A-Select filter en agent Om Entree authenticatie en autorisatie uit te voeren, moet een A-Select webagent geïnstalleerd worden die met Entree communiceert. Deze software werkt op de volgende webservers: Microsoft IIS Apache 1.3.x en 2.x De A-Select agent, die bij de webdienst draait, zet na het eerste bezoek van een gebruiker een aantal cookies. De dienst is dan in staat de gebruikersattributen van de inlogde gebruiker uit te lezen. De belangrijkste cookie hierbij is de applicatieticket, het cookie met de naam: aselectattributes. Deze cookie bevat gebruikersattributen in de vorm van URL encoded naam en waarde paren. In de configuratie van de A-Select agent (agent.xml) kan men autorisatieregels in voeren in de vorm van specifieke attribuut naam-waarde paren per afgeschermde resource. Met resource wordt de in de A-Select filter ingestelde URL bedoeld. Vanaf deze URL wordt er een inlogscherm getoond. Dus bij deeplinking krijgen gebruikers ook te maken met Entree authenticatie. N.B.: De autorisatieregels in de A-Select agent zijn hoofdletter gevoelig! 2.3 Specificatie van applicatieticket attributen De webapplicaties die gebruik maken van een A-Select agent en filter kunnen gebruikers herkennen, autoriseren, maar ook persoonlijke content aanbieden. Dit wordt gedaan op basis van de gebruikers attributen in het applicatieticket. In de volgende paragrafen wordt er dieper op deze attributen ingegaan. De gebruikersattributen zijn, in de vorm van HTTP header variabelen, die in het Entree A-Select applicatieticket kunnen zitten. Pagina 6

9 2.3.1 Federatieve Eduperson attributen Sinds Entree 2.0 kunnen gebruikers met non-entree accounts gebruik maken van Entree authenticatie. Deze accounts zijn afkomstig van partijen die gekoppeld zijn aan Entree, bijvoorbeeld elektronische leeromgevingen van scholen. Deze stellen zich dan op als identiteit verstrekker naar de Entree federatie en worden daarom Identity Provider (IdP) genoemd. Deze partijen beheren zelf gebruikeraccounts, inclusief de gebruikersgegevens. Entree delegeert dan de authenticatie naar deze partijen en fungeert als doorgeefluik van de digitale identiteit naar de dienstleveranciers. Attribuut Uniek kenmerk van gebruiker voornaam tussenvoegsels achternaam adres soort relatie BRIN instellingnaam (friendly) Inititialen Telefoonnummer privé Mobielnummer Thuis adres Veldnaam (EduPerson) Verplichte levering IdP Voorbeeld uid Ja givenname Ja Piet nledupersontussenvoegsels van sn Ja Pukkelen mail Ja edupersonaffiliation Ja [student employee staff] nledupersonhomeorganizationid ja 01AB nledupersonhomeorganization initials P. Petteflat college homephone mobile homepostaladdress Petteflat 121e 2518PP Zoetermeer Uiteraard worden de Entree 1.0 attributen met hun oude benamingen voor een nog nader te bepalen overgangsperiode ondersteund. De federatieve attributen en de legacy attributen worden in detail in Appendix A behandeld. Appendix B gaat dieper in op de legacy attributen Kennisnet Attribute Release Policy (ARP) Voor elke dienstleverancier spreekt Kennisnet af welke combinatie van attributen deze kan krijgen. Er moet dan rekening worden gehouden met de privacy wetgeving. De algemene spelregels hierbij zijn: 1. De identiteit van de gebruiker mag niet te achterhalen zijn op basis van de doorgegeven combinatie van attributen, dus geen: voornaam, achternaam en BRIN. Maar wel: voornaam en BRIN. 2. Minimal disclosure. Dit betekend dat er niet meer gegevens worden verstrekt over de gebruiker dan strikt noodzakelijk is voor het functioneren van de dienst, met in achthouding regel nummer 1. Pagina 7

10 De vastgelegde set van doorgegeven attributen voor een dienstleverancier heet de Attribute Release Policy (ARP). Hoe de doorgifte van attributen wordt bepaald is hieronder schematisch weergegeven: Conform contract IDP - Entree Conform contract SP - Entree Klant organisatie Attributen waar de IDP beschikking over heeft IDP (bediend meerdere Klantorganisaties) Attributen volgens Entree / Eduperson opmaak Federatie operator (Entree) Attribute filtering Per Service Provider Service Service Provider Service Provider Provider Alleen tijdelijke opslag gedurende inlogsessie gebruiker ivm performance Hier kan ivm profielvorming opslag van gegevens plaats vinden Klantorganisatie specifieke wijzigingen in attribuutdoorgave (per service provider, via Entree beheer omgeving) Contract KO SP (buiten Kennisnet om) Figuur 2: Doorgifte van gebruikersattributen via Entree Entree krijgt dus een set attributen van zijn elk van zijn achterliggende indentiteitsverstrekkens (IdP's). Elk van deze set bevat tenminste de standaard attributen set (zie Appendix A). Een Service Provider (SP), ofwel een dienstleverancier, krijgt vervolgens van Entree een gefilterde set van gebruikers attributen door zoals deze in een contract tussen Kennisnet en de leverancier is afgesproken. Deze filtering wordt gedaan vanwege privacy en de minimal disclosure principes. In het aansluiten van diensten wordt zoveel mogelijk gestuurd op het gebruiken van de standaard attributen. Echter in sommige gevallen vereisen dienstleveranciers voor de werking van hun webdiensten extra attributen. Bijvoorbeeld als een dienst specifieke groepen van gebruikers in een school moet herkennen. Deze moeten dienstleveranciers, buiten het contract met Kennisnet, vragen aan hun klanten (scholen) om deze extra attributen door te geven. Om dit met Entree voor elkaar te krijgen moet het een en ander eerst geregeld worden. Hieronder is een opsomming gemaakt van de noodzakelijke activiteiten: Activiteiten die een IdP (portal, elektronische leeromgeving) moet uitvoeren: De IdP van de school beschikt over het betreffende attribuut De IdP van de school geeft extra attribuut door aan Entree Bij Entree is het attribuut aangemeld zodat het doorgegeven kan worden Activiteiten die een klantorganisatie (school) moet uitvoeren: Pagina 8

11 De school heeft zich bij Kennisnet gemeld om toegang te krijgen tot hun Entree beheer omgeving. Hiertoe hebben ze van Kennisnet een KO-beheer digicode verkregen. De Entree beheerder bij de school heeft het verkregen KO-beheer digicode geactiveerd op zijn account. De Entree beheerder bij de school heeft via de Entree beheer omgeving ingesteld dat de betreffende dienst het extra attribuut door krijgt. Blacklisting / Whitelisting door dienstleveranciers Als dienstleverancier kun je met Entree ook centraal de toegang tot de afgeschermde website beheren op basis van het behoren tot een bepaalde lijst van scholen. De sleutel hiertoe is de BRIN die wordt doorgeven. Dit attribuut verteld Entree tot welke school of instelling deze behoort. Deze organisaties moeten dus in Entree worden geregistreerd als een IdP aansluit of uitbereidt. Een dienstleverancier kan in Entree instellen welke instellingen toegang hebben (whitelisting) of welke instellingen juist geen toegang hebben (blacklisting). Als men dat doet dan doet Entree hier twee dingen mee. Ten eerste toont het Entree Where are you from scherm alleen de keuze van de scholen die op de whitelist staan. Als gebruikers via single sign on bij de afschermde website komen dan zal Entree ze tegenhouden als ze niet op de whitelist (dus op de blacklist) staan. Een dienstleverancier krijgt tijdens de implementatie van Entree afscherming van Kennisnet een beheerdigicode. Dit geeft toegang tot de digicodebeheerder omgeving (digicodebeheer.kennisnet.nl) waar men naast het aanmaken van digicodes ook de black/whitelisting kan instellen. Blacklisting / Whitelisting door klantorganisaties Entree Klantorganisaties, dit zijn met name scholen die via elektronische leeromgevingen zijn aangesloten, kunnen de toegang van gebruikers van hun eigen instelling ook beinvloeden. Ze kunnen ervoor kiezen om hun achterban geen toegang te verlenen, ondanks het feit dat een dienstleverancier dit wel toestaat. Zoals eerder vermeld kunnen scholen de attribuutdoorgave aan afgeschermde websites aanpassen. Het is mogelijk dat scholen nog minder attributen willen doorgeven, ondanks het feit dat Kennisnet zich aan de privacy wetgeving houdt. In dat geval kan een school zelf bepalen van wat er wel en niet wordt doorgegeven. Echter de werking van de dienst kan dan niet meer gegarandeerd worden. Pagina 9

12 3 Uitleg over het gebruik van digicodes Gebruikers die met Entree kunnen inloggen kunnen extra toegang krijgen door het activeren van zogenaamde digicodes op hun account. Dit hoofdstuk gaat hier dieper op in. Dit hoofdstuk heeft dus alleen relevantie als de dienstleverancier van plan is om toegang te verlenen tot de website door het (fysiek) uitdelen van digicodes aan hun gebruikers. 3.1 Wat kan ik met een digicode? Met behulp van een digicode kunnen gebruikers met een Entree account de volgende zaken aan hun account toevoegen: Toegangsbewijzen Koppelcodes Lidmaatschappen (legacy) Voor een uitleg van de bovenste twee begrippen wordt verwezen naar paragraaf 3.3 op pagina 11. Lidmaatschappen worden beschreven in Appendix B: Entree 1.x legacy attributen op pagina 26. Hierbij moet worden opgemerkt dat dit om functionaliteit gaat dat dankzij federatieve authenticatie niet meer nodig is. Men zal dus vrijwel geen gebruikers tegen komen die deze lidmaatschappen bezitten. In onderstaand diagram is het model aangegeven hoe kenmerken van toegangsbewijzen en lidmaatschappen via digicodes aan gebruikers worden gegeven: Figuur 3: Entree model van kenmerkoverdracht aan accounts via digicodes Pagina 10

13 3.2 Hoe ziet een digicode eruit? Een digicode heeft een vaste opbouw: 3.3 Hoe kan ik digicodes aanmaken? Alleen de rol digicodebeheerder binnen Entree heeft toegang tot de digicode module waarmee digicodes kunnen worden aangemaakt. Bij de implementatie van een dienst kan een dienstleverancier bij Kennisnet aangeven of, en zo ja wie, er de rol van digicodebeheerder moeten krijgen. Beoogde digicodebeheerders maken eerst zelf via het internet een Entree account aan. Vervolgens ontvangen zij van Kennisnet een digicode die toegang geeft tot de digicode beheermodule. Na het toevoegen van de code (zie verderop) kan de digicodebeheerder starten met het aanmaken van toegangsbewijsprofielen en het genereren van digicodes Toegangsbewijsprofiel: Digicode attributen aanmaken Entree-dienstleveranciers, bijvoorbeeld uitgevers, ELO-leveranciers, CMS-leveranciers, etc., kunnen digicodes aanmaken waarmee een Entree-gebruiker toegang krijgt tot de applicatie(s) van die dienstleverancier. Een toegangsbewijs kan uit meerdere attributen bestaan. Daarom kennen wij ook een toegangsbewijsprofiel. Een voorbeeld: Een Entreebeheerder van Aanbieder 01 maakt de volgende attributen en attribuutwaarden aan: Attribuut naam Vak Toetsrol Etc. Attribuut waarden Natuurkunde Scheikunde Biologie Toets afnemen Toets geven Etc. Etc. Pagina 11

14 Vervolgens maakt de Entreebeheerder van dezelfde aanbieder voor dienst WebToets A het volgende profiel aan voor het toegangsbewijs (kan elke willekeurige combinatie zijn): Vak = Natuurkunde Toetsrol = Toets afnemen De Entree-beheerder genereert tenslotte een bulk van 500 digicodes. Deze codes worden bijvoorbeeld via vouchers gedistribueerd aan scholen die ze weer verspreiden in de klas. De aangemaakte attributen zijn voor een dienst zichtbaar in het applicatieticket van Entree en kunnen gebruikt worden voor autorisatie. Het formaat van een toegangsbewijs is: - DL_<DLcode>_<Autorisatieattribuut naam>=<autorisatieattribuut waarde> o <DLcode> bestaat uit 6 karakters, bijvoorbeeld AANB01 voor Aanbieder 01. Deze code wordt door Entree gebruikt als filterwaarde, zodat alleen de door de dienstleverancier uitgegeven attributen leesbaar zijn. o <Autorisatieattribuut naam> = Attribuut naam o <Autorisatieattribuut waarde> = specifieke waarde van het attribuut - Voorbeelden: o DL_AANB01_Vak=Natuurkunde o DL_AANB01_Toetsrol=Toets afnemen Er zijn oneindig veel varianten mogelijk, want de namen en de waarden die aan een toegangsbewijsattribuut worden toegekend bepaalt u zelf: Recht om te schrijven op dienst 1 & 2 (bijv. voor 1 jaar) Recht op een sneak preview (bijv. voor 30 dagen) Etc. N.B.: De autorisatieregels in de A-Select agent zijn hoofdletter gevoelig! Gebruikers kunnen met Entree meerdere toegangsbewijzen verkrijgen. Attributen van andere dienstleveranciers zijn uiteraard niet zichtbaar Instellen aantal digicode activaties Het is mogelijk om digicodes aan te maken die meer dan één keer te activeren zijn. Dit betekend dat meerdere gebruikers dezelfde digicode kunnen activeren en dus daaraan gerelateerde autorisatie gegevens krijgen. Men kan tijdens het aanmaken van digicodes instellen wat het maximaal aantal activaties is voor een digicode is. Nadat een digicode dit aantal keer is geactiveerd (op verschillende accounts) is de digicode verbruikt en kan niemand meer de digicode op zijn of haar account activeren. Dit kan handig zijn als er bijvoorbeeld klassikaal toegang moet worden verleend tot een webdienst. Want dan hoeft er maar één digicode door een docent verspeid te worden aan zijn klas. Ook verminderd het gebruik van digicodes die meerdere activaties hebben de distributielast. Echter men loopt wel een verhoogt risico op misbruik. Als een digicode 'uitlekt', dus buiten de beoogde groep mensen bekend wordt, dan kan het gebeuren dat mensen die buiten de doelgroep of licentievoorwaarden vallen toegang krijgen tot de webdienst. Hierdoor kunnen dan mensen die wel binnen de doelgroep vallen geen digicodes meer activeren omdat de digicode inmiddels niet meer te activeren is. Het maximaal aantal activaties is dan verbruikt. Om dit risico te managen is het aan te raden om goed na te denken over het maximaal aantal activaties dat men insteld. Via Entree is het mogelijk notificatie s in te stellen als digicodes een bepaald percentage van acticaties hebben bereikt. Entree stuurt dan automatisch een e-mai naar de dienstleverancier dan een digicode een grens percentage van activaties heeft bereikt. Pagina 12

15 Men kan dan besluiten contact op te nemen met de partij aan wie de digicode verspreid is om na te gaan of dit klopt Digicode attrbuten: Koppelcodes Een aparte variant van toegangsbewijzen zijn koppelcodes. Deze zijn wat betreft de technische specificatie identiek aan toegangsbewijzen (zie vorige paragraaf). Echter ze dienen een ander doel dan alleen toegangscontrole, namelijk identificatie van gebruikers aan de hand van een uniek en herkenbaar kenmerk in hun account. Sommige applicaties, bijvoorbeeld elektronische leeromgevingen (ELO s), willen gebruikers zodanig herkennen dat er een koppeling gelegd kan worden met gebruikers die al eerder in het systeem zijn ingevoerd. Aangezien Entree gebruikers zelf accounts aanmaken, zijn de namen die men opgeeft niet gecontroleerd en dus niet betrouwbaar. Men kan koppeldigicodes aanmaken door een bestand op te voeren die vele waarden (koppelcodes) bevat. Hierdoor worden er in tegenstelling met toegangsbewijzen digicodes aangemaakt die unieke attribuutwaarden vertegenwoordigen. Dit kan dus gebruikt worden om koppelingen te leggen. Een voorbeeld: Een Entreebeheerder van Aanbieder 01 maakt het volgende koppelattribuut en attribuutwaarden aan: Attribuut naam Attribuut waarden GebruikerID Etc. Hierdoor ontstaat de volgende tabel: GebruikerID Digicode AANBD1-12-R6W3B-Y73ED AANBD1-12-K8C3G-PW3L AANBD1-12-5MJJ2-U7T3H Etc. Etc. Deze tabel wordt vervolgens geïmporteerd in de applicatie. Docenten bekijken halen dan uit de applicatie de digicodes voor de leerlingen. De leerlingen hebben pas toegang tot de applicatie nadat ze de (koppel)digicodes hebben ingevoerd bij hun Entree account. De applicatie identificeert de Entree gebruikers aan de hand van hun GebruikerID. Pagina 13

16 3.4 Hoe gebruik ik de Entree Digicode beheer omgeving? Een dienstleverancier heeft toegang tot de Entree Digicode beheer omgeving (digicodebeheer.kennisnet.nl) als hij een digicodebeheer-digicode heeft geactiveerd op zijn account. Deze wordt tijdens de implementatie door Kennisnet verstrekt. Op deze omgeving kan men digicodes aanmaken. Accounts kunnen hiermee geüpgrade worden en specifieke, door de dienstleverancier zelf gedefinieerde attributen meekrijgen. De dienst kan gebruikers toegang doormiddel van het herkennen van deze attributen. Zie hoofdstuk 4 op pagina 18 over hoe deze attributen herkend kunnen worden. Aanmaken van toegangsbewijs attributen Nadat men is ingelogd op digicodebeheer.kennisnet.nl kan men de attributen aanmaken en beheren via de menuoptie Toegangsbewijsattributen beheren. Men begint met het definiëren van attributen door op Attribuut toevoegen te klikken. Op het volgende scherm afdruk wordt getoond hoe je een attribuut definieert. Eerst definieer je een attribuut naam (type), daarna de waarden die het kan hebben. Aanmaken van toegangsbewijsprofielen Nadat men attributen heeft gedefinieerd kan een toegangsprofiel worden aangemaakt. Een toegangsprofiel bestaat uit de attributen die via deze digicodes aan accounts worden gekoppeld, de termijn waarop deze attributen geldig zijn, maar ook informatie die de gebruiker in zijn Entree accountbeheer omgeving kan zien over zijn verkregen toegangsrecht. Pagina 14

17 Als men op de knop Profiel aanmaken drukt gaat men meteen door naar de menuoptie Actieve Profielen. Vanuit hier kunnen bulken van digicodes worden aangemaakt door een profiel te kiezen en op Digicodes aanmaken te klikken: Pagina 15

18 Voor het aanmaken van een bulk van digicodes moet men aangeven hoeveel digicodes men wil hebben en hoe vaak elke digicode te activeren is. Ook is aan te geven in welke periode een digicode geactiveerd mag worden: Nadat de digicodes zijn aangemaakt, kunnen deze in de vorm van een CSV-bestand worden gedownload: 3.5 Hoe kan ik digicodes distribueren? De dienstleverancier is zelf verantwoordelijk voor de verspreiding van de digicodes en de wijze waarop dit gebeurt. Diverse methoden kunnen gebruikt worden, zoals , post of SMS. De dienstleverancier kan er voor kiezen om de digicodes te verspreiden via een klantorganisatie, meestal een onderwijsinstelling, via een tussenpartij of direct aan de eindgebruikers. De technische en procedurele middelen die noodzakelijk zijn voor de gekozen wijze van distributie, zullen door de dienstleverancier zelf moeten worden gerealiseerd. Entree levert alleen het bronbestand met de gegenereerde bulk aan digicodes. Pagina 16

19 3.6 Hoe kan een gebruiker een digicode toevoegen? Via de Entree account beheer Selfservice module (mijnentree.kennisnet.nl) of direct via een verkorte URL digicode.kennisnet.nl kan een gebruiker die een digicode ontvangen heeft, deze toevoegen: Het digicode invoer veld is intelligent, als men in het eerste invul vakje de gehele digicode plakt dan wordt het meteen uitgesplitst en kan men daarna direct op de knop Activeren drukken. Nadat de digicode is toegevoegd, kan de gebruiker via Mijn toegangsrechten de verkregen toegangsbewijzen bekijken: Pagina 17

20 4 Uitgewerkte voorbeelden autorisatieregels Indien een dienst met Entree wordt afgeschermd, dan vindt de authenticatie ( is de persoon wie hij zegt dat hij is ) van gebruikers plaats op de Entree server van Kennisnet. Autorisatie ( mag hij toegang hebben tot de dienst ) van de gebruiker gebeurt daarentegen op de webserver van de dienstleverancier. De techniek van beide principes is eerder toegelicht in hoofdstuk 1. Autorisatie geschiedt op de webserver van de dienst door het opnemen van de juiste autorisatieregels in de configuratie van het A-Select agent. Autorisatieregels vormen als het ware de technische vertaling van het gedefinieerde toegangsbeleid. In de volgende paragrafen wordt een aantal voorbeelden gegeven om dit nader toe te lichten. 4.1 Autorisatie op basis van toegangsbewijsattributen Een autorisatie op basis van een toegangsbewijsattribuut is een zeer krachtig middel, aangezien de dienstleverancier zelf kan bepalen hoe het toegangsbewijsprofiel eruit ziet en ook zelf (als enige) via digicodes de toegangsbewijzen kan uitdelen. Om te beginnen wordt het voorbeeld herhaald dat eerder is gebruikt bij het autoriseren op basis van lidmaatschappen. Deze manier vindt de dienstleverancier te arbeidsintensief (bij iedere nieuwe school moet hij het configuratiebestand aanpassen) en dus besluit hij te gaan werken met autorisatie op basis van toegangsbewijzen. Voorbeeld 1: Aanbieder 01 biedt de dienst Webtoets B aan, waarvoor door scholen betaald moet worden. Hiervoor sluit Aanbieder 01 contracten af met scholen, waaronder ook het Sint Nicolaas College. Alle personen van die school hebben dan toegang tot deze dienst. De digicodebeheerder van de dienstleverancier maakt om te beginnen via de beheermodule van Entree een toegangsbewijsprofiel aan (zie 3.3. voor een toelichting). Het aangemaakte toegangsbewijsprofiel heeft de volgende kenmerken: Naam Waarde Opmerking Code AANB01 Deze informatie is voor Dienstleverancier Aanbieder 01 gebruikers zichtbaar in de Product naam Webtoets B Entree selfservice omgeving. Product Webtoets B versie januari 2008 omschrijving Product URL Geldigheidsduur t/m De onderstaande verkregen attributen zijn alleen in deze periode gekoppeld aan een Entree account. Attribuut 1 Dienstnaam Deze attributen komen bij de Attribuutwaarde 1 Webtoets B gebruiker in zijn applicatieticket te staan en zijn dus uitleesbaar door de dienst. Let op: alleen de Code en de Attributen worden gedurende de geldigheidsduur in het applicatieticket meegegeven en kunnen gebruikt worden om op te autoriseren via het instellen van het A-Select agent. De overige gegevens zijn alleen bedoeld voor de registratie in Entree en in een enkel geval ook de visuele presentatie in de verschillende Entree menu s. Pagina 18