Residentie.net. Functioneel ontwerp. Pim 2.0

Residentie.net Functioneel ontwerp Pim 2.0

Functionele specificatie Pim 2.0 Residentie.net

“Nu opgroeiende generaties zullen intensief gebruik maken van elektronische dienstverlening, zowel door de overheid als door het bedrijfsleven. Dit betekent dat over niet al te lange tijd een grote bevolkingsgroep klaar staat om op elektronische wijze met de overheid te communiceren en van de overheid verwacht en verlangt dat deze wijze van communiceren mogelijk is.” – Berenschot, april 2003.

Awake! The future is now! - onbekend.

Confidential

Page 2/35

25.05.2004


Versiebeheer Versie 19

Datum 6 april 2004

Auteur Leon Kuunders

Opmerking Werkversie. Volgt op versie 0.5 (fornet05). Bepaalt de uitgangsbasis voor het systeem. Inclusief de nieuwe ontwikkelingen voor 3P.

Distributie aan Martijn Hazelzet Henk Bos Arjan Otter André van der Ark Kenney Westerhof

19 ½

20 april 2004

Leon Kuunders

Verwerkt reacties op fornet19. To do’s uitgewerkt. UI voorbeelden opgenomen.

Martijn Hazelzet e.v.

20

28 april 2004

Leon Kuunders

Use cases uitgebreid. To-do lijsten aangevuld. Semantiek toegevoegd.

Martijn Hazelzet Henk Bos Arjan Otter André van der Ark Kenney Westerhof e.a.

21

28 mei 2004

Confidential

Laatste commentaar verwerkt

Page 3/35

25.05.2004


Index Versiebeheer........................................................ 3 Index............................................................... 4 Semantiek........................................................... 6 1. Inleiding................................................. 7 2. Waar gaat dat heen?....................................... 8 2.1 Ben ik bekend?............................................ 8 2.2 Wat te doen?.............................................. 8 2.3 Vragen stellen, antwoorden krijgen........................ 9 3. Voor wie ben ik?......................................... 11 3.1 Onderwijs................................................ 11 3.1.1 Functionaliteiten........................................ 11 3.1.1.1 Beheer Residentie.net.................................... 11 3.1.1.2 Portaal.................................................. 11 3.1.1.3 Producten................................................ 11 3.2 Ondernemers.............................................. 12 3.2.1 Functionaliteiten........................................ 13 3.3 Overigen................................................. 13 4. Persoonlijke Informatie Manager.......................... 14 4.1 Aanleiding “de Digitale Kluis”........................... 14 4.1.1 Vastgeklonken............................................ 14 4.1.2 Kluizenaar............................................... 15 4.2 De “digitale postduif”................................... 15 4.3 De impasse ten hele gekeerd.............................. 16 4.4 Ja ik wil!............................................... 17 4.5 Resumé: Iedereen is hetzelfde............................ 19 5. Architectuur 3P.......................................... 20 5.1 Algemeen................................................. 20 5.2 Zoals het was .. 3P versie 1.0........................... 20 5.3 Zoals het wordt .. 3P/Pim versie 2.0..................... 21 5.3.1 Registreren als “Inwoner” bij de Gemeente Den Haag....... 21 5.3.2 Registreren als “Ondernemer” bij de Gemeente Den Haag.... 21 5.4 Relaties................................................. 22 5.4.1 De Dienst Invullen....................................... 22 5.4.2 De Dienst Afnemen........................................ 23 5.4.3 De Dienst Opmaken........................................ 24 5.4.4 Autorisaties: rollen en profielen........................ 25 6. Ontwerpen................................................ 26 6.1 Inleiding................................................ 26 6.2 Actielijst............................................... 26 6.2.1 Pim 2.0.................................................. 26 6.2.1.1 Acties ten behoeve van Pim 2.0........................... 26 6.2.2 Onderwijsportaal......................................... 27 6.2.2.1 Acties ten behoeve van portaal........................... 27 6.2.2.2 Acties ten behoeve van WebMail........................... 27 6.2.2.3 Acties ten behoeve van Fronter........................... 27 6.2.2.4 Acties ten behoeve van SiteBuilder....................... 27 6.2.3 Ondernemersportaal....................................... 27 6.2.3.1 Acties ten behoeve van portaal........................... 27 6.2.3.2 Acties ten behoeve van diensten en producten............. 27 BI. Database layout.......................................... 28 I.a “Live”................................................... 28 I.b Technisch Ontwerp........................................ 29 I.c SAML integratie.......................................... 30 I.d PIM20 integratie......................................... 30 BII. Pim User Interface....................................... 32 BIII. Van ontwerp naar techniek................................ 34 III.a Koppelingen tussen tabellen.............................. 34 III.b Vragen ten behoeve van permissies........................ 34

Confidential

Page 4/35

25.05.2004


III.c III.d

Confidential

Vragen voor toegang tot gebruikerstaken.................. 34 Vragen voor de interface................................. 34

Page 5/35

25.05.2004


Semantiek In dit hoofdstuk wordt ingegaan op de begrippen en definities die in het document worden gebruikt. [LK, nader uitwerken] Woord Rol DienstAanbieder DienstRol AutorisatieProfiel Pim Pied Pia 3P Produkt

Dienst Taak

DienstAfnemer SysteemRol GebruikersRol

Confidential

Omschrijving De functie van een gebruiker. Instelling die producten ter beschikking stelt. Een rol die een gebruiker bij een dienst kan hebben. Bevat een set van voorgedefinieerde permissies. Persoonlijke Informatie Manager, ook wel Profiel Informatie Manager Persoonlijke Informatie BEwerkingsDienst Persoonlijke Informatie Agent Kort voor Pim, Pied en Pia. “Voortbrengsel van de natuur, van arbeid of nijverheid, van kunst, van een chemisch proces”, aangeboden door de DienstAanbieder. “Instelling” die producten levert. “Werk dat iemand is opgelegd, arbeid die verricht moet worden”, nodig voor het afnemen van een product. Iemand die een product van een Dienst afneemt. Functies van gebruikers voor het systeem Residentie.net Functie van gebruikers bij een DienstAanbieder

Page 6/35

Gebruikt in

25.05.2004


