Als een vierde instelling nu van deze dienst gebruik zou willen maken, dan zou ook voor deze instelling aparte (virtuele) hardware ingezet worden, waar opnieuw de applicaties op worden geïnstalleerd, waarbinnen een nieuwe kopie van de software van de leverancier wordt gemaakt. Allemaal specifiek voor deze vierde instelling.

Single-tenancy en delen van resources

Naast het strikt scheiden van de resources voor verschillende instellingen is het ook mogelijk bepaalde resources te delen. Dat betekent dat verschillende lagen door meerdere tenants gedeeld kunnen worden, zonder dat dit invloed heeft op de perceptie van de eindgebruiker, die zijn gegevens alleen met zijn eigen groep kan delen.

De leverancier zal vaak uit een efficiëntie-oogpunt bepalen welke lagen wel en niet gedeeld worden. Het ligt hier voor de hand om juist generieke lagen te delen, terwijl de applicatie-specifieke lagen los van elkaar blijven bestaan. Behoud van afscherming van de data tussen de verschillende tenants blijft in alle gevallen centraal staan.

Multi-tenancy

Het ultieme delen van resources tussen verschillende groepen wordt bereikt als vervolgens ook de presentatielaag wordt gedeeld tussen alle groepen gebruikers. Daarna vervalt ook de eigen dienstingang voor iedere groep afzonderlijk. Precies dat wordt bereikt met multi-tenancy.

Men spreekt van multi-tenancy als verschillende groepen gebruikers van dezelfde dienst gebruik maken, waarbij de groepen van elkaar afgeschermd zijn en alleen met eigen gegevens werken. Dan ziet de architectuur er zo uit:

Als in dit geval een vierde instelling gebruik wil maken van de dienst, dan hoeft daar aan de kant van de leverancier vaak heel weinig te gebeuren. Het komt meestal neer op een aanpassing van de configuratie van het systeem en de vierde instelling kan van start.

Architectuur afwegingen

Single- en multi-tenant architecturen hebben hun eigen voor- en nadelen. Er zijn verschillende gezichtspunten die de voorkeur bepalen voor de één of andere architectuur. Er zijn technologische afwegingen te maken op de volgende gebieden:

1. Flexibiliteit:

• • In een single-tenant architectuur kan flexibel opgetreden worden. Omdat een wijziging in de hardware of software van de ene tenant geen impact heeft op de andere instanties. Dit geeft volledige vrijheid in maatwerk voor een instelling. Het aanbieden van deze flexibiliteit geeft echter een grote beheerslast voor de leverancier.
  • Overigens is deze flexibiliteit ook te realiseren in een multi-tenant omgeving zoals in het laatste hoofdstuk van dit artikel beschreven wordt. Dit vergt meer initiële softwareontwikkeling aan de kant van de leverancier, maar uiteindelijk minder beheerslast.

2. Beveiliging:

• Een single-tenant architectuur wordt als veiliger gezien, voornamelijk omdat de data van de instellingen in aparte databases wordt opgeslagen en dus niet gemixt kan worden.
• Daarentegen is het een multi-tenant softwareleverancier er alles aangelegen om de data goed te beveiligen. Juist doordat er in deze omgeving meer aandacht voor beveiliging is, kan dat voordelig uitpakken.

3. Upgrades en releasemanagement:

• In een single-tenant opstelling kunnen upgrades individueel per tenant worden uitgerold.
• In een multi-tenant architectuur is een upgrade van de hardware en/of software meteen voor alle partijen actief. De partijen profiteren dus allemaal van de ontwikkeling. Dit heeft als nadeel dat er geen ruimte is voor individuele releases.

4. Migratie en beschikbaarheid:

• Een single-tenant architectuur is relatief makkelijk te back-uppen en te migreren naar een andere locatie, zelfs vanuit de cloud terug naar on-premise.
• Een multi-tenant architectuur is als geheel in de cloud te migreren naar een andere locatie. Een verhuizing vanuit de cloud naar on-premise is vaak onmogelijk. Bij een multi-tenant architectuur is vaak meer aandacht voor beschikbaarheid, omdat de impact van een storing groot is en alle tenants erbij betrokken zijn.

5. Schaalbaarheid en efficiëntie:

• Een single-tenant architectuur is wel schaalbaar, maar niet efficiënt, omdat voor iedere tenant afzonderlijk alles opnieuw moet worden geregeld.
• Voor de leverancier is het onderhouden van een multi-tenant architectuur beter schaalbaar en efficiënter dan een single-tenant architectuur. Dat komt omdat de verschillende instanties profiteren van elkaars capaciteit.

Leveranciers van clouddiensten leveren in toenemende mate multi-tenant architecturen omdat schaalbaarheid & efficiëntie (5) en upgrades & releasemanagement (3) in deze omgeving veel eenvoudiger te realiseren zijn. Daarnaast is er veel aandacht voor flexibiliteit (1) en beveiliging (2), waardoor de kosten voor softwareontwikkeling in eerste instantie hoger zullen zijn, maar dat wordt op termijn weer bespaard door het delen van resources. Migratie (4) speelt voor een leverancier van een clouddienst een minder belangrijke rol, maar de nadruk ligt meer op beschikbaarheid.

Met SURFconext de gebruikersgroep herkennen

