Document toolboxDocument toolbox

AB.013 - Multitenancy

Multitenancy

We maken multitenancy voor stelselcomponenten mogelijk

Multitenancy

We maken multitenancy voor stelselcomponenten mogelijk

Status

vervallen - Is multitenancy een implementatie keuze of iets wat we moeten (willen) standaardiseren?

Context

  • Voorziening componenten van een leverancier kunnen meerdere domeinen bedienen

  • Dit kan door per domein instanties van voorziening componenten te installeren

  • Dit kan ook door voor een groep domeinen enkelvoudige instanties van voorziening componenten te installeren. Deze component en zijn dan multitenant (ze huizen meerdere domeinen)

  • Een component moet het domein kunnen herkennen, dat het domein aanspreekt, op een veilige manier aan de service verzoeken van de domein kunnen voldoen en loggegevens per domein kunnen vasthouden.

  • Dit vereist identificatie van het domein bij aanroep van de stelsel component service

Besluit

  • Er wordt rekening gehouden met multitenant voorziening componenten door in relevante URL’s een positie voor de TenantId te reserveren

  • Voorziening componenten zijn zelf verantwoordelijk voor veilige het uitvoeren van de gevraagde service via de URL’s

  • Het voorziening component FHIR Store borgt dat gegevens van tenants niet worden gemixed , tenant data van andere tenants niet kunnen opvragen of zien en foutafhandeling per tenant plaats vindt

  • De voorziening component domeinlogging borgt dat logging per tenant plaats vindt en ook de foutafhandeling en logging van fouten per tenant plaats vindt .

  • De voorziening component autorisatie server borgt dat autorisaties per tenant vastliggen , niet worden gemixed of door andere tenants kunnen worden gelezen en datbij het vrijgeven van autorisaties dit op basis van de tenant informatie gebeurt.

Consequenties

  • DEV: In de referentie implementatie maken we geen gebruik van tenants . De keuze voor één instantie met mutitenants of meerdere fysiek gescheiden instanties per koppeltaaldomein is aan de leverancier(s) van de stelsel componenten. Het enige wat we in de standaard afdwingen is een positie voor de tenant in de relevante URL’s, i.v.m. consistentie en het gebruik van de waarde van die positie in logging en foutafhandeling.

Aandachtpunten 2.x

  • In de gaten blijven houden of dit wellicht ooit een relevant onderwerp voor standaardisatie wordt.

Bevinding en vraag aan visiegroep door lead architect

Bevinding en vraag aan visiegroep door lead architect

Ik begrijp zelf dit besluit niet zo goed. Multi-tenancy is een implementatie oplossing en we hebben juist afgesproken dat we ons vanuit de standaard niet met implementatiekeuzes bemoeien. Logische scheiding wordt daarnaast al geborgd via PvE non-functional nr. 24: Niet-Functionele eisen voor voorziening#(Virtueel)Gescheidenomgevingen

update: Ieder domein krijgt voor aansluiting op de voorziening een eigen unieke url toegewezen.