1. Inleiding Een jaar geleden, in februari 2003, werd het Functioneel Ontwerp (FO) voor het gebruikersbeheersysteem van Residentie.net gepresenteerd. Dat functioneel ontwerp (met de werknaam fornet05) lag aan de basis van wat later 3P is genoemd. 3P, de naam is afgeleid van de 3 p’s van Pim, Pied en Pia, is een systeem waarbij gebruikers met een minimale set identificerende gegevens gebruik kunnen maken van diensten, aangeboden via (het domein) residentie.net. Een half jaar later, augustus 2003, werd de koppeling tussen Residentie.net en de diensten van de gemeente Den Haag beschreven in het document Single Sign On voor Residentie.net en Denhaag.nl. Dat document beschrijft de module die de koppeling met het Liberty Framework middels SAML, de Security Assertion Markup Language, mogelijk maakt. De diensten van de gemeente maken gebruik van het Liberty Framework voor het authenticeren van gebruikers en het koppelen van autorisaties. Dankzij SAML kan een Residentie.net gebruiker de diensten van denhaag.nl afnemen. Tijdens de ontwikkeling van 3P is afgeweken van het FO uit 2003. Met dit nieuwe FO worden deze wijzigingen verwerkt en als uitgangspunt genomen voor de nieuwe situatie. Wijzigingen op het entiteitendiagram zijn daartoe opgenomen in bijlage BI. Leeswijzer Het tweede hoofdstuk gaat in op de toekomst, wat gaat er gebeuren met Residentie.net en hoe wordt dit vertaald in functionaliteitswijzigingen? Het daaropvolgende hoofdstuk gaat in op een aantal use cases van klanten van Residentie.net. Hoofdstuk 4 gaat in detail in op Pim, de Persoonlijke Informatie Manager, en het onderdeel van 3P dat de meeste wijzigingen ondergaat. In hoofdstuk 5 wordt ingegaan op de architectuur van 3P en de relaties tussen de (oude en) nieuwe tabellen. Verder wordt in dit hoofdstuk een aantal handreikingen gegeven voor de ontwikkeling van de software. Hoofdstuk 6 geeft een overzicht van de verschillende fases uit de ontwikkeling van 3P en welk werk nog is te verrichten. Bijlage I geeft een overzicht van de huidige database structuur en de te verwachten wijzigingen. In bijlage II staan een aantal voorbeelden van de nieuwe Pim-interface.

De nummering van de documentatie is aangepast. Het voorliggende document is versie 19 (fornet19). Deze versie leidt tot versie 20 (fornet20), met als alias de naam Pim 2.0, voorziene publicatiedatum 28 april 2004.

Confidential

Page 7/35

25.05.2004


2. Waar gaat dat heen? In februari 2004 is de volgende fase voor 3P ingegaan. Er is gekeken naar de diensten die door de gemeente Den Haag worden aangeboden en naar de grotere rol voor Residentie.net bij het aanbieden van diensten voor ondernemers, scholieren en zorgafnemers. Persoonlijke diensten die zijn toegesneden op specifieke gebruikers.

2.1 Ben ik bekend? Wil men gebruik kunnen maken van persoonlijke diensten dan is het noodzakelijk dat een identiteit van de gebruiker bekend is. Pas als de dienstaanbieder die identiteit van de gebruiker kan koppelen aan een bekend profiel, kan er sprake zijn van gepersonificeerde diensten. Het vaststellen van identiteit gebeurt in een proces dat authenticeren wordt genoemd. Authenticatie betekent dat een gebruiker een geclaimde identiteit bevestigd. Bijvoorbeeld: bij het gebruik maken van een gebruikersnaam en wachtwoord staat de gebruikersnaam voor de “identiteit” en wordt met het wachtwoord de identiteit bevestigd, ofwel geauthenticeerd. Er bestaan diverse authenticatie-infrastructuren. Bijvoorbeeld het in de inleiding genoemde Liberty Framework. Dankzij de SAML koppeling is Residentie.net in staat diensten te ontsluiten die met het Liberty Framework zijn voorzien van een authenticatieprocedure, en diensten die de SAML koppeling ondersteunen. Residentie.net wordt gezien als de middleware die verschillende authenticatie-infrastructuren bij elkaar brengt. Residentie.net koppelt gebruikers aan profielen bij DienstAanbieders. Door Residentie.net’s opzet blijft anonimiteit gewaarborgd waar dat wenselijk is, kan kenbaarheid worden afgedwongen indien nodig en is het mogelijk niet kenbaar te blijven zonder verlies aan functionaliteit. 1) Residentie.net is een platform voor het publiceren van informatie over diensten en producten, van en door organisaties en gebruikers. Het legt de koppeling tussen burger en overheid en kan de communicatie met organisaties en overheid voor die burger, Hagenaar en Hagenees, beheren.

2.2 Wat te doen? Het huidige gebruikersbeheersysteem is begin 2004 geëvalueerd in het licht van de te verwachten ontwikkelingen. Uit dat onderzoek zijn de volgende conclusies getrokken: 1. De huidige interface van Pim, de Persoonlijke Informatie Manager, voldoet niet aan de wensen en wordt aangepast. 2. In Pim moet de gebruiker permissies uit kunnen delen door middel van AutorisatieRollen. 3. Via Pim moet de gebruiker producten af kunnen nemen en taken toebedeeld kunnen krijgen. 4. Via Pim moet de gebruiker taken kunnen afwerken.

1

Zie: Residentie.net 3.0 "functionele specificatie userbeheersysteem", d.d. februari 2003, pagina 8 e.v.

Confidential

Page 8/35

25.05.2004


5. De namen en parameters 2) voor bevragingen van de Pied database worden vastgelegd en gepubliceerd. 6. Resultaten van bevragingen worden als XML opgeleverd. Door gebruik te maken van XSL 3) kan een dienst de weergave van deze gegevens naar eigen inzicht aanpassen. De nieuwe interface voor Pim wordt weergegeven met behulp van XSLT, of XSLTC 4). De gegevens die voor de nieuwe interface van belang zijn worden in de database opgeslagen en na bevraging opgeleverd in XML formaat. De namen en parameters voor bevragingen van Pied door DienstAanbieders worden beschreven en vastgelegd. Hierdoor is het voor een DienstAanbieder mogelijk die gegevens uit de profielen van geabonneerde gebruikers te halen die voor hem van belang zijn. Overigens kan dit enkel nadat de gebruiker daarvoor toestemming heeft verleend. De Pim interface krijgt een aantal toevoegingen. Het afwerken van toegekende taken is daarvan een belangrijk onderdeel. Een taak wordt gebruikt voor het afnemen van een product en is bijvoorbeeld het online invullen van een formulier, het opsturen van een brief en het maken van een afspraak. Producten zijn gekoppeld aan een rol die de gebruiker bij een DienstAanbieder heeft. Die rol bepaalt dus het mogelijk productaanbod dat voor de gebruiker zichtbaar is. Taken zijn onderdeel van producten en verzorgen de feitelijke uitlevering van een product. De gebruiker kan derden toegang verlenen tot delen van Pim. Er is voorzien in vier verschillende autorisatieprofielen, namelijk “Eigenaar”, “Bewerker”, “Bekijker” en “Bekijker Speciaal”. Het toekennen van rollen gebeurt door de Eigenaar. DienstAanbieders geven bij het invoeren van taken aan welk autorisatieprofiel op desbetreffende taak van toepassing is. De DienstAanbieder bepaald welke rol zijn medewerkers hebben. Verder wordt de interface uitgebreid met een boomstructuur. De gebruiker kan in Pim de afgenomen producten en diensten wijzigen en rangschikken. Deze boomstructuur is vergelijkbaar met de interface zoals Microsoft’s Explorer (en andere bestandbrowsers) die gebruikt. Een voorbeeld van deze structuur is opgenomen in bijlage BII. Met het doorvoeren van bovenstaande wensen wordt de 3P infrastructuur generiek gemaakt, dat wil zeggen dat DienstAanbieders makkelijker gebruik kunnen maken van de architectuur van Residentie.net.

2.3 Vragen stellen, antwoorden krijgen De ingang die gekozen wordt voor Pim 2.0 is: - Ik wil gebruik maken van producten of diensten, en/of; - Ik lever producten of diensten. De communicatie met een dienstaanbieder wordt gestuurd doordat de gebruiker een vraag stelt, of een verzoek indient. “Ik wil een vraag stellen” verwijst dan naar generieke vragen over bijvoorbeeld het 2