SURFconext maakt koppelingen tussen instellingen (IdP’s) en leveranciers van diensten (SP’s). Deze koppelingen zijn verschillend bij gebruik van een single- of multi-tenant dienst.

In een single-tenant omgeving is de gebruiker eenvoudig te herkennen, want dan koppelt SURFconext alleen de betreffende IdP aan de dienst, waardoor alleen gebruikers van die instelling bij de dienst kunnen inloggen. Dit betekent dat SURFconext voor iedere single-tenant een aparte IdP- en SP-koppeling moet maken. Wat resulteert in veel koppelingen en een hoge beheerslast bij SURFconext en bij de leverancier van de dienst. 

In een multi-tenant omgeving worden door SURFconext meerdere IdP's aan één dienst gekoppeld. De kunst voor de SP is om in een multi-tenant omgeving de gebruiker die aan de deur klopt te herkennen, indien noodzakelijk. Dat kan met de door SURFconext meegegeven attributen van een gebruiker. Bijvoorbeeld het attribuut: 'schacHomeOrganization' voor het identificeren van de instelling of met 'eduPersonPrincipalName' voor het uniek identificeren van gebruikers per instelling. Op basis van deze attributen kan de software bepalen tot welke groep de gebruiker behoort. In een multi-tenant omgeving is de groep dus eenvoudig te herkennen aan de hand van attributen van de gebruiker.

Een dienst kan ook gebruik maken van externe groepsinformatie, uit SURFconext Teams of rechtstreeks uit de ‘Group Provider’ van de instelling. Deze informatie kan worden gebruikt om autorisatiebeslissingen te nemen. De dienst kan lidmaatschap van een gebruiker van een bepaalde groep opvragen via de VOOT API. Zo kan aan leden van een bepaalde groep toegang gegeven worden tot een bepaald onderdeel binnen de dienst.

Voordelen van een multi-tenant omgeving binnen SURFconext

Het voordeel van een multi-tenant omgeving voor SURFconext, de leverancier én voor de instelling is dat SURFconext een nieuwe instelling snel en eenvoudig (middels één configuratiehandeling) kan koppelen aan een al bestaande SP. Hiervan is ook al bewezen dat deze werkt; immers, andere tenants maken reeds gebruik van dezelfde omgeving.

Terwijl voor iedere nieuwe single-tenant dienst een nieuwe SP moet worden ingericht door de leverancier en een nieuwe koppeling moet worden gemaakt door SURFconext. Daar gaat veel meer ontwikkeltijd en testtijd overheen.

Een multi-tenant SP kan dus veel sneller in gebruik worden genomen en daardoor sneller groeien, terwijl de effort om een gebruiker te herkennen in de software relatief klein is.

Specifieke SURFconext gebruikersgroepen in een multi-tenant omgeving

Flexibiliteit wordt vaak gezien als een voordeel van de single-tenant omgeving. In eerste instantie lijkt dat misschien zo, maar een volwassen multi-tenant omgeving kan met de eigen software dezelfde flexibiliteit bieden. Dat komt doordat de gebruiker die binnenkomt te herkennen is aan de attributen van zijn instelling en/of de groepen waar hij lid van is.

Op basis van attributen en groepslidmaatschap kunnen verregaande autorisatiebeslissingen in de software genomen worden. Zo kan bijvoorbeeld een aparte interface getoond worden voor mensen van een bepaalde instelling in de presentatielaag. Maar ook kan een bepaalde groep mensen extra functionaliteit krijgen in de businesslaag. Denk hierbij aan het verschil tussen een medewerker en een student wat tot uiting komt in het 'eduPersonAffiliation' of het 'eduPersonScopedAffiliation' attribuut. Zelfs kunnen aparte databases aangeroepen worden in de databaselaag op basis van attributen. Zie de volgende figuur voor wat er kan gebeuren binnen een laag. De kleuren geven respectievelijk de gescheiden interfaces, functionaliteiten & databases aan voor de doelgroepen.

Juist door in software gebruikersgroepen te onderscheiden op basis van attributen en groepen kan een specifiekere groepsvorming in de applicatie gerealiseerd worden. De attributen die een leverancier kan gebruiken worden beschreven in de SURFconext Wiki. Kijk hier voor meer informatie over attributen en over het opvragen van attributen en groepslidmaatschap in SURFconext:

• Attributen in SURFconext (NL)
• IdP Discovery - WAYF
• VOOT definition

Methoden om een SP multi-tenant te maken

• Allereerst kan de dienst zoals hierboven beschreven inherent multi-tenant ontworpen worden, zodat er ook werkelijk een gedeelde infrastructuur is waarop de verschillende klanten draaien. Er is één SP die attributen gebruikt om bepaalde klanten te identificeren.
• Indien een dienst toch uit verschillende instanties voor verschillende klanten bestaat, kan men de authenticatie-component centraliseren binnen het platform, waar alle instanties gebruik van maken. Eventueel kan gebruik gemaakt worden van de mogelijkheid om verschillende ACS-locaties voor één SP te definiëren zodat verschillende URL's gebruikt kunnen worden met dezelfde metadata.
• Men kan zelf een Service Provider proxy installeren die als één aansluiting richting SURFconext functioneert, en zelf de verschillende instanties intern bedient.