Portaal

Context

In het Mijn Overheid Zakelijk prototyping team houden we ons bezig met het maken van technische oplossingen om aan de hand daarvan vooruitgang te boeken in het programma en te komen tot een definitieve technische oplossing zodat overheidsinstanties kunnen voldoen aan de Wet MEBV.

Als ondernemer dien je hier te kunnen inloggen met eHerkenning of DigiD (eerst gesimuleerd). Daarna kun je je profiel bekijken, wat een set van gegevens is uit het KVK Basisregister, aangevuld met ontbrekende gegevens beginnende met het e-mailadres.

Als er geen e-mailadres is, moet de ondernemer het kunnen invullen en wordt dit bewaard in de Profiel Service database. Als er reeds een e-mailadres bekend is, moet de ondernemer dit ook weer kunnen aanpassen.

Naast de profielinformatie, dient de ondernemer een geschiedenis lijst van contactmomenten te kunnen inzien. Dit wordt opgehaald uit de Historie Service, welke de callbacks van het Output Management Component of de NotifyNL Service ontvangt.

Functioneel overzicht

Wat hebben wij onderzocht en uitgewerkt?

Voorkant

De huidige voorkant van onze services is gebaseerd op MijnOverheid voor burgers. Hier kan een fictieve zakelijke gebruiker zijn e-mailadres instellen en contactmomenten bekijken. Ons doel is om deze voorkant, MijnOverheidZakelijk, verder te ontwikkelen tot een platform waar zakelijke gebruikers diverse zaken voor hun onderneming, stichting of vergelijkbare organisatie kunnen regelen. Denk bijvoorbeeld aan het aanvragen van subsidies, het melden van zwangerschapsverlof van medewerkers of het registreren van bedrijfsauto’s.

Profiel service

Deze service beheert het profiel van een onderneming, momenteel beperkt tot het e-mailadres. Op de achtergrond haalt de service aanvullende gegevens op uit het Handelsregister van de KvK. De ambitie van de profiel service is om een centrale plek te worden waar verschillende overheidsinstanties terechtkunnen als ze (contact)informatie van een bedrijf nodig hebben.

Output management component (OMC)

De OMC is verantwoordelijk voor de communicatie tussen vakapplicaties en Notify. Deze service ondersteunt contactherstel, wat betekent dat meerdere contactkanalen kunnen worden opgegeven. Bij uitval van een kanaal wordt het volgende kanaal in de prioriteitsvolgorde benaderd. De OMC registreert uitgebreide event-logs, die zowel voor de eindgebruiker als in de vakapplicatie zichtbaar zijn.

Bij een permanent falende reactie van een kanaal pakt de OMC dit ook op. In dat geval verzamelt de OMC de adresgegevens en initieert een call naar een brievendienst, die vervolgens een fysieke brief bezorgt.

Notify

Notify verstuurt de daadwerkelijke attenderingen en kennisgevingen naar de eindgebruiker, via e-mail, sms en/of brief. De precieze invulling van deze service wordt nog onderzocht; zie hiervoor ook ADR-0002.

Vakapplicatie

De vakapplicatie simuleert een systeem dat draait bij een externe partij die zakelijke gebruikers moet notificeren, zoals het UWV of de Belastingdienst. In de gemockte variant die wij beschikbaar stellen, is het mogelijk om een paar scenario’s te testen: scenario 2, scenario 8 en scenario 9. Voor meer uitleg over deze scenario’s, zie ook ADR-0003 en Scenario beschrijvingen in dit hoofdstuk.

Historie service

De historie-service is op dit moment nog grotendeels conceptueel. Deze service wordt verantwoordelijk voor het verzamelen van alle contactmomenten, zodat deze eenvoudig inzichtelijk zijn voor zowel de zakelijke gebruiker als de vakapplicatie. Dit gebeurt op een federatieve manier: de gebruiker logt in bij MijnOverheidZakelijk om zijn contactmomenten te bekijken, waarna de historie-service bij verschillende overheidsinstanties de relevante gegevens ophaalt en aan de gebruiker toont.

Figma

De meest actuele UX-designs zijn terug te vinden in Figma: [figmalink hier]