Het formaat is www-urlencoded HTTP Post Extensible Stylesheet Language Family, zie http://www.w3.org/Style/XSL/ 4 XSL Transformations, zie http://www.w3.org/TR/xslt 3

Confidential

Page 9/35

25.05.2004


productaanbod van een DienstAanbieder. “Ik wil een verzoek indienen” verwijst naar concrete acties met betrekking tot een product. Door het opnemen van beslisbomen in de gebruikersinterface wordt de gebruiker gestuurd bij het afnemen van een product. Daarmee kan de gebruiker een inschatting maken van de tijd die nodig is voor het verkrijgen van een product.

Confidential

Page 10/35

25.05.2004


3. Voor wie ben ik? De functionaliteiten die aan Residentie.net worden toegevoegd middels Pim 2.0 volgen op de navolgende ontwikkelingen, waarin Residentie.net een rol speelt of gaat spelen. In dit hoofdstuk worden een aantal use cases behandeld. De functionaliteitbeschrijvingen vallen uiteen in een gedeelte voor Residentie.net (Hoe wordt het beheer op het portaal geregeld?) en een productspecifiek gedeelte.

3.1 Onderwijs Het Onderwijsportaal biedt leerlingen van haagse scholen mogelijkheden op het gebied van digitaal leren. Naast specifieke toepassingen zoals Fronter wordt ook webmail aangeboden.

3.1.1 Functionaliteiten 3.1.1.1 Beheer Residentie.net In het Onderwijsportaal moet het voor de Eigenaar mogelijk zijn één, of meerdere, Beheerders aan te wijzen. Verder moet het mogelijk zijn om één, of meerdere, Deelnemers aan te wijzen. Het portaal is toegankelijk voor iedereen (anonieme toegang). 3.1.1.2 Portaal Voor het Onderwijsportaal is voorzien dat de navolgende producten worden opgezet: een e-mail faciliteit (dit is een combinatie van Webmail en Pop/Imap ondersteuning), een e-learning faciliteit (hiervoor wordt gebruik gemaakt van de applicatie Fronter), een CMS toevoeging voor Fronter (voor het toevoegen van leerobjecten aan Fronter) en SiteBuilder (een click-and-publish systeem voor het bouwen van websites). Per product moet één Eigenaar worden aangewezen. Per product moeten één, of meerdere, Beheerders aan te wijzen zijn door de Eigenaar. Per product moeten één, of meerdere, Gebruikers (of Deelnemers) aan te wijzen zijn door de Beheerder(s) en/of Eigenaar. 3.1.1.3 Producten Voor WebMail is de volgende werking voorzien: -

-

-

ICT coördinatoren maken de accounts, inclusief e-mail adres en gebruikeridentificatie / wachtwoord, voor hun leerlingen aan via het WebMail-beheerders-scherm; o de leerling krijgt als e-mailadres: @ <school> . hop . nl; o dit e-mail adres is het primaire forward e-mail adres voor het Residentie.net account; de basisgegevens voor het Residentie.net account dat de leerling krijgt (nodig voor de overige diensten uit het Onderwijsportaal), worden tijdens dit proces verzameld en bestaan uit: e-mailadres, gebruikersnaam en wachtwoord, de gebruikersalias voor het afnemen van het product webmail wordt . <schoolnaam>; de leerling krijgt z’n e-mail accountgegevens per brief van z’n ICT coördinator; de “welkom” e-mail van Residentie.net wordt naar het emailadres van de leerling gestuurd;

Confidential

Page 11/35

25.05.2004


-

de accountgegevens voor Residentie.net zijn automatisch aangemaakt en voor de leerling geactiveerd; de leerling neemt via z’n Residentie.net account de overige diensten uit het Onderwijsportaal af.

Onderstaande afbeelding geeft deze werkwijze schematisch weer.

Het aanmaken van een e-mailaccount gebeurt met de administratie module van WebMail. WebMail maakt gebruik van een wachtwoord generator voor nieuwe accounts.

3.2 Ondernemers Administratieve Lasten zijn een bron van ergernis voor ondernemers. Volgens gegevens van het kabinet bedragen de administratieve lasten voor ondernemers € 17,1 miljard. De helft van deze kostenpost komt door regels die de EU heeft opgelegd. De andere helft door Nederlandse regelgeving. Administratieve lasten zijn de kosten voor het bedrijfsleven om te voldoen aan informatieverplichtingen voortvloeiend uit weten regelgeving van de overheid. Het gaat om het verzamelen, bewerken, registreren, bewaren en ter beschikking stellen van informatie. 5) Administratieve lasten: inspanningen die moeten worden geleverd door burgers en bedrijven om te voldoen aan administratieve verplichtingen die hen door de overheid worden opgelegd. 6) Pim 2.0, als dienst van Residentie.net en onderdeel van het Ondernemersportaal, verlaagt de inspanningen voor ondernemers bij het voldoen aan administratieve verplichtingen die hen door de overheid zijn opgelegd. Niet door de vraag te verkleinen, maar door het aanleveren te automatiseren. Voor een ondernemer is Pim de dossierkast. De dossierkast bevat voor de ondernemer alle ondernemingen; de laden gesorteerd, dossiers met labels gemerkt. Verzoeken en reacties, alsmede vragen van algemenere soort zijn logisch gerangschikt. Er is echter één verschil, in deze dossierkast zitten alleen de post-it briefjes waarop staat waar iets is opgeborgen. De feitelijke documenten uit de dossiers liggen bij de dossierhouders zelf, te weten aanbieder en afnemer. 5 6

Zie www.administratievelasten.nl Zie www.ictal.nl

Confidential

Page 12/35

25.05.2004


Pim is de index en weet waarom verzoeken zijn ingediend en documenten zijn opgeleverd. Pim vertelt daarbij ook wat het resultaat is van die actie. De gebruiker, als eigenaar, geeft aan welke gegevens worden overgedragen aan onderliggende documenten en dossiers. Een systeem waarmee subsets van gegevens (zoals contactgegevens) eenvoudig kunnen worden overgenomen op onderliggende formulieren levert voor de ondernemer gemak op. De inspanning voor het opleveren van informatie wordt daarmee verkleind, evenals de ergernis over het repeterend opleveren van gelijke gegevens.

3.2.1 Functionaliteiten In het Ondernemersportaal moet het voor de Eigenaar mogelijk zijn één, of meerdere, Beheerders aan te wijzen. Verder moet het mogelijk zijn om één, of meerdere, Deelnemers aan te wijzen. Dit betreft specifiek het beheer van het portaal, dus niet de via het portaal aangeboden producten. Het portaal is een product van de DienstAanbieder Residentie.net.

3.3 Overigen Er liggen meerdere portalen en producten in het verschiet. Te denken valt daarbij aan een Zorgportaal, waarmee toegang wordt verleend tot diverse ZorgVerleners en functionaliteit wordt geboden in de lijn met de ontwikkelingen rondom het electronisch patienten dossier. Dit soort functionaliteitwensen behoren nader uitgewerkt te worden.

Confidential

Page 13/35

25.05.2004


4. Persoonlijke Informatie Manager In dit hoofdstuk wordt ingegaan op Pim, de Persoonlijke Informatie Manager. In dit hoofdstuk wordt verwezen naar de functionaliteitseisen en wensen uit hoofdstuk 2.

