Page tree
Skip to end of metadata
Go to start of metadata

An English version of this article is available here: Use of single-tenant and multi-tenant services in SURFconext.

Inleiding

De diensten die op SURFconext aangesloten worden, zijn vaak clouddiensten van externe leveranciers. Deze leveranciers leveren deze diensten over het algemeen als SaaS, Software-as-a-Service. De leverancier bekommert zich om de infrastructuur, applicaties en software van de dienst zodat de instelling hier geen omkijken naar heeft. De gebruiker van de instelling krijgt vervolgens toegang tot deze software, afgeschermd door SURFconext.

Leveranciers maken hun dienst beschikbaar voor één of meerdere instellingen en kunnen daarbij verschillende architecturen gebruiken. Dit artikel beschrijft de mogelijkheden voor dienstaanbieders om een SaaS-dienst schaalbaar aan instellingen aan te bieden via SURFconext.

Een op SURFconext aangesloten instelling die een eigen instellingsdienst aan SURFconext wil koppelen kan ook gebruik maken van de technologieën die in dit artikel worden besproken. Al zal dit alleen relevant zijn als deze dienst ook aan meerdere instellingen wordt aangeboden.

Wat betekenen single-tenant en multi-tenant eigenlijk?

Een tenant is een groep gebruikers met dezelfde toegangsrechten tot bepaalde software. Een single-tenant dienst is een dienst of software instantie waar maar één groep gebruikers toegang toe heeft. Een multi-tenant dienst is een dienst waar meerdere groepen gebruikers toegang toe hebben. In een multi-tenant dienst gebruiken deze groepen ieder hun eigen deel van de software en de onderliggende database enzovoorts. De verschillende groepen zijn van elkaar afgeschermd en zien elkaars gegevens niet. Daardoor lijkt de multi-tenant dienst voor elke groep afzonderlijk ook een aparte dienst. Dit wordt verder in een volgende paragraaf uitgelegd.

Let op, hier wordt toegang tot de dienst bedoeld, i.t.t. toegangsrechten binnen de dienst. Er kan sprake zijn van verschillende rollen binnen dezelfde tenant, bijvoorbeeld een beheerder die meer rechten heeft dan een reguliere gebruiker.

Binnen SURFconext is een aangesloten instelling een voorbeeld van een tenant. Een single-tenant dienst wordt dan ingericht voor één specifieke instelling. Mediasite is bijvoorbeeld zo een single-tenant dienst. Deze videodienst geeft een instelling de mogelijkheid om een eigen versie van het videoplatform in gebruik te nemen. SURFconext koppelt de instelling aan deze versie van het videoplatform en zo wordt toegang geregeld voor één tenant.

Van een multi-tenant dienst kunnen meerdere instellingen gebruik maken. De multi-tenant dienst kan de groepen op verschillende manieren herkennen:

(1) De standaard manier is dat SURFconext alle instellingen naar één multi-tenant dienst verwijst. Dan zal de gebruiker, voordat hij kan inloggen op de dienst, een keuze moeten maken van welke instelling hij komt. Hij krijgt dan een ‘WAYF’ (Where Are You From) scherm te zien waar hij zijn instelling kan kiezen. Nadat de gebruiker is ingelogd, krijgt de dienst de beschikking over verschillende gegevens van de gebruiker (in de vorm van attributen; op deze Wiki-pagina vind je meer informatie over attributen op basis waarvan de dienst de gebruiker kan indelen in groepen.

De dienst kan nu strikt een scheiding aanbrengen tussen gebruikers van verschillende instellingen, zodat de het lijkt alsof de dienst specifiek voor één instelling is.

De meeste multi-tenant diensten zijn echter flexibeler ingericht en kunnen ook instellingsoverstijgend samenwerken faciliteren. EDUgroepen maakt het bijvoorbeeld mogelijk om met een instellingsaccount in te loggen en met mensen van je eigen instelling een groep (of team) te vormen. Maar vervolgens kan ook aan medewerkers van andere instellingen toegang gegeven worden tot documenten in de dienst. Deze extra toegang kan gegeven worden op individuele basis of op basis van groepen uit SURFconext Teams.

(2) Een andere, minder voorkomende optie is dat via SURFconext een instelling direct aan een bestaande groep binnen de multi-tenant dienst wordt gekoppeld. Een voorbeeld hiervan is Google Apps for Education. De groep wordt door het subdomein herkend; de URL van SURFnet is bijvoorbeeld: google.com/a/apps.surfnet.nl. Daar hebben alleen medewerkers van SURF toegang toe. Andere instellingen krijgen een ander subdomein.

Merk op dat dit voor de ‘buitenwereld’ gewoon een single-tenant dienst is. SURFconext ziet ieder subdomein als een aparte dienst en maakt directe koppelingen tussen de instelling en de dienst.

Een Service Provider bepaalt zelf hoe gebruikers kiezen welke instelling zij willen gebruiken voor het inloggen. SURFconext biedt standaard een WAYF-pagina aan. Hier hoeft een Service Provider niets voor te doen. Een Service Provider kan echter ook kiezen om een eigen WAYF-pagina te maken, of specifieke login-pagina’s voor elke instelling. Het maakt hierbij niet uit of de dienst single- of multi-tenant is. Op deze Wiki-pagina staat uitgelegd hoe dat werkt.

Single-tenancy en de basisarchitectuur

Om SaaS aan te bieden heeft de leverancier met verschillende componenten te maken. Voor deze uitleg worden deze onderverdeeld in drie lagen:

  • De (virtuele) hardwarelaag. Dat zijn de fysieke (of virtuele) servers die de leverancier gebruikt om de applicaties op te hosten. Voor de eenvoud wordt in dit verhaal ook het netwerk en de fysieke locatie onder deze hardwarelaag verstaan.
  • De generieke applicatielaag. Dat zijn de applicaties die de leverancier gebruikt waarbinnen zijn software draait. Denk daarbij aan applicaties zoals een webserver.
  • De dienst/eigen softwarelaag. Dat is de software van de leverancier die de specifieke dienst levert. Deze laag is ook weer onderverdeeld in drie lagen:
    • De databaselaag. Dat is de laag waar de data wordt opgeslagen.
    • De businesslaag. Dat is de laag waarin de data wordt verwerkt. Deze laag bepaalt de functionaliteiten van de dienst.
    • De presentatielaag. Dat is de laag waarin de data wordt gepresenteerd, bijvoorbeeld in de vorm van HTML in een browser of een app.

In een single-tenant architectuur heeft iedere groep gebruikers een eigen instantie van al deze lagen. Voor een dienst die door drie instellingen afzonderlijk wordt gebruikt ziet dat er zo uit:

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:

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.
  • No labels