Scenario beschrijvingen

Functionele beschrijving van de werking van onze vakapplicatie: de twee opties worden in de frontend weergegeven als een reeks knoppen.

Voor meer informatie zie decision scenario bepaling

Scenario 2

mermaid
sequenceDiagram
    actor Medewerker
    Medewerker->>Vakapplicatie:
    activate Vakapplicatie
    Vakapplicatie->>Notificatie service:Verstuur verzoek tot notificatie
    activate Notificatie service
    Notificatie service-->>Vakapplicatie:
    deactivate Vakapplicatie
    Notificatie service-->>Vakapplicatie:Notificatie status update callback
    deactivate Notificatie service
    activate Vakapplicatie
    Vakapplicatie->>Vakapplicatie:Afhandeling callback
    deactivate Vakapplicatie

Scenario 8

mermaid
sequenceDiagram
    actor Medewerker
    Medewerker->>Vakapplicatie:
    activate Vakapplicatie
    Vakapplicatie->>OMC:Verstuur verzoek tot notificatie
    deactivate Vakapplicatie
    activate OMC
    OMC->>Profiel service:Haal contact inforamtie op o.b.v. kvknummer
    activate Profiel service
    Profiel service-->>OMC:
    deactivate Profiel service
    OMC->>Notificatie service:Verstuur verzoek tot notificatie
    activate Notificatie service
    deactivate OMC

    Notificatie service-->>OMC:Notificatie status update callback
    deactivate Notificatie service
    activate OMC
    alt status = mislukt
        OMC->>Profiel service:Haal adres gegevens op o.b.v. kvknummer
        activate Profiel service
        Profiel service-->>OMC:
        deactivate Profiel service
        OMC->>Notificatie service:Stuur verzoek tot brief
        activate Notificatie service
        Notificatie service-->>OMC:Brief callback
        deactivate Notificatie service
    end
    deactivate OMC
    OMC-->>Vakapplicatie:Optionele callback

Onderwerpen zijn:

• Performance (e.g. latency and throughput)
• Scalability (e.g. data and traffic volumes)
• Availability (e.g. uptime, downtime, scheduled maintenance, 24x7, 99.9%, etc)
• Security (e.g. authentication, authorisation, data confidentiality, etc)
• Extensibility
• Flexibility
• Auditing
• Monitoring and management
• Reliability
• Failover/disaster recovery targets (e.g. manual vs automatic, how long will this take?)
• Business continuity
• Interoperability
• Legal, compliance and regulatory requirements (e.g. data protection act)
• Internationalisation (i18n) and localisation (L10n)
• Accessibility
• Usability

Accessibility

Alle webapplicaties van de overheid dienen te voldoen aan de WCAG 2.1 A + AA standaarden. Zie hiervoor de wet- en regelgeving op digitoegankelijkheid.nl.

Tijdens de Pilot zullen de volgende browsers ondersteund worden:

• Chrome
• Edge
• Safari
• Firefox

Hiervan worden de laatste twee versies ondersteund. Ook wordt de Responsive versie van deze browsers ondersteund. Motivatie: de gekozen browsers worden het meest gebruikt op het Internet. De keuze om de laatste twee versies van elke browser te ondersteunen is volgens het beleid van de Rijksoverheid,bij de Overheid, zoals bij Algemene Zaken. Uiteraard moet ook mobiel ondersteund worden. Vandaar de ‘Responsive’-eis.

Design systemen

NL Design System conform ADR 0009. UI-teksten in het Nederlands, TODO: en toepassing van de vertaal tooling van de Europese Commissie om alle talen van de EU te ondersteunen.

Lighthouse

**Lighthouse test? **Om de kwaliteitseisen te behalen maken we gebruik van een Lighthouse test, deze kijkt naar de volgende aspecten:

Accessibility & Best Practices zijn belangrijk in verband met Digi Toegankelijkheid en W3 Web design. Performance is ook van belang, maar moet niet de Accessibility in de weg zitten dus is iets lager. Het resultaat van deze test fluctueert ook aan de hand van de server drukte. Metrics hier te vinden. SEO (Search Engine Optimization) en PWA (Progressive Web App) is niet relevant voor deze applicatie.