4.1 Aanleiding “de Digitale Kluis” In het rapport “Werkbare vormen van digitale regie over eigen (persoons)gegevens door de burger”, wordt een advies gegeven over de wenselijkheid en haalbaarheid van (werkbare vormen van) een digitale kluis, als antwoord op het rapport van de commissie Snellen.” 7) De Digitale Kluis wordt als volgt omschreven: Middels de digitale kluis kan de overheid de burger namelijk inzicht geven in de over hem geregistreerde persoons(gerelateerde) gegevens en documenten (inzagerecht), kan de burger deze zonodig laten corrigeren (correctierecht) en kan de burger regie voeren over de verstrekking van deze gegevens aan geïnteresseerde organisaties met een niet-publieke taak.

De volgende functionaliteiten van een digitale kluis worden voorzien: 1. De burger inzicht bieden in de gegevens die door diverse overheidsorganisaties over hem zijn opgeslagen (inzagerecht); 2. De kwaliteit van die vastgelegde gegevens verhogen door de burger zelf wijzigingen te laten maken (correctierecht); 3. Persoonlijke gegevens hergebruiken in de elektronisch communicatie met burgers, overheid en bedrijfsleven (regierecht). Deze functionaliteiten vragen om een systeem waarin opslag van gegevens en mutaties op die vastgelegde gegevens mogelijk zijn. Verder moeten deze gegevens zodanig worden genormaliseerd dat subsets eenvoudig zijn te maken voor hergebruik.

4.1.1 Vastgeklonken De vraag dringt zich op of een dergelijk systeem in staat kán zijn de gewenste functionaliteiten te bieden. Ten eerste is het zo dat gemeenten en rijksoverheid gegevens van burgers en ondernemingen in diverse systemen en diverse formaten opslaan. Toegang tot deze systemen (zelfs via tussenoplossingen) zal niet, of slechts gedeeltelijk en zeer moeizaam, te realiseren zijn. Ten tweede is de overheid bij uitstek een dossiervormende organisatie. Overnemen van identieke wijzigingen in meerdere dossiers gebeurt door per dossier een dergelijke wijziging aan te geven. Ten derde is slechts een kleine subset aan persoons- en bedrijfsgegevens geschikt voor hergebruik. Het betreft dan ondermeer contact- en vestigingsgegevens. Vanuit het perspectief van de burger is het bestaan van meerdere sets van persoons- en bedrijfsgegevens bij de overheid niet bezwaarlijk. Naast het punt dat het sowieso niet mogelijk is het kopiëren van digitale informatie tegen te gaan (evenals dit geldt voor het 7

Berenschot, april 2003, zie http://www.elo.nl/elo/kennisbank/Documenten/index.jsp?cat=architectuur en “POP Periodiek Overzicht Persoonsgegevens”, Stratix, februari 2002 (www.stratix.nl).

Confidential

Page 14/35

25.05.2004


kopiëren van formulieren, documenten en andere brieven die door de burger naar de overheid worden gestuurd), is het met name de inspanning van de burger voor het opleveren van deze gegevens dat als belastend wordt ervaren.

4.1.2 Kluizenaar Een belangrijk aandachtspunt in de beschrijving van een digitale kluis is de toegangsbeveiliging. Immers, “het ontbreken van een adequate technisch en juridisch geregelde toegangsbeveiliging (dreigt) een bottleneck te worden in het doorontwikkelen van de elektronische dienstverlening.” 8) In het eerder aangehaalde rapport van Berenschot worden twee verschillende soorten gegevens onderscheiden, namelijk gegevens geauthentiseerd zijn en gegevens die niet-geauthentiseerd zijn. gebruiker van de digitale kluis voert het beheer over de nietgeauthentiseerde gegevens. Beheer van geauthentiseerde gegevens middels regel- en wetgeving vastgelegd en wordt uitgevoerd door overheid.

die De is de

De gegevens in de kluis zijn van persoonlijke aard. Vanuit deze gedachte bezien is beveiliging met bijvoorbeeld een smartcard minimaal noodzakelijk, wil de kluis op afdoende wijze beschermd zijn. Maar is die beveiliging dan ook werkelijk afdoende? En levert het centraal opslaan (en aanbieden!) van deze gegevens niet teveel risico op? De digitale kluis draagt het risico van een bomkoffer. Wordt de kluis gekraakt dan kunnen gegevens van duizenden gebruikers worden ontvreemd, een gevolg van de centrische gedachte en het opslaan van documenten.

4.2 De “digitale postduif” Met de digitale kluis wordt het principe van gecentraliseerde opslag gevolgd. Echter, gegevens uit deze kluis kunnen alleen dan worden bekeken als ze daadwerkelijk uit 9) de kluis worden gehaald. Op dat moment verliest de eigenaar de controle over deze gegevens. Een digitale kluis biedt daardoor slechts een schijnzekerheid. Om uit de toegangsbeveiligingimpasse te raken (steeds zwaardere beveiligingsmiddelen, nooit weten of het genoeg is) wordt voor Pim 2.0 een andere werking voorgesteld. Residentie.net heeft de ambitie met Pim 2.0 de burger een elektronisch loket te bieden dat aansluit bij de producten dienstleveringen van DienstAanbieders. Dit elektronisch loket heeft als werktitel: de digitale postduif 10). De digitale postduif verzorgt de communicatie tussen gebruiker en dienstaanbieder. De digitale postduif weet waar formulieren en documenten moet worden afgeleverd en is in staat de reactie daarop in het juiste postvak te stoppen.

8

Berenschot, april 2003, zie http://www.elo.nl/elo/kennisbank/Documenten/index.jsp?cat=architectuur. 9 Dit is inherent aan de natuur van het internet en daarop gebaseerde technieken. 10 Niet te verwarren met RFC 1149 “Avian Carriers” http://www.ietf.org/rfc/rfc1149.txt

Confidential

Page 15/35

25.05.2004


Pim 2.0 draagt de navolgende kenmerken (deze kenmerken zijn ook behandeld in hoofdstuk 2): -

De primaire doelstelling is “Het vastleggen en vereenvoudigen van de (communicatie-)relaties tussen gebruiker (natuurlijk persoon, niet natuurlijk persoon) en DienstAanbieder.” o In Pim 2.0 worden verwijzingen naar documenten en formulieren opgeslagen. o Pim 2.0 genereert hashes van ingestuurde documenten en verzorgt de communicatie met de DienstAanbieder. o In Pim 2.0 kunnen documenten en formulieren worden opgeslagen. o Toegang tot (gedeeltes van) het gebruikersprofiel kan worden verleend aan derden.

-

Pim 2.0 voorziet in een koppeling tussen een identiteit van de gebruiker en het gebruikersprofiel bij de DienstAanbieder.

-

Pim 2.0 voorziet in een koppeling tussen gebruikersrollen en producten van de DienstAanbieder.

-

Pim 2.0 voorziet in een koppeling tussen producten en taken.

-

Pim 2.0 voorziet in een volgmechanisme voor ingestuurde vragen, verzoeken, alsmede voor ingestuurde gegevens ten behoeve van de productafname.

-

Pim 2.0 voorziet in de mogelijkheid om ingestuurde documenten te versturen aan belanghebbenden.

