M2M identificatie, authenticatie en autorisatie

Binnen Edu-V wisselen Leveranciers gegevens uit via M2M gegevensuitwisselingen. Hiervoor implementeert iedere Leverancier een identificatie, authenticatie en autorisatie oplossing. De werking hiervan wordt hieronder nader toegelicht op deze pagina en bestaat uit de volgende onderdelen:

NL GOV Assurance profile voor OAuth 2.0

Binnen Edu-V worden M2M gegevensuitwisselingen geïdentificeerd en geauthenticeerd op basis van het NL GOV Assurance profile voor OAuth 2.0. Dit NL GOV OAuth 2.0 profiel is onderdeel van de API Strategie van het Kennisplatform APIs. Het Kennisplatform APIs is een initiatief van onder meer Bureau Forum Standaardisatie, Geonovum, Kamer van Koophandel, VNG Realisatie en Logius die allen het manifest ondertekend hebben.

Het profiel gaat er in de basis vanuit dat er met standaardcomponenten een verbinding opgezet kan worden geïnitieerd vanuit een eindgebruiker (Authorization code flow) of tussen twee machines (Client Credentials flow met Direct Access Clients).

Binnen Edu-V hebben we te maken met de variant van uitwisseling tussen twee machines. Leveranciers wisselen immers via hun referentiecomponenten gegevens uit met de referentiecomponenten van andere leveranciers.

Binnen de specificatie van het NL GOV profiel zijn de volgende onderdelen van toepassing op Edu-V:

• Direct Access Client voor referentiecomponenten die een request doen op een API van een andere referentiecomponent. Deze referentiecomponenten voldoen aan de gestelde eisen in het profiel:

  • must Een verzoek aan het token endpoint wordt door de Client gedaan op basis van:

    • must Private key jwt en met het grant_type client_credentials en voor een client_id.

    • SHOULD In het verzoek worden de scopes meegegeven van de resources die bevraagt gaan worden. Binnen Edu-V zijn de gegevensdiensten voorzien van specifieke scopes op basis van de vereiste uit het profiel voor protecting resources.

  • must De Client beschikt over een PKIoverheid certificaat met Client keys bestaande uit een publieke en een private key.

  • must De publieke key wordt door de Client beschikbaar gesteld middels een jwks_uri.

    • De private key wordt door de Client gehanteerd om in de private_key_jwt flow de Client_jwt te signeren.

    • De autorisatieserver kan met de publieke key vervolgens de Client_jwt ontcijferen. De publieke key verkrijgt de autorisatieserver via de jwks_uri.

  • must Een verzoek aan de resourceserver wordt gedaan met het token dat door de Autorisatieserver is uitgegeven aan de Client.

• Autorisatieserver en resourceserver voor de referentiecomponenten die de API aanbieden en requests van Clients ontvangen. Deze referentiecomponenten voldoen aan de gestelde eisen in het profiel:

  • must Client registration met een unieke client_id voor iedere applicatie.

    • MUST De client_id wordt bepaald door de leverancier die de autorisatieserver aanbiedt.

    • SHOULD NOT client_id is bij voorkeur niet gelijk aan het OIN. Het OIN wordt gehanteerd om de organisatie vast te stellen. Het client_id is gericht op de identificatie en de authenticatie van de applicatie van de leverancier.

  • COULD Dynamic registration van clients hoeft niet ondersteund te worden.

  • must Het kunnen verwerken van een verzoek aan het token endpoint van de autorisatieserver en het teruggeven van een token response op basis van JWT Bearer Tokens.

  • must Het token heeft een maximale levensduur van één uur. Op dit vlak zijn we strikter dan de voorgeschreven zes uur voor Direct Access Clients.

  • COULD Het aanbieden van de discovery endpoints issuer, token_endpoint en jwks_uri. Het authorization_endpoint is niet verplicht. Ook op dit punt wijken we af van de specificatie.

  • must De resource server voldoet aan de vereisten zoals gesteld in het protected resource profile.

  • must De autorisatieserver verifieert of de client_id van de Client en de OIN uit het PKIoverheid certificaat overeenkomen met de gegevens in de eigen Clientregistratie.

  • must De autorisatieserver verifieert de geldigheid, certificaateketen en de CRL voor het door de Client gehanteerde PKIoverheid certificaat.

De bovenstaande implementatiekeuzes van het NL GOV OAuth profiel zijn nader uitgewerkt in een interactieanalyse.

Proces: interactieanalyse identificatie en authenticatie middels OAuth 2.0

In Figuur 1 is het interactiediagram voor de identificatie en authenticatie middels OAuth2.0 beschreven. In het geïllustreerde scenario wil Leverancier A het endpoint van Leverancier B gaan bevragen.

Open

Interactieanalyse identificatie, authenticatie en autorisatie middels OAuth2.0 private_key_jwt

De wijze van identificeren, authenticeren en autoriseren is afhankelijk van de gegevensdiensten die Leverancier A wil gaan uitwisselen. Afhankelijk van de gegevensclassificatie voor het informatieobject zijn er additionele authenticatie en autorisatieregels van toepassing. Het betreft:

• VERTROUWELIJK van toepassing op uitwisseling van vertrouwelijke informatieobjecten

• activering van toepassing op uitwisseling van informatieobjecten waarbij Onderwijsorganisatie regie heeft op de uitwisseling

In onderstaand schema is per gegevensclassificatie weergegeven of de maatregelen al dan niet van toepassing zijn.

Het proces bestaat uit de volgende stappen:

Release notes