Impact van Edukoppeling en OKE

[mcginkel]

Er ligt een vraagstuk of we EDU-Koppeling onder OKE communicatie kunnen zetten. Dit komt vanuit FACET/DUO.

Er zijn wat presentaties en ideeen gedeeld, en er ligt de vraag aan kerngroep techniek voor een reactie.

vragen aan de werkgroep edu koppeling:

• Wat zijn de voordelen en nadelen van de hier geschetste richting?
• Geeft dit houvast voor een gedetailleerde uitwerking in een Npulse/OKE afspraak?  Zo nee, wat te doen?
• Geeft houvast voor een gedetailleerde uitwerking in een onderwijsbrede afspraak? Zo nee, wat te doen?

Vanuit de presentatie is lastig om de impact te bedenken op de OKE, dus is het nodig om enkele aspecten beter te definieeren. Deze storie om een plek te hebben om dit beter te bespreken.

Uitgangs punten waar we in de OKE mee gestart zijn:

• geen centrale services in de keten. partijen communiceren direct met elkaar
• altijd beveiligde TLS verbinding (transportlaag)
• oauth2 als authenticatie mechanisme (client credential flow), client-id per school, niet per applicatie
• inhoud van tokens is aan de partij die token genereert en later weer accepteert. daar schrijven we niets voor.

Probeer de vragen als reactie te formuleren zodat we daarover kunnen discusiieren en toelichting vragen

[roelgrif]

Ik zie in ieder geval dat in de voorstellen de inhoud van het JWT token (gebruikte attributen) volledig anders is dan wij in gebruik hebben bij OKE als bearer-token. Dat lijkt me een issue.
Ik vind het vooralsnog erg lastig om de impact hiervan op de OKE uitwisseling (en specifieker voor ons pakket) in te schatten. Wel merk ik dat e.e.a. vooral beschreven is vanuit een SaaS gezichtspunt. Ik zou graag de situatie van een partij die voor zichzelf de service aanroept (ipv voor een klant) er ook graag bij beschreven willen zien (ook al is die situatie wellicht eenvoudiger).

[mcginkel]

Ik zou graag helderheid hebben over het gebruik van TEST OIN's. Die zijn officieel wel beschreven (https://gitdocumentatie.logius.nl/publicatie/dk/oin/#samenstelling-oin) als 00000099 prefix. Voor ons essentieel als we development doen en willen garanderen dat een developer geen certificaat heeft om in productie te gebruiken.

Er zijn "geruchten" dat logius van de test prefix af wil en ze niet meer uitgegeven worden.

[mcginkel]

Ik heb vragen over het gebruik van OIN als identificatie van de school. Ik sta achter het mechanisme dat je de afzender en ontvanger op leverenciers niveau kan zien, maar de OIN als school identificatie te gebruiken schuurt soms.

De OIN's zijn BRIN gebaseerd, de protocollen in de OKE (en vele andere) gebruiken geen BRIN's en dus is het OIN niet af te leiden en moet apart vastgelegd worden in alle applicaties. Ik OKE gebruiken we de OOAPI waar BRIN geen rol speelt

Waarom ION als school identificatie? hebben we die in de tokens wel nodig? of alleen bij overheid communicatie.

Verder graag aandacht voor: meerdere BRIN/OIN in een systeem, of juist een brin/OIN verspreid over meerdere leverenciers (lees: merges/splitten van scholen, overgangs periodes, etc)

[mcginkel]

Kunnen we bevestigen dat er in de EDU koppeling geen centrale componenten toegevoegd worden ? (was ook een breekpunt bij EDU-V)

[roelgrif]

Ik zou graag helderheid hebben over het gebruik van TEST OIN's. Die zijn officieel wel beschreven (https://gitdocumentatie.logius.nl/publicatie/dk/oin/#samenstelling-oin) als 00000099 prefix. Voor ons essentieel als we development doen en willen garanderen dat een developer geen certificaat heeft om in productie te gebruiken.

Er zijn "geruchten" dat logius van de test prefix af wil en ze niet meer uitgegeven worden.

Bij mijn weten is DUO er inderdaad helemaal van af gestapt om die reden. Zeker een issue: hoe zorgen we voor een goede authenticatie in testketens en voor een afscheiding van testketen van productieketen.

[mcginkel]

Kan er gebruik gemaakt worden van de "standaard" oauth token servers ? Kan een kleine leverancier/school dit met bv Azure blijven doen? Of keycloak?

Achterliggende reden: Het maken en bijhouden van eigen authenticatie/authorisatie servers door een klein partij is niet aan te bevelen.

[mcginkel]

Wie kan bepalen of de edukoppeling extra's gebruikt moeten worden? de ontvangende partij? of de zendende ? of beide?

[roelgrif]

Wat is de reden voor het gebruik van FSC? Kan er geen internationale standaard gekozen worden? Zeker met het oog op ver(der)gaande flexibilisering en internationalisering.

[mcginkel]

van de mail:

"Basisvraag: Waar is deze zware authenticatie voor nodig. Op welke onderdelen is het effectief veiliger dan de binnen OKE gekozen OAuth2.0 credential afhandeling eventueel in combinatie met standaard mTls.
Vervolgvraag: Is de classificatie waar vanuit wordt gegaan idd correct en welke authenticatiewijzes voldoen daar volgens DUO aan."

[mcginkel]

Kunnen we gebruik blijven maken van standaard libraries om token aan te vragen en rest calls te doen?

[rrutte]

Los van de gekozen oplossing is het handig om altijd gebruik te maken van industry standaards. Bijvoorbeeld om het ondersteunen van Reference tokens naast JWT tokens mogelijk te maken. Hoe specifieker je de koppeling maakt hoe lastiger is het om mee te bewegen met veranderende authenticatiestandaarden.

[mcginkel]

we wachten nog steeds tot de specs van de edukoppeling auth profiel helder opgeschreven staan.
Tussenstand:

• eerste niveau dat in de standaard gedefinieerd is is wat we nu doen bij de OKE (oauth2, met client credential flow, geen pki overheid certificaten of mTls, wel TLS1.2>)
• hoger nivea's is met signen pki overheid certificaat van token aanvraag ala EDU-V organisatie. Dat zouden we gebruiken met communicatie overheid.