-

Pim 2.0 maakt het mogelijk reacties op ingestuurde documenten te verwerken.

Niet het opslaan van documenten en gegevens wordt het uitgangspunt, maar het vastleggen en vereenvoudigen van de (communicatie-)relaties tussen dienstafnemer en dienstaanbieder. Pim is dus een archiefkast zonder inhoud. Door het vastleggen van relaties levert Pim overzicht en controle.

4.3 De impasse ten hele gekeerd Pim 2.0 biedt haar gebruikers de mogelijkheid documenten die nodig zijn voor het verkrijgen van een product, in te sturen. In dat proces wordt een document door de gebruiker naar de server verstuurd, alwaar van het document een digest of hash 11) wordt berekend. Het document, en de hash, wordt vervolgens doorgestuurd naar het e-mail adres dat de DienstAanbieder, voor het uitvoeren van de aan het product gekoppelde taak, heeft vastgelegd. De hash ondersteunt twee functies: de ontvanger van het document kan daaruit afleiden of het document tijdens transport is gewijzigd en afzender en ontvanger kunnen controleren of gebruikte documenten identiek zijn. Onweerlegbaarheid, onbetwijfeld aantonen dat een bericht door een specifieke identiteit is verstuurd, wordt niet ondersteund. Op deze wijze wordt het volgen van de communicatie met de DienstAanbieder mogelijk. Documenten en formulieren worden 11

Deze techniek is gelijk aan die voor het genereren van een digitale handtekening.

Confidential

Page 16/35

25.05.2004


automatisch ingestuurd naar een e-mail adres. Dit adres kan de DienstAanbieder per taak en/of product aangeven. De ondernemer hoeft dat adres niet te kennen, het is afhankelijk van de gegevens die de DienstAanbieder in het Residentie.net systeem heeft opgenomen. Een voorbeeld: Een Haagse horecaondernemer, laten we hem Harrie noemen, gebruikt Pim 2.0 voor het stroomlijnen van zijn communicatie met de gemeente. Voordat zijn café een terras mag plaatsen moet daarvoor een terrasvergunning worden aangevraagd. Die aanvraag loopt via Pim 2.0. Harrie legt een verbinding met Residentie.net en Pim 2.0. In Pim maakt hij zijn horecaonderneming “Café Olé” aan. Hij wijzigt de basisgegevens van het café, die automatisch uit zijn profiel zijn overgenomen, in de vestigingsgegevens van het café. Nadat dit is opgeslagen kiest hij voor de optie “Ik wil gebruik maken van producten of diensten” en vervolgens de DienstAanbieder “Gemeente Den Haag”. Harrie krijgt als Horecaondernemer vervolgens een lijst met producten te zien. Harrie kiest het product “Terrasvergunning”. Vervolgens wordt aan Harrie een taak toegekend, “Invullen van het aanvraagformulier voor een terrasvergunning”. In de taak staat onder meer naar welk e-mail adres dat formulier moet worden opgestuurd. Het aanvraagformulier haalt Harrie op vanaf de URL die in de taak staat. Nadat het document is ingevuld en opgeslagen (op Harrie’s eigen computer) maakt Harrie opnieuw verbinding met Residentie.net en Pim. In de takenlijst staat de aanvraag voor de terrasvergunning. Harrie opent de taak en kiest voor het “Insturen” van een document. Middels de “Browse” knop bladert Harrie naar het document op zijn computer en selecteert dit. Hij klikt op OK en het document wordt naar Residentie.net gestuurd. Als het document is ontvangen wordt er een hash waarde van gegenereerd. Vervolgens wordt het document, met de bijbehorende hash waarde, doorgestuurd naar het e-mail adres dat bij de taak hoort. Bij de taak wordt de volledige bestandsnaam opgeslagen van waar het document is ingestuurd. Verder wordt de gegenereerde hash waarde opgeslagen en wordt vastgelegd op welk moment het document is ingestuurd. Als Harrie in Pim het document aanklikt, wordt dit geopend vanaf zijn eigen computer. Harrie kan ter bescherming van zijn gegevens gebruik maken van cryptografische technieken. Hierdoor worden de gegevens op zijn computer beschermd, terwijl ze toch via de webinterface beschikbaar blijven.

Pim 2.0 kan, optioneel, documenten van de gebruiker opslaan. Toegang tot die documenten kan worden verleend aan derden.

4.4 Ja ik wil! Gebruikers van Residentie.net krijgen met Pim 2.0 een nieuwe manier voor het afnemen van (webgebaseerde) producten c.q. diensten. Maar ook het aanbieden daarvan wordt vereenvoudigd. Want een gebruiker is ook een aanbieder.

Confidential

Page 17/35

25.05.2004


Een voorbeeld: Harrie, de Haagse horecaondernemer, gebruikt Pim 2.0 voor het stroomlijnen van zijn communicatie met de gemeente. Nadat Harrie voor zijn café de benodigde vergunningen heeft aangevraagd wil hij aan Hagenaars en Hagenezen kenbaar maken dat het terras tijdens de zomermaanden geopend is. Harrie maakt een verbinding met Residentie.net en Pim en navigeert naar zijn café. Vervolgens kiest hij voor “Ik lever producten of diensten”. Het “producten of diensten aanbieden”-scherm wordt geopend. In dit scherm zijn de gegevens van het café overgenomen en staat een aanvinkvak waarmee hij bevestigt dat hij een publieke dienst gaat maken. Daarna geeft hij de naam van zijn product in (“Zonnig terras”), een omschrijving (“Elke halve dag bakken in de zon, van 11:00 tot 23:00”), en voor wie het product beschikbaar is (“Iedereen”). Standaard is de dienst voor iedere gebruiker van Residentie.net beschikbaar (anoniem). Harrie besluit die instelling te laten zoals die is en klikt op “Ok”. Het systeem vraagt hem of er taken aan het product moeten worden gekoppeld en biedt hem de mogelijkheid Taken toe te voegen. Omdat dit niet het geval is klikt Harrie op “Geen (of niet meer) taken”. Vervolgens wordt zijn product vastgelegd en gepubliceerd via de Publieke Producten Pagina.

Op het moment dat een gebruiker aangeeft dat hij producten en diensten aanbiedt, wordt aan de gebruiker de (Residentie.net) rol van DienstAanbieder toegekend. Met deze rol krijgt de gebruiker toegang tot het DienstAanbieder scherm van Pim. Middels dat scherm kan de gebruiker: -

Dienst gegevens muteren, inclusief Eigenaar en Bewerker(s). Wat voor dienst is het, wie is de eigenaar van deze dienst en door wie wordt deze dienst beheerd?

-

Producten aanmaken Wat voor producten heeft de DienstAanbieder?

-

Taken aanmaken Wat voor taken zijn nodig voor het verkrijgen van de producten van de DienstAanbieder?

-

Producten en taken koppelen Welke taken moeten voor een product worden uitgevoerd?

-

DienstRollen aanmaken Wat voor type gebruikers onderscheidt de DienstAanbieder?

-

DienstRollen en producten koppelen Welke producten zijn voor welke gebruikers beschikbaar?

-

Voorwaarden aan DienstRollen koppelen Wat zijn de voorwaarden waaraan een gebruiker moet voldoen wil deze een bepaalde DienstRol krijgen?