Let op: voor het daadwerkelijk voldoen aan de Accessibility richtlijnen dient er altijd een handmatige test te worden uitgevoerd door een toetsingsbureau!

CVE issues

TODO: welke tool gaan we gebruiken voor het automatisch controleren van CVE issues in de projecten

Open Standaarden

Via het Forum Standaardisatie van de Rijksoverheid is de volgende selectie van van toepassing zijnde Open Standaarden gemaakt. Zie PDF: Beslisboom_Open_Standaarden___Forum_Standaardisatie.pdf

Monitoring en Management

NTB

Concurrency/Stress Testing

NTB

Beperkingen

Overzicht

Technologiestack en standaarden

• Voorkeurslijst open standaarden (Forum Standaardisatie) en NL Design System (ADR 0009). Opgelegd door rijksstandaarden/UX-kaders. Impact: front-end componentkeuze is beperkt; consistentie en toegankelijkheid zijn geborgd.

Design Principles

Principes

• Toegankelijkheid en UX-conventies (productbreed)
  Voor UI-onderdelen volgen we het NL Design System.
  Verwijzing: ADR 0009.
  Noot: de Profielservice is primair backend; UI-principes gelden waar UI-componenten worden opgeleverd of referentie-UIs worden gebruikt.

Software Architectuur

De Software Architectuur is de “big picture view” en beschrijft de structuur van de software.

Zie ook: Inhoud guidelines Software Architectuur

Systeem Landschap diagram

Om een beeld te schetsen van het Mijn Overheid Zakelijk systeem landschap, inclusief notificeren met kanaalherstel, berichtenbox en de profielservice, is hier een totaaloverzicht van het gehele systeemlandschap van Mijn Overheid Zakelijk. In de verdere paragrafen van dit hoofdstuk zoomen we verder in op de verschillende onderdelen. Via het diagram kan ook verder worden ingezoomd op de verschillende softwaresystemen.

Architectuurschets Profiel Service

Dit diagram toont het containerniveau van de Profiel Service en de systemen waarmee deze interageert. De Profiel Service bestaat uit een service-laag met een achterliggende database. Daarnaast raadpleegt de service het Handelsregister, om twee redenen:

1. Het tonen van bedrijfsinformatie aan zakelijke gebruikers via MijnOverheid Zakelijk.
2. Het verstrekken van adresgegevens aan de Berichtenbox voor Burgers en Ondernemers (BBO), wanneer deze daar om vraagt.

De systemen en scenario’s die de Profiel Service bevragen, worden hieronder toegelicht.

Mijn Overheid Zakelijk

MijnOverheid Zakelijk wordt in een later hoofdstuk uitgebreider behandeld. Vanuit het perspectief van de Profiel Service fungeert MijnOverheid Zakelijk als de interface waar zakelijke gebruikers hun profielinformatie kunnen inzien en beheren. Daarnaast haalt MijnOverheid Zakelijk ook contactmomenten op bij onder andere de BD en het UWV. Deze interacties worden verder toegelicht in het betreffende hoofdstuk.

Scenario 2

In scenario 2 wordt geen gebruik gemaakt van de Profiel Service. Om die reden is RVO niet opgenomen in het diagram.

Scenario 8

In dit scenario raadpleegt het UWV de Profiel Service om contactgegevens van de zakelijke gebruiker op te halen. Deze informatie is nodig voor het versturen van een kennisgeving.

Scenario 9

Scenario 9 maakt op één momenten gebruik van de Profiel Service namelijk: Aan het begin van het proces, om de contactgegevens op te halen ten behoeve van het versturen van een kennisgeving.

Opmerking: de foutmelding vanuit de Notificatie Service richting BBO is in dit diagram niet visueel weergegeven.

Architectuurschets MijnOverheid Zakelijk

Het diagram hierboven toont de systeemcontext van MijnOverheid Zakelijk (MOZA). MOZA is het portaal waar zakelijke gebruikers hun profiel kunnen beheren en inzicht krijgen in hun contactmomenten met aangesloten overheidsorganisaties. Twee kerncomponenten zijn zichtbaar:

