Architectuurscan Edukoppeling REST

Uit ROSA Wiki
Ga naar: navigatie, zoeken

Deze pagina toont een samenvatting van de ROSA Architectuurscan van het onderwerp Edukoppeling REST/SAAS-profiel. Met de ROSA Architectuurscan worden op systematische wijze alle architectuuraspecten van een bij Edustandaard ingebracht onderwerp in kaart gebracht en worden knelpunten en kansen gesignaleerd. Niet alleen kan de indiener er zijn voordeel mee doen, ook kan ROSA ermee worden verrijkt. En tot slot stelt het andere ketenpartijen in staat om kennis te nemen van architectuurwijzigingen en het belang hiervan voor de eigen organisatie of achterban te bepalen (transparantie in de keten, informatiepositie).

De architectuurscan is uitgevoerd op 29 oktober 2020. Zie voor meer informatie, waaronder de adviezen die naar aanleiding van de scan door de Architectuurraad zijn uitgebracht, het adviesdeel en het bevindingendeel.

ROSA onderdeelBevindingen uit project: Edukoppeling REST/SAAS-profielRelatie met ROSA (blauw: ROSA, geel: Edukoppeling REST/SAAS-profiel)
Werkingsgebied

Gehele onderwijsdomein (cf. organisatorisch werkingsgebied zoals beschreven in Edukoppeling architectuur).

Fullyconformant.pngFully conformant - Het REST/SaaS-profiel valt binnen de Edukoppeling architectuur waarvan het werkingsgebied het gehele onderwijsdomein betreft.

Toepassingsgebied

M2M-gegevensuitwisseling via een beveiligde point-to-pointverbinding waarbij RESTful standaarden voor gesloten (access-restricted en purpose-limited) APIs worden toegepast (zowel pull als push).

Consistent.pngConsistent - Het REST-SaaS-profiel voegt een gestandaardiseerde werkwijze voor het gebruik van REST-APIs toe aan de Edukoppeling-architectuur.

Bovensectorale samenwerking

Gemeenschappelijkheid in informatiehuishouding

Binnen het onderwijs zijn al veel ketenpartijen die gebruik maken van RESTful gegevensuitwisseling. Deze maken nu zelfstandige keuzes hoe transport, logistiek en beveiliging ingericht moeten worden. Het profiel beoogt hier meer standaardisatie in door te voeren, waarbij met name invulling gegeven wordt aan het kunnen routeren tussen de rollen die in Edukoppeling t.b.v. SaaS worden onderscheiden.

Compliant.pngCompliant - Het SaaS/REST-profiel brengt gemeenschappelijkheid in RESTful gegevensuitwisseling in het onderwijsdomein.

IBP
  • TLS (wordt verwezen naar UBV)

Vertrouwelijke gegevens in GET-parameters

  • P.13: ‘dienen gepseudonimiseerd te zijn’
  • P.18: igv persoonsgegevens ‘kunnen aanvullende beveiligingsmaatregelen toegepast worden, zoals adequaat versleutelen en/of voorkomen ongewenste logging dmv filter’.

Compliant.pngCompliant - Het SaaS/REST-profiel brengt gemeenschappelijkheid in RESTful gegevensuitwisseling in het onderwijsdomein

De opmerkingen in de tekst over vertrouwelijke gegevens in GET-parameters zijn in kennelijke tegenspraak.

  • ‘Vertrouwelijk’ is breder dan ‘persoonsgegevens’
  • Specifiek voor persoonsgegevens geldt AVG (‘passende maatregelen’)
  • Pseudonimisering als specifieke maatregel is mogelijk niet in alle situaties toepasbaar. (Uit toelichtende gesprekken blijkt overigens dat ‘pseudonimisering’ hier gelezen moet worden als het gebruiken van betekenisloze identifiers.)
IAA
  • Identificatie/authenticatie verwerker obv OIN / PKI-infrastructuur (P2P).
  • Eindorganisaties worden geïdentificeerd via routeringskenmerken (TO, FROM)
  • Inzet van transparante dienstverleners wordt (nog) niet ondersteund (daarvoor: WUS)
  • Verplicht gebruik Onderwijsserviceregister
  • Verwijzing naar ontwikkelingen OAuth in bijlage A.
  • Gebruik van API-sleutels geen onderdeel van het profiel, maar wel toegestaan
    • Voor API-key (geen onderdeel profiel) stroomschema’s en mogelijke 401/403-foutcodes. Zoiets mist voor afhandeling van ‘from-OIN’ en OIN verwerker (P2P) .

Consistent.pngConsistent - de invulling van IAA sluit aan bij bestaande methoden en voorzieningen (OIN, PKI, OSR).


(Verplichte) toepassing van het OSR voor RESTful-gegevensuitwisseling tussen meerdere gelijkwaardige ketenpartijen stelt aanvullende eisen aan registratie van diensten in en de werking van het OSR.

Gegevensuitwisseling in de keten

Must: Gebruik van openbare internet “Overigens kan Edukoppeling ook toegepast worden in gesloten netwerken.”. Tegenspraak? Hoe ‘must’ te lezen?

Foutafhandeling:

  • Architectuur definieert categorieën A t/m E In 3.1.8 alleen foutmeldingen voor cat. A t.a.v. syntax to/from-routeringskenmerken. → hoe passen de andere categorieën op HTTP statuscodes?

Compliant.pngCompliant - Toepassing voor zowel bevragingen als meldingen, gebruikmakend van generieke bedrijfstransactiepatronen uit Edukoppeling architectuur. Deze ‘atomaire’ patronen kunnen worden gecombineerd tot complexe, toepassingsspecifieke interactiepatronen.

Governance

Relaties met andere standaarden

  • UBV (zie ook onderdeel IBP)
  • Voor transparante intermediair, onweerlegbaarheid, en/of uitwisseling obv XML: toepassen Edukoppeling WUS-profiel
  • OOAPI: onduidelijk of Edukoppeling-rollen hierin onderkend worden
  • Inbedding in nationale (overheidsbrede) standaarden. Basis wordt gevormd door afspraken en voorschriften uit de landelijke API-strategie. Enige mate van ontkoppeling via MoSCoW-classificering.
  • Op p.6 wordt XML over REST niet toegestaan, volgens API-24 is het een eigen afweging (COULD).

Consistent.pngConsistent - REST-profiel wordt duidelijk gepositioneerd t.o.v. de bestaande WUS-profielen.

De tekst is onduidelijk over of XML over REST ‘verboden’ is, of ontraden wordt. Er zijn scenario’s waarin XML over REST wenselijk kan zijn, m.n. De overgang van WUS naar REST, waarbij bestaande XML-gegevensstructuren tijdelijk gehandhaafd blijven.

Afwijkingen op nationale afspraken zijn grotendeels beargumenteerd en niet in fundamentele tegenspraak.

Deze pagina is vastgesteld door Architectuurraad, op 29 oktober 2020.