De gebruiker wordt automatisch eigenaar gemaakt van de dienst. Producten die worden aangeboden zijn zichtbaar voor gebruikers met de juiste rol. Afgenomen producten worden bekeken door medewerkers van de dienstaanbieder die het juiste AutorisatieProfiel hebben, evenzo de aan producten gekoppelde taken.

Confidential

Page 18/35

25.05.2004


4.5 Resumé: Iedereen is hetzelfde De navolgende twee figuren laten het verschil zien tussen DienstAanbieder en DienstAfnemer, vanuit het perspectief van Residentie.net.

Een DienstAanbieder maakt een onderscheid in gebruikers middels de Rollen die een gebruiker kan hebben. Productenafname wordt ondersteund middels beslisbomen. Producten en taken worden gecontroleerd door medewerkers met het juiste AutorisatieProfiel. Een DienstAfnemer heeft één, of meerdere, rollen bij één, of meerdere, dienstaanbieders. Voor het verkrijgen van producten voert de DienstAfnemer de aan het product gekoppelde taken uit. De DienstAfnemer kan toegang tot (gedeeltes van) het gebruikersprofiel verlenen aan derden. De volgende figuur laat zien hoe het systeem vanaf installatie wordt uitgebouwd: het eerste product, Pim, wordt beschikbaar gesteld, en krijgt een Afnemer. Deze Afnemer maakt producten aan en wordt een Aanbieder. De producten worden aangeboden via Pim.

Gebruikers melden zich aan via Pim en blijven gebruikers van Residentie.net, met specifieke kenmerken (Rollen) bij de diverse Aanbieders.

Confidential

Page 19/35

25.05.2004


5. Architectuur 3P [LK, dit hoofdstuk dient nader uitgewerkt te worden]

5.1 Algemeen [LK:...] Hiertoe maakt de DienstAanbieder gebruik van Pia om met Pied te communiceren. Schematisch ziet dat er als volgt uit:

Figuur 1: communicatie met Pied via Pia

Dit is in lijn met versie 1.0 van 3P, met dat verschil dat Pia als module wordt gebruikt door elke DienstAanbieder, waar het vorige ontwerp nog sprak over één Pia voor alle diensten.

5.2 Zoals het was .. 3P versie 1.0 In de eerste versie van 3P is voorzien in een mechanisme waarbij gebruikers middels het toekennen van een rol van een dienst gebruik kunnen nemen. Schematisch ziet dat proces er als volgt uit: Stap 1. 2.

Omschrijving Gebruiker registreert bij Residentie.net Gebruiker registreert bij dienst en kiest daarvoor de UserAlias.

Resultaat Geregistreerde gebruiker. Geregistreerde gebruiker met rol “/”

Tabel 1.

Doordat de gebruiker tijdens het aanmelden voor de dienst zelf kan kiezen voor de naam waaronder wordt aangemeld, is de privacy van de gebruiker gegarandeerd. Daarom een onderscheid gemaakt tussen gebruikers die Anoniem, Niet Kenbaar of Kenbaar zijn. 12) Aanmelden, of single sign on, tussen RNET en de diensten wordt bereikt door het koppelen van servicename en servicerolename aan het session-id van de gebruiker.

12

Zie: Residentie.net 3.0 "functionele specificatie userbeheersysteem", d.d. februari 2003, pagina 8 e.v.

Confidential

Page 20/35

25.05.2004


Dit heeft tot gevolg dat een gebruiker bij een aangesloten dienst slechts één rol kan hebben onder één UserAlias. Meerdere rollen zijn wel mogelijk, maar alleen onder een ander UserAlias. In dat geval is het voor de DienstAanbieder niet mogelijk één profiel aan desbetreffende User te koppelen. Omdat geen autorisaties worden uitgedeeld is dat niet bezwaarlijk.

5.3 Zoals het wordt .. 3P/Pim versie 2.0 Het nieuwe systeem voorziet in het uitdelen van permissies door gebruikers. Ook is het in het nieuwe systeem mogelijk dat van één DienstAanbieder meerdere diensten worden afgenomen. Deze diensten bestaan uit producten en daaraan gekoppelde taken. Verder kan een gebruiker bij een DienstAanbieder verschillende rollen hebben. Het productaanbod van de DienstAanbieder is gekoppeld aan één of meerdere rollen.

5.3.1 Registreren als “Inwoner” bij de Gemeente Den Haag Deze DienstAanbieder heeft een reeks aan producten voor diverse gebruikers, bijvoorbeeld burgers en ondernemers. Deze gebruikers hebben voor de DienstAanbieder dus een verschillende rol. Stap 1.

Omschrijving Gebruiker registreert bij DienstAanbieder “Gemeente Den Haag” met rol “Inwoner”.

Resultaat De gebruiker is met de rol “Inwoner” geregistreerd.

2.

DienstAanbieder biedt producten aan voor inwoners.

De gebruiker krijgt een overzicht van de producten die voor een “Inwoner” beschikbaar zijn.

3.

Gebruiker kiest voor een product uit de lijst voor “Inwoners”.

De gebruiker krijgt instructies omtrent het afnemen van het product via de TakenLijst.

4.

Gebruiker volgt de instructies uit de takenlijst op.

Afgenomen product.

5.3.2 Registreren als “Ondernemer” bij de Gemeente Den Haag De gebruiker uit het vorige voorbeeld heeft ook een onderneming in Den Haag. In de volgende stappen wordt die rol geregistreerd. Stap 1.

Omschrijving Gebruiker registreert bij DienstAanbieder “Gemeente Den Haag” met rol “Ondernemer”.

Resultaat De gebruiker is met de rol “Ondernemer” geregistreerd.

2.

De gebruiker maakt het type onderneming “Horeca” aan.

De gebruiker krijgt een overzicht van de producten die voor een horecaondernemer beschikbaar zijn.

3.

Gebruiker kiest voor een product uit de lijst voor “Horeca Ondernemers”.

De gebruiker krijgt instructies omtrent het afnemen van het product via de TakenLijst.

4.

Gebruiker volgt de instructies uit de takenlijst op.

De takenlijst wordt geverifieerd.

Confidential

Page 21/35

25.05.2004


5.4 Relaties In deze paragraaf worden een aantal schema’s gegeven die duidelijk maken hoe de functionaliteitwensen worden gerealiseerd. Enerzijds dankzij de nieuwe interface, anderzijds door gebruik te maken van de aanwezige architectuur.

5.4.1 De Dienst Invullen Er wordt een verschil gemaakt tussen Diensten en Producten. In het volgende schema staat aangegeven hoe de rollen, producten en taken van een Dienst worden vastgelegd. Een Dienst levert producten, maar levert de producten alleen aan gebruikers die daarvoor de juiste rol hebben bij de dienst. Deze rol is opgenomen in ServiceRoles. Producten worden gekoppeld aan de rol via ServiceRoleProduct. Om een product af te nemen moet een taak (of taken) worden afgewerkt. Deze worden vastgelegd in ServiceTasks. Omdat producten hun specifieke takenlijst kennen worden deze opgenomen in ServiceProductTask en aan een product gekoppeld. Middels een autorisatieprofiel wordt bepaald welke medewerker van de dienst inzage heeft in de uitgeleverde producten en toegewezen taken. Het betreft dan specifiek de rol van bekijker van informatie. Deze autorisatieprofielen staan in AuthorizationProfiles.

