KNF:Multi-Tenant-SAML-SP

Binnen Entree Federatie heeft iedere Service Provider een eigen unieke identifier, het entityID. Dit entityID staat beschreven in de metadata van de Service Provider, samen met onder andere Wanneer een dienst koppelt met de Entree Federatie, wordt deze dienst als SAML SP geregistreerd. Een van de kenmerken van een SAML SP, is dat deze een unieke identiteit heeft (de EntityID) en een URL ter beschikking stelt met de SAML-metadata die de technische specificatie van de dienst als SAML systeem beschrijft.

Wanneer een dienst zodanig is ingericht, dat het bestaat uit meerdere diensten die in principe onafhankelijk van elkaar functioneren, dan zijn er een aantal mogelijkheden om deze diensten aan te sluiten op de Entree Federatie. Het uitgangspunt van deze mogelijkheden, is dat elke partij zoveel mogelijk zijn eigen verantwoordelijkheid kan nemen.

In bovenstaande figuur is de architectuur geschetst van de situatie waarvoor onderstaande oplossingen zijn bedoeld. SP1-a .. SP1-z verwijzen naar de verschillende uitvoeringen van een dienst SP1, die allemaal binnen hetzelfde administratieve domein van een dienst vallen, maar niet in hetzelfde technische domein worden uitgevoerd.

Optie 1: Service Provider is de Identity Provider proxy voor het eigen domein

In deze oplossing maakt de dienst SP1 een koppeling met Entree Federatie en zorgt SP1 ervoor dat de systemen SP1-a, SP1-b, etc. een identiteit geleverd krijgen van SP1. De dienst SP1 fungeert hiermee als een IDP Proxy.

Om deze oplossing te realiseren, maakt Kennisnet een afspraak met de dienst en wordt er een technische koppeling gerealiseerd tussen Entree Federatie en de Identity Provider Proxy van de dienst als Service Provider. De dienst kan nu een eigen administratie uitvoeren voor wat betreft het koppelen van de uitvoeringen van haar eigen dienst.

Voordelen van deze oplossing zijn:

1. Kennisnet registreert één dienst en heeft dus precies één koppeling te onderhouden met de dienst
2. De dienst bepaalt of er een nieuwe dienst SP1-x wordt toegevoegd, zonder dat het hierbij afhankelijk is van Kennisnet

Deze oplossing heeft de voorkeur van Kennisnet. Er wordt nog gewerkt aan een standaard document met basis instructies hoe een IDP Proxy te realiseren op basis van diverse open source applicaties.

Optie 2: Alle klanten van de dienst worden door Kennisnet geadministreerd

In deze oplossing zal Kennisnet elke klant SP1-a, SP1-b, etc van een dienst SP1 apart administreren. De dienst meldt elke nieuwe omgeving hiervoor aan Kennisnet, en voorziet Kennisnet van de vereiste gegevens (naam klant, URL van de SAML metadata van de omgeving, etc).

Om deze oplossing te realiseren, moet Kennisnet elke omgeving van de dienst SP1 apart gaan registreren.

Voordelen zijn:

1. Het lijkt een simpele manier van koppelen

Nadelen zijn:

1. Het is niet schaalbaar
2. Kennisnet voert een deel van de administratie waarvoor de dienst verantwoordelijk is
3. Dienst introduceert een afhankelijkheid van de administratie van Kennisnet
4. Dienst heeft geen overzicht op hoe de omgevingen zijn gekoppeld