Inhoudsopgave

Context binnen MAGDA

Tijdens het MAGDA aansluitingsproces worden er voor u enkele toegangs- en identificatieparameters aangemaakt. De doelstelling van de verschillende parameters is de nodige IDENTIFICATIE te voorzien en een extra laag BEVEILIGING te faciliteren. Afhankelijk van het technische protocol waarin de MAGDA Dienst is opgebouwd (SOAP/REST) zal er een andere identificator van toepassing zijn. In dit overzicht worden de verschillende parameters in detail toegelicht.

1. Identificatie voor de MAGDA Afnemer

1.1 Uniform Resource Identifier (URI)

Unieke identificatie van de juridische verantwoordelijke met eventueel de dataverwerker en de finaliteit.

Onderdelen binnen de URI

Juridische verantwoordelijke: De organisatie die over de JURIDISCHE BASIS beschikt om de gegevens te gebruiken.
Dataverwerker : De organisatie die de data bij het MAGDA-platform komt ophalen. Is een optioneel onderdeel en enkel van toepassing indien verschillend van de juridische verantwoordelijke.
Finaliteit: Gerechtvaardigd verwerkingsdoeleinde, vaak onderdeel van een JURIDISCHE BASIS, waarvoor gegevens gebruikt worden.
- Wordt gelinkt aan een Concept IPDC uit de IPDC van Digitaal Vlaanderen en uitsluitend naar een instantie IPDC indien het een toepassingsgebied Vlaams Gewest heeft, het een specifieke dienstverlening voor één lokaal bestuur betreft of er een filtering op maat van één lokaal bestuur nodig is.
- Meer informatie over IPDC van Digitaal Vlaanderen kan hier teruggevonden worden. De handleiding rond IPDC staat hier beschreven en de technische handleiding kan men hier raadplegen.
Omgeving: De technische omgeving op het MAGDA-Platform waar de gerealiseerde aansluiting staat.

2. Beveiliging voor de MAGDA Diensten via het SOAP protocol

2.1 Common Name (CN)

Unieke identificatie dat onderdeel uitmaakt van het certificaat en dat de juridische verantwoordelijke met eventueel de dataverwerker en een toepassing identificeert.

Onderdelen binnen de CN

Organisatiecode: De KBO nummer van de organisatie. Indien KBOnr 0316.380.841, dan gebruiken we de OVOcode. Indien er geen Belgische organisatiecode beschikbaar is, zoeken we een oplossing op maat.
- Dit onderdeel komt ook overeen met het “Domein” in DCBaaS
Juridische verantwoordelijke: De organisatie die over de JURIDISCHE BASIS beschikt om de gegevens te gebruiken.
Dataverwerker: De organisatie die de data bij het MAGDA-platform komt ophalen. Is een optioneel onderdeel en enkel van toepassing indien verschillend van de juridische verantwoordelijke.
Applicatienaam: De toepassing die de technische connectie maakt met het MAGDA Platform.
Omgeving: De technische omgeving op het MAGDA-Platform waar de gerealiseerde aansluiting staat.

2.2 Certificaat

Een vorm van beveiliging en identificatie van de toepassing van waaruit en naar waar er gegevensstromen gebeuren.

Inhoud van het certificaat

Common Name (CN): Identificatie van de bronapplicatie - wordt geleverd door MAGDA bij het aansluitingsproces
- vb wse.vlaanderen.be/dienstencheques
Organisational Unit (OU): Leesbare naam van de aanvrager, beperkt tot 24 tekens. In de mate van het mogelijke dient deze overeen te komen met de officiële naam van de aanvrager zoals volgens bestaande codering
- vb Stad Antwerpen, Provincie Vlaams-Brabant
Organisation (O): De organisatiecode van de organisatie. Voor Vlaamse overheid zonder rechtspersoon: OVO Code, Alle andere: KBO Code
- vb KBOXXXXXXXXXX, OVOYYYYYY
Country Code (C): Landcode
- Voor MAGDA vast als 'BE'

2.3 Stappenplan voor CN’s en Certificaten

De Common Names (CN’s) én Certificaten voor MAGDA Aansluitingen worden beheerd in het Certificatenbeheer of de DCBaaS toepassing van de veiligheidsbouwstenen van Digitaal Vlaanderen. Hieronder staat een overzicht van de verschillende stappen die nodig zijn voor de aanmaak en koppeling van een Common Name, Certificaat en MAGDA Dienst.

Stap

Beschrijving

Uitvoerder

Aanmaak Common Name/Toepassing in DCBaaS

Er wordt door het MAGDA Team tijdens het MAGDA Aansluitingsproces een nieuwe Common Name aangemaakt in het Certificatenbeheer (DCBaaS).