Schema 1; de relatie tussen DienstAanbieder, Producten, Taken en Rollen

Confidential

Page 22/35

25.05.2004


5.4.2 De Dienst Afnemen Het volgende schema laat zien hoe een product door een gebruiker wordt afgenomen. Een productenlijst krijgt de gebruiker alleen te zien indien hij een Rol heeft bij de DienstAanbieder (UserServiceRole) waaraan zo’n product is gekoppeld (ServiceRoleProduct, zie 5.4.1). De productenlijst wordt aan de hand van die gegevens opgebouwd. Kiest de gebruiker een product dan wordt UserServiceRoleProduct gevuld met de productgegevens uit ServiceProduct (zie 5.4.1). De aan het product gekoppelde taken worden overgenomen uit ServiceProductTask, en opgeslagen in UserServiceRoleProductTask. Met deze laatste acties wordt een kopie van de gegevens gemaakt in de gebruikerstabel. Er wordt geen gebruik gemaakt van verwijzingen naar de originele gegevens. Door het maken van een kopie wordt voorzien in een producthistorie. Als onderdeel van deze actie worden de autorisatiegegevens van de DienstAanbieder meegenomen. Daardoor is het voor medewerkers van de dienst mogelijk een overzicht van de afgenomen producten en toegekende taken te genereren.

Schema 2; de relatie tussen de gebruiker, rollen, producten en taken

Confidential

Page 23/35

25.05.2004


5.4.3 De Dienst Opmaken Het volgende schema laat zien hoe een gebruiker een dienst en producten kan aanbieden en aldus een DienstAanbieder wordt. Op het moment dat de gebruiker een Dienst (= Service) aanmaakt wordt hij als Eigenaar gekoppeld aan de Dienst. De rest van dit schema komt overeen met het schema bij “5.4.1. De Dienst Invullen”.

Schema 3; het aanmaken van een dienst door een gebruiker

Confidential

Page 24/35

25.05.2004


5.4.4 Autorisaties: rollen en profielen In Pim 2.0 is voorzien in het toekennen van permissies. Deze permissies zijn gekoppeld aan profielen, zogenaamde AutorisatieProfielen. De volgende profielen zijn vastgesteld: AutorisatieProfiel1: AutorisatieProfiel2: AutorisatieProfiel3: AutorisatieProfiel4: AutorisatieProfiel5:

Eigenaar: volledige toegang; Bewerker: lezen, schrijven en wijzigen; Bekijker Algemeen: lezen algemene gegevens; Bekijker Speciaal: lezen bijzondere gegevens; Niemand: geen toegang.

De volgende uitgangspunten zijn gekozen: 1. Een gebruiker kan een AutorisatieProfiel koppelen aan de boomstructuur van zijn persoonlijke profiel. Daardoor wordt (een gedeelte van) dat profiel opengesteld voor de aan het AutorisatieProfiel gekoppelde Rollen. 2. Een gebruiker kan geen permissies wijzigen op de ‘root’ van zijn profiel. 3. Gebruikers worden gekoppelt aan rollen. Deze rollen op hun beurt aan AutorisatieProfielen. 4. Een DienstAanbieder legt per product/taak vast welk AutorisatieProfiel daarop van toepassing is. Een DienstAanbieder heeft de mogelijkheid de eigen producten, en daaraan gekoppelde taken, te bekijken, nadat ze zijn afgenomen. De DienstAanbieder kan kiezen uit twee AutorisatieProfielen voor bekijken, waarbij één profiel specifiek bedoeld is voor privacy gevoelige gegevens.

Confidential

Page 25/35

25.05.2004


6. Ontwerpen 6.1 Inleiding In fornet05 is een entiteitendiagram opgenomen waarin de opbouw va de database en de relaties tussen de verschillende tabellen staat aangegeven. Dit schema is tijdens de opvolgende bouwperiodes enkele malen aangepast. Ook zijn niet alle tabellen zo ingevoerd als in het functioneel ontwerp voorzien. Het ontwerp voor Residentie.net heeft de volgende fases doorlopen:

Figuur <X>. Ontwerpfases Residentie.net

6.2 Actielijst In deze paragraaf zijn acties opgenomen die worden uitgewerkt in de verdere verloop van het project. Deze lijst is niet volledig en bedoeld als geheugensteun.

6.2.1 Pim 2.0 6.2.1.1 -

Acties ten behoeve van Pim 2.0

Ontwikkeling interface Testen interface Migratie database naar nieuw ontwerp Opstellen documentatie Vullen database met basisgegevens Node types vaststellen Formaat Import/Export bestanden vastleggen ..

Confidential

Page 26/35

25.05.2004


6.2.2 Onderwijsportaal 6.2.2.1 Acties ten behoeve van portaal - aanwijzen eigenaar - aanwijzen beheerder(s) - handleiding werken met portaal - ..

6.2.2.2 -

E-mail systemen + handleiding bevestiging script “Help” tekst WebMail “Welkom” e-mail tekst Residentie.net ICT coördinator instructie Digitaal leren instructie “Account gegevens brief” tekst ..

6.2.2.3 -

Acties ten behoeve van Fronter

..

6.2.2.4 -

Acties ten behoeve van WebMail

Acties ten behoeve van SiteBuilder

..

6.2.3 Ondernemersportaal 6.2.3.1 -

aanwijzen eigenaar aanwijzen beheerder(s) handleiding werken met portaal ..

6.2.3.2 -

Acties ten behoeve van portaal

Acties ten behoeve van diensten en producten

Opnemen beslisboom productafname ..

Confidential

Page 27/35

25.05.2004


BI. Database layout I.a “Live” De huidige database layout staat in de volgende tabel: db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout

Confidential

Actions Actions Actions Actions AuthTypes AuthTypes AuthTypes Categories Categories EmailCodes EmailCodes EmailCodes EmailCodes EmailCodes Fups Fups Fups KeyTypes KeyTypes KeyTypes Metatags Metatags Profiles Profiles Profiles Profiles ServiceActions ServiceActions ServiceActions ServiceRoleInfo ServiceRoleInfo ServiceRoleInfo ServiceRoles ServiceRoles ServiceRoles ServiceRoles ServiceRoles ServiceRoles ServiceRoles ServiceRoles ServiceRoles ServiceRoles Services Services Services Services Services UserInfo UserInfo UserInfo UserInfo UserInfoKeys UserInfoKeys UserInfoKeys

id classname name standard id classname name id name id code creationtime email user_id id url version id classname name id name id label name standard id action_id service_id id servicerole_id userinfokey_id id active fup_id info_url label name profile_id service_id sessiontimeout standard id info_url label name password id user_id userinfokey_id value id category_id keytype_id

Page 28/35

25.05.2004


db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout db-layout

UserInfoKeys UserInfoKeys UserMetatags UserMetatags UserMetatags UserProfiles UserProfiles UserProfiles Users Users Users UserServiceRoles UserServiceRoles UserServiceRoles UserServiceRoles UserServiceRoles UserSessions UserSessions UserSessions UserSessions UserSessions

label name id metatag_id user_id id profile_id user_id id password username id displayname fup_id servicerole_id user_id id authtype_id lastusagetime session_id userservicerole_id

