Onboarding makkelijker maken

[mcginkel]

Op dit moment hebben we met de 0.93/1.0 versie een stabiel werkend koppelvalk waar we mee uit de voeten kunnen.

Een van de dingen die we onderweg tegen komen is het onboarden van een nieuwe planning -> toetsafname combinatie voor een school. In de huidige flow moeten we verschillende emails uitwisselen tussen school, planning en afname systemen voordat alles goed geconfigureerd is. bv aanvragen van url/secret/clientid door school bij toetsafname, deze ontvangen en doorsturen naar planner. bij de planner aanvragen van url/client/secret door de school en deze doorsturen naar de afname applicatie. dit is foutgevoelig

Andere optie zou zijn om de url/client/secrets uit te wisselen tussen de leveranciers en deze nooit te tonen bij de scholen. de scholen hebben een switch om de koppeling aan of uit te zetten.
Achterliggend is de vraag of de client/id en secrets van de leverancier zijn om met de andere leverancier te communiceren en niet school specifiek.

[hamrt]

In principe is dit voor een heel groot deel afspraken mbt de inrichting van functioneelbeheer.
Mogelijk kan hier nog een korte toelichting op gedaan worden, maar is geen onderdeel van de specificatie binnen OKE.
Het lijkt niet automatiseerbaar.

[mcginkel]

Als we tijdens het aansluiten kijken wat we moeten instellen aan een kant (en dus moeten uitleveren) is dat iets als

{ 
"Naam" : "Remindo ESS",
"Url" : "https://mijnschool.remindo.nl/api/oke",
"TokenUrl": "https://authenticatie.remindo.nl/auth/token",
"Clientid" : "1234-567-12112-ABC",
"Clientsecret": "heelerggeheimsecret#!"
"Timestamp" : "2024-02-22T10:22:00"
}

Dit invullen geeft wel eens fouten. Wat fijn zou zijn als dit tot 1 token gemaakt kan worden dat alle informatie bevat en alleen maar gecopy en paste kan worden. en dat er gecontroleerd kan worden dat de info nog consistent is.

Voorbeeld van base64 encoded:
eyAKIk5hYW0iIDogIlJlbWluZG8gRVNTIiwKIlVybCIgOiAiaHR0cHM6Ly9taWpuc2Nob29sLnJlbWluZG8ubmwvYXBpL29rZSIsCiJUb2tlblVybCI6ICJodHRwczovL2F1dGhlbnRpY2F0aWUucmVtaW5kby5ubC9hdXRoL3Rva2VuIiwKIkNsaWVudGlkIiA6ICIxMjM0LTU2Ny0xMjExMi1BQkMiLAoiQ2xpZW50c2VjcmV0IjogImhlZWxlcmdnZWhlaW1zZWNyZXQjISIKIlRpbWVzdGFtcCIgOiAiMjAyNC0wMi0yMlQxMDoyMjowMCIKfQ==

de werkelijke implementatie zou een json formaat in een jwt token zijn.

Iedere applicatie moet dus 2 dingen implementeren: genereren van configuratie token en accepteren van een configuratie token. Belangrijk is om dit formaat af te spreken zodat partijen dit kunnen aanbieden om een onboarding makkelijker te maken

[hamrt]

Onderzoekje doen in hoeverre dit aansluit bij eerdere standaarden op dit vlak. Mogeljk nog aangevuld met scopes zoadat je aan kunt geven waarvoor deze info is.

[hamrt]

@hamrt checken!