• Mijn Overheid Zakelijk, dat functioneert als gebruikersinterface voor de persoonlijke mijnomgeving van zakelijke gebruikers
• De IAM Gateway, die authenticatie faciliteert via eHerkenning (en potentieel DigiD)

Rol van de Zakelijke Gebruiker

Bovenaan het diagram is de zakelijke gebruiker gepositioneerd. Via het MOZA-portaal beheert deze gebruiker zijn profielgegevens, waaronder contactinformatie. Deze informatie speelt een centrale rol in de afhandeling van kennisgevingen binnen scenario’s 8 en 9, zoals eerder beschreven. Daarnaast biedt MOZA inzicht in contactmomenten met aangesloten organisaties, in dit geval de BD en het UWV.

MOZA in de scenario’s

Hoewel scenario 2 (RVO) geen gebruik maakt van MOZA en daarom niet is opgenomen in het diagram, is de rol van MOZA in scenario’s 8 en 9 wél essentieel.

In scenario 8 (UWV) zorgt MOZA ervoor dat de zakelijke gebruiker zijn contactinformatie up-to-date kan houden in de Profiel Service. De UWV raadpleegt deze gegevens vervolgens om kennisgevingen correct te adresseren.

In scenario 9 (BD) is deze rol vergelijkbaar, maar uitgebreider: de contactinformatie is niet alleen nodig voor de initiële kennisgeving, maar ook voor het kanaalherstelproces indien een notificatie niet succesvol kan worden afgeleverd. Ook in dit scenario speelt MOZA een cruciale rol in het beschikbaar stellen van actuele en betrouwbare gegevens.

Code

Data

Datastore typen

Voor het opslaan van de verschillende datatypes maken we gebruik van verschillende datastores die het beste aansluiten bij het type data dat moet worden opgeslagen.

• PostgreSQL
  PostgreSQL is een SQL datastore die geschikt is voor het opslaan van data volgens een vastgesteld model / schema.

Systeem Logging

Metrics

Structured Application Logging

Infrastructuur Architectuur

Infrasctuctuur Standaard Platform

Alle software systemen binnen het landschap Vertegenwoordigen draaien op het Standaard Platform van Logius. Dit is een door Logius gehoste container infrastructuur op basis van Kubernetes. Meer informatie hierover is te vinden op de website van Logius: https://logius.nl/diensten/standaard-platform.

Verdere technische informatie en tal van voorbeeld applicaties is te vinden op de Wiki van het Standaard Platform:

• Standaard Platform Wiki

Ook op bovenstaande Wiki te vinden, maar een snel toegankelijk overzicht van de infrastructuur is:

Klantomgeving

Verkeersbeeld

Multi Data Center

Deployment

Branching strategie

We maken gebruik van de GitFlow branching strategie. Dat wil zeggen dat er elke feature in zijn eigen feature-branch wordt ontwikkeld en na review via een Merge Request naar de develop branch wordt gemerged. Nieuwe releases worden via een merge request van develop naar een release/x.x.x branch gepushed. Om de release naar productie te brengen, wordt de release/x.x.x branch naar main gemerged.

De software wordt via CI/CD-pipelines uitgerold naar de omgevingen. Dit gebeurt binnen een OpenShift 4.x-omgeving. De uitrol wordt handmatig gestart via een pipeline in het GitLab-project dat je wilt uitrollen. Deze pipeline downloadt de broncode van de main-branch uit de GitHub-repository, bouwt hieruit een image en pusht deze naar Harbor. Vervolgens wordt ArgoCD genotificeerd dat er een nieuwe sync moet plaatsvinden; Argo synchroniseert daarna de deployment op OpenShift naar de nieuwste versie.

Gebruikte Tooling

Prototype omgeving

De POC omgeving is te vinden op het TEST cluster van Openshift in de logius-moz-poc namespaces.

Applicaties

Door ons gehosten applicaties

Extern gebruikte applicaties door prototype omgeving

Uitrol naar omgeving

Postgres databases leegmaken

Er zijn situaties waarbij de data in database leeggemaakt dient te worden alvorens een uitrol kan worden gedaan. Voor het leegmaken van de Postgres database dien je de volgende stappen te doen (stap 1 t/m 3 is eenmalig):