I.b Technisch Ontwerp In het TO van maart 2003 zijn, naast de hiervoor genoemde tabellen, de navolgende tabellen en velden gedefinieerd. Deze zijn niet opgenomen in de live implementatie van 3P. to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec to-spec

Confidential

AuthorisationProfiles AuthorisationProfiles AuthorisationProfiles Certificates Certificates Certificates CertificateTypes CertificateTypes CertificateTypes Roles Roles Roles ServiceGroups ServiceGroups ServiceGroups ServiceGroups ServiceGroups ServiceGroups ServiceGroups ServiceRoleCertTypes ServiceRoleCertTypes ServiceRoleCertTypes ServiceTypes ServiceTypes UserAlias UserAlias UserAliasCertificates UserAliasCertificates UserAliasCertificates UserInfoCategories UserInfoCategories UserInfoCategories

id description level id certificatetype_id value id description handlerclass id description name id description name parentservicegroupid serviceid servicetypeid visible id certtypeid serviceroleid id name id userid id certificateid useraliasid id label name

Page 29/35

25.05.2004


I.c SAML integratie Ten behoeve van de SAML integratie dienen de navolgende wijzigingen nog doorgevoerd te worden. Deze wijzigingen komen uit het technisch ontwerp van september 2003 en zijn nog niet opgenomen in de ‘live’ implementatie van 3P. db-saml db-saml db-saml db-saml db-saml db-saml db-saml db-saml

ServiceRoles ServiceRoles ServiceRoles UserServiceRoles UserServiceRoles UserServiceRoles UserSessions UserSessions

Sso_saml_host Sso_saml_login_page Sso_token_ttl pseudonym pseudonym_confirmed token Sso_token Sso_token_gen_time

I.d PIM20 integratie Uit het voorliggend functioneel ontwerp komen de volgende wijzigingen en toevoegingen op de database. [LK: wijzigingen nader bekijken i.o.m. MH/KW ...] db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new

Confidential

Fups Roles RoleType RoleType ServiceProduct ServiceProduct ServiceProduct ServiceProduct ServiceProductTask ServiceProductTask ServiceProductTask ServiceProductTask ServiceProductTask ServiceProductTask ServiceRoleProduct ServiceRoleProduct ServiceRoleProduct ServiceRoleProduct ServiceRoleProduct ServiceRoleProduct ServiceRoles Services Services Services ServiceTask ServiceTask ServiceTask ServiceTask ServiceTask ServiceTask ServiceTask ServiceTask TaskType TaskType TaskType UserServiceRoleProductTask UserServiceRoleProductTask UserServiceRoleProductTask

active roletype_id id name id authorisationprofile_id name type id authorisationprofile_id name orderid ServiceRoleProduct_id ServiceTask_id id description name orderid ServiceProduct_id ServiceRole_id icon icon serviceowner servicetype_id id description e-mail formurl name service_id tasktype_id url id description naam id ClosedDate DueDate

Page 30/35

25.05.2004


db-new db-new db-new db-new db-new db-new db-new db-new db-new db-new

Confidential

UserServiceRoleProductTask UserServiceRoleProductTask UserServiceRoleProductTask UserServiceRoleProductTask UserServiceRoleProductTask UserServiceRoleProductTask UserServiceRoleProductTask UserServiceRoleProductTaskAction UserServiceRoleProductTaskAction UserServiceRoleProductTaskAction

e-mail formurl LastModificationDate name OpenDate ServiceTask_id url id formurl userserviceroleproducttask_id

Page 31/35

25.05.2004


BII.

Pim User Interface

In deze bijlage wordt een indruk gegeven van de nieuwe interface.

Voorbeeld 1: de ‘root’ van een installatie

In dit voorbeeld staat aan de linkerzijde, ingeklapt, de DienstAanbieder “Gemeente Den Haag”.Rechts staat de openingspagina van deze dienst, met een aantal mogelijke acties die op dat punt gedaan kunnen worden.

Voorbeeld 2: de DienstAanbieder uitgeklapt

Confidential

Page 32/35

25.05.2004


Voorbeeld 2 laat zien dat onder de ‘root-node’ vijf verschillende folders zijn te zien. De onderste heeft de naam Producten. Deze map bevat het productaanbod van de DienstAanbieder “Gemeente Den Haag”.

Voorbeeld 3: de Producten uitgeklapt

Als de productenmap wordt geopend worden de daarin opgeslagen producten zichtbaar.

Voorbeeld 4: een product uitgeklapt

Wordt een product uitgeklapt, dan worden de taken die aan het product gekoppeld zijn zichtbaar.

Confidential

Page 33/35

25.05.2004


BIII.

Over ontwerp en techniek

III.a Koppelingen tussen tabellen De tabellen uit Pied worden aan elkaar gekoppeld zodat aan de functionaliteiteisen wordt voldaan. -

-

Aan een DienstRol zijn producten gekoppeld. Aan Producten zijn Taken gekoppeld. Aan Taken zijn AutorisatieProfielen gekoppeld. Aan Rollen zijn AutorisatieProfielen gekoppeld. Producten zijn verzameld in ProductGroepen. Aan ProductGroepen zijn DienstRollen gekoppeld. Verschillende type rollen: Systeemrollen t.b.v. beheer DienstAanbieder en Gebruikersrollen t.b.v. gebruikers DienstAanbieders. ..

III.b Vragen ten behoeve van permissies Deze vragen helpen bij het vaststellen van de werkwijze voor het vastleggen en koppelen van de AutorisatieProfielen; -

Wie beheert de Dienst? Wie beheert de {Rollen} van de Dienst? Wie beheert de {Producten} in een DienstRol? Wie beheert de {Productgroepen} van de Dienst? Wie beheert de {Taken} van een Dienst? Wie beheert de {Takenlijst} van een product? Wie kan {Taken} [toekennen], [verifiëren (inzien)] en [accorderen]? Wie kan afgenomen taken wijzigen? Wie kan afgenomen taken verwijderen? ..

III.c Vragen voor toegang tot gebruikerstaken Deze vragen helpen bij het vaststellen van de werkwijze voor het lijsten van gebruikerstaken; -

Laat {alle taken} zien die aan {afnemers} van {mijn product} zijn toegekend, waarvoor {ik} ben {geautoriseerd}. Laat {alle afgenomen producten} zien, waarvoor {ik} ben {geautoriseerd}. Selecteer het {dossier} van de {onderneming} die {mijn product} wil afnemen. Reageer op {de taak} van {de gebruiker} en voeg {mijn reactie} toe. ..

III.d Vragen voor de interface Deze vragen helpen bij het vaststellen van de werkwijze voor het inrichten van het DienstAanbieder, annex DienstAfnemer, profiel; -

{Wat} voor {type-node} wilt u {aanmaken}? {Welke node} wilt u {verplaatsen}?

Confidential

Page 34/35

25.05.2004


-

{Welke node} wilt u {verwijderen}? {Wat} voor {Rol} wilt u {aanmaken}? {Welke voorwaarden} zijn er voor het {verkrijgen} van deze {rol}? Onder {welke Categoriën} valt {deze onderneming}? {Welke Taken} zijn aan dit {product} gekoppeld? {Wat voor} {Taak} wilt u aanmaken? ..

III.e Producten

Confidential

Page 35/35

25.05.2004

Residentie.net. Functioneel ontwerp. Pim 2.0

Recommend Documents