Een “Common Name” wordt in DCBaaS gezien als “Toepassing”.

MAGDA

Goedkeuren Common Name/Toepassing in DCBaaS

De nieuwe Common Name wordt automatisch goedgekeurd en slechts in beperkte gevallen is er nog een actie nodig van de Afnemer.

De toegang tot het certificatenbeheer en de beschikbare functies worden bepaald door de rol die een gebruiker heeft gekregen van de Lokaal Beheerder in het Gebruikersbeheer van de Vlaamse overheid (IDM).

DCBaaS Certificatenbeheerder Organisatie
DCBaaS Certificatenbeheerder Toepassing
DCBaaS Workflowbeheerder

Meer informatie over het Gebruikersbeheer vindt u op de website.

ACM of AFNEMER

Aanmaak van een DCBaaS Certificaat voor een Toepassing

Zodra de Common Name is aangemaakt is het voor de Afnemer mogelijk om hiervoor een nieuw DCBaaS Certificaat aan te maken.

Dit is pas mogelijk NA communicatie van het MAGDA Team.

AFNEMER

Koppeling DCBaaS Certificaat & MAGDA Dienst

De nieuwe Common Name en het daaraan verbonden Certificaat wordt door het MAGDA Team aan de gewenste MAGDA Dienst(en) gekoppeld.

MAGDA

Meer informatie over het aanmaken en beheren van certificaten binnen certificatenbeheer (DCBaas) vindt u hier.

Impact bij MAGDA voor het beheren van een certificaat

Impact op Certificaat

Impact bij MAGDA

Vernieuwen/verlengen DCBaaS Certificaat

Vernieuwen obv zelfde Common Name

Geen impact

Vernieuwen/verlengen Certificaat met publieke CA

Vernieuwen obv zelfde Common Name

Actie nodig

Voor vragen rond de impact bij MAGDA kan er contact opgenomen worden via de MAGDA Service Desk.

3. Beveiliging voor de MAGDA Diensten via het REST protocol

3.1 ACM OAuth ClientID

GUID ter identificatie van de toepassing in het Beheersportaal van Veiligheidsbouwstenen

Momenteel is er een één op één koppeling tussen een URI en een ClientID
Meer informatie over het Beheersportaal van Veiligheidsbouwstenen.

3.2 Stappenplan voor ACM OAuth ClientID

De ACM OAuth ClientID’s voor MAGDA Aansluitingen worden beheerd in het Beheerportaal van de veiligheidsbouwstenen van Digitaal Vlaanderen. Hieronder staat een overzicht van de verschillende stappen die nodig zijn voor de aanmaak en koppeling van een ACM OAuth ClientID en MAGDA Dienst.

Stap

Beschrijving

Uitvoerder

Aanmaak ACM OAuth ClientID

Er wordt door het MAGDA Team tijdens het MAGDA Aansluitingsproces een nieuw ACM OAuth ClientID aangemaakt in het Beheerportaal waarbij er een eerste koppeling is met MAGDA API’s.

Door de afnemer zelf aangemaakte clientID's kunnen niet gekoppeld worden aan MAGDA API’s.

MAGDA

Koppeling ClientID & MAGDA Dienst

De nieuwe ClientID wordt door het MAGDA Team gekoppeld aan de aangevraagde MAGDA Dienst obv de scopes.

MAGDA

Authenticeren obv Publieke key door Afnemer

De nieuwe ClientID moet door de Afnemer in het Beheersportaal nog de nodige authenticatie krijgen obv de publieke key.

Dit is pas mogelijk NA communicatie van het MAGDA Team.

Mogelijke manieren van authenticeren

De eigenlijke Public Key registreren (mogelijks DCBaaS Certificaat)
De URL (Json Web Key Set) als verwijzing naar Public Key registreren

Meer informatie over het Authenticeren obv Publieke key in het beheerportaal van ACM/IDM vindt u hier.

AFNEMER

Meer informatie over de werking van de ACM Oauth Client Credential Grant vindt u hier.

4. Contact

Met vragen rond Gebruikersbeheer kan u terecht op https://www.vlaanderen.be/digitaal-vlaanderen/onze-oplossingen/veiligheidsbouwstenen-applicatie-en-platformdiensten/gebruikers-en-rechten-tot-je-digitale-toepassingen-beheren, contactcenter via 1700 of dit contactformulier.
Met vragen rond het gebruik van Certificatenbeheer (DCBaaS) kan u terecht op vodcb@vlaanderen.be.
Met vragen rond het gebruik van MAGDA-Diensten en/of MAGDA Aansluitingsprocedure kan u terecht bij de MAGDA Service Desk. Vermeld indien mogelijk je dossiernummer.