1. Download de “oc - OpenShift Command Line Interface” CLI. Deze kan gedownload worden via https://console-openshift-console.apps.test3.gn3.sp.rijksapps.nl/command-line-tools
2. Maak een nieuw folder aan in Program Files bv. openshift
3. Voeg een nieuw pad aan je path environment variables -> “C:\Program Files\openshift”
4. Open een Powershell terminal om in te loggen in OpenShift. oc login --web
5. Switch naar logius-moz-poc namespace met de volgende kubernetes command: oc project logius-moz-poc Ter info. in deze stap wordt vanuit gegaan dat je de Kubernetes command-line tool(kubectl) al op je lokale omgeving beschikt. Deze komt namelijk mee wanneer je Docker op je omgeving hebt geinstalleerd. Als dit niet het geval is dan kan je de cli downloaden via https://kubernetes.io/docs/tasks/tools/#kubectl
6. Neem vervolgens de shell over van de draaiende Postgres pod in kubernetes kubectl exec --tty --stdin postgres-statefulset-0 -- /bin/sh
7. Maak een connectie met je Postgres database: psql -h localhost -U postgres -d postgres
8. Hij zal om een wachtwoord vragen, zie hiervoor de secret in openshift postgres-postgresql
9. Ga naar OpenShift om de Pods die met postgres praten down te scalen. Doe die door de deployments naar 0 replicas te scalen.
10. Maak een connectie met gewenste database met de volgende command \c "databasename"
11. Gebruik de volgende command om je data in de database leeg te maken delete from tablename;
12. Sluit je database connect af \q
13. Sluit je shell af met exit

Ontwikkelomgeving

Ontwikkel werkplek

Als DevOps-medewerker dien je de beschikking te hebben over een unmanaged laptop, of BYOD. Beter gezegd; een laptop naar eigen voorkeur, die je zelf verder kunt inrichten. Het OS / platform maakt niet uit.

VPN verbinding

Om verbinding te kunnen maken met het Standaard Platform, dient er een VPN te worden opgezet. De benodigde inloggegevens hiervoor ontvangt een nieuwe medewerker van het Standaard Platform. Het opzetten van de VPN verbinding is OS-specifiek en keuze voor software daarvoor vrij aan de medewerker zelf.

OpenShift CLI

Voor interactie met OpenShift is de OpenShift CLI nodig. Deze is te downloaden van de OpenShift website zelf wanneer je een RedHat account hebt en is ook beschikbaar via de webinterface. Klik rechtsboven op het vraagteken en kies Command Line Tools. Zie Deployment view voor URL’s van de OpenShift omgevingen.

Kubernetes

Voor het technisch beheren van de Kubernetes is kubectl nodig.

Links

• Getting Started with the OpenShift CLI
• Kubernetes Install Tools

Beheer en Support

Gezamenlijke War-Room

Er is momenteel geen fysieke, gezamenlijke “special operation”-room, aangezien we ons nog in de POC-fase bevinden.

Incidentenprocedure

Er is momenteel nog geen incidentenprocedure opgesteld, aangezien we ons nog in de POC-fase bevinden. Incidenten/bugs worden gemeld bij de Product Owner en komen in de backlog, daar worden ze opgepakt door het DevTeam.

Hosting Standaard Platform

De omgeving wordt gehost door het Standaard Platform van Logius. Incidenten en wijzigingen kunnen, met de juiste rechten, worden ingeschoten via Topdesk: https://topdesk.sp-cloudservices.nl/tas/public/login/form.

Nieuwe Medewerker

Nieuwe medewerkers hebben een Standaard Platform account nodig om verbinding te kunnen maken met de VPN en toegang te krijgen tot de omgevingen. Dit account wordt geregeld via het Standaard Platform.

Accounts

• VPN
• GitLab

Vertrek van medewerkers

Wanneer medewerkers het team verlaten, wordt de toegang tot hun account bij het SP ingetrokken op de laatste werkdag. Daarmee kunnen zij niet meer bij de omgevingen.

Backups Restoren

Voor het terugzetten van backups van bijvoorbeeld Persistant Volume Claims (PVC’s) en andere objecten die je niet vanuit de pipelines of eigen MinIO omgeving kunt herstellen, kan men bij het Standaard Platform terecht via het Self-Service portaal, of de Topdesk formulieren. Hiervoor dient men wel de juiste rechten te hebben (Developer en Resource Beheerder).

• Self Service portaal: https://ssp.cicd.s15m.nl/
• Topdesk: https://topdesk.sp-cloudservices.nl/

Databases beheren

Er wordt Code First ontwikkeld, wat betekent dat de database schema’s worden gegenereerd op basis van de in de code gedefinieerde modellen. Hierdoor zal het niet nodig zijn, of liever gezegd niet de bedoeling, om aanpassingen in de database definities te maken. Uiteraard kan er nog steeds beheer op databases nodig zijn waarvoor je verbinding met een database moet kunnen maken.

Verbinden met een database op het SP kan via CLI of een IDE (bijvoorbeeld Azure Data Studio of IntelliJ). Om vanaf de ontwikkelwerkplek direct in te loggen op een database of andere service op kubernetes dien je port forwarding in te stellen.

kubectl port-forward service/postgres-service 5432:5432

Zie ook: Use Port Forwarding to Access Applications in a Cluster

Databases restoren

Certificaten

Voor de omgevingen van MOZ hebben we nog geen certificaten aangevraagd.

Secrets

In “Secrets” staan de login gegevens van de diverse componenten, denk aan hier aan bijvoorbeeld Databases en externe API’s.

POC omgeving:

Iedereen die een hierboven genoemd VPN en Openshift account heeft, kan voor deze omgevingen een certificaat/secret neerzetten en verwijderen.

Certificaat als Sealed Secret installeren op OpenShift

Voor het installeren van een certificaat in OpenShift is een .key en een .crt bestand nodig. Heb je deze niet, maak deze dan aan. Let op: De key dient unencrypted te zijn.

Secret maken en sealen

1. Inloggen op OpenShift
   1. Ga naar de OpenShift webinterface (zie URL in Deployment View)
   2. Log in met sp-oidcdp
   3. Klik op je naam > Copy login command
   4. Nogmaals inloggen
   5. Klik op Display Token
   6. Kopieer het eerste commando
2. Open je terminal/console
3. Plak het commando dat je zojuist hebt gekopieerd: oc login
4. Kies de gewenste omgeving: oc project [naam-omgeving]
5. Download de public key van het desbetreffende cluster (TEST of PROD) om te kunnen sealen uit https://gitlab.cicd.s15m.nl/sp-docs/publiek/-/wikis/applicatie-uitrollen/ci-cd/Sealed-Secrets.
6. Maak het secret aan en seal deze met het volgende commando (pas [] aan):

   kubectl create secret generic [secret-naam] -n [namespace]
   --from-file=tls.key=[file-naam]
   --from-file=tls.crt=[file-naam]
   --dry-run -o yaml | kubeseal --cert env_public-key-[test|prod].pem --format yaml - > [bestandsnaam].yaml
   

7. Upload het secret naar OpenShift:
   kubectl apply -f [kies_filename].yaml
   1. LET OP: op de productie namespaces kan dit commando alleen worden uitgevoerd onder account van technisch applicatie beheer met de toevoeging: --as logius-moz-tab

Certificaten bewerken

• TODO: hier info over hoe certificaten te bewerken

Monitoring

• Kibana & Grafana: bouwstenen van het Standaard Platform.

Zie deployment voor URL’s.

Logging

Voor de logging strategie maken we een onderscheid in gebruikte standaard services, en onze eigen services / containers. Standaard Services hebben hun eigen, onaangepaste logging. Onze eigen services / containers hebben service specifieke logging en bijbehorende foutmeldingen. Alle logging van de services is inzichtelijk via Kibana en Grafana.

Wanneer er bijzonderheden zijn in de logging van een van onze services, kan dat hier worden beschreven.

Zie deployment voor URL’s.

Meest voorkomende storingen en oplossingen

• TODO: Meest voorkomende storingen en bijbehorende oplossingen beschrijven.