KNF:Multi-Tenant-SAML-SP: verschil tussen versies
Naar navigatie springen
Naar zoeken springen
| (17 tussenliggende versies door 3 gebruikers niet weergegeven) | |||
| Regel 1: | Regel 1: | ||
| + | __TOC__ |
||
| − | ==Multi-Tenant SAML SP Koppeling met Kennisnet Federatie== |
||
| + | Binnen Entree Federatie heeft iedere Service Provider een eigen unieke identifier. Deze identifier of '''entityID''' staat beschreven in de metadata van de Service Provider. |
||
| − | Wanneer een dienst koppelt met de Kennisnet 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 |
+ | 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. |
[[afbeelding:multi1.png]] |
[[afbeelding:multi1.png]] |
||
| Regel 9: | Regel 9: | ||
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. |
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 |
+ | 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. |
[[afbeelding:multi2.png]] |
[[afbeelding:multi2.png]] |
||
| − | Om deze oplossing te realiseren, maakt Kennisnet een afspraak met de dienst |
+ | 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: |
+ | '''Voordelen van deze oplossing zijn:''' |
#Kennisnet registreert één dienst en heeft dus precies één koppeling te onderhouden met de dienst |
#Kennisnet registreert één dienst en heeft dus precies één koppeling te onderhouden met de dienst |
||
#De dienst bepaalt of er een nieuwe dienst SP1-x wordt toegevoegd, zonder dat het hierbij afhankelijk is van Kennisnet |
#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 |
+ | Deze oplossing heeft de voorkeur van Kennisnet. |
| ⚫ | |||
| − | ===Optie 2: Dienst levert SAML SP Metadata met verschillende SAML AssertionConsumerService URLs=== |
||
| − | Indien er geldige redenen zijn waardoor de IDP Proxy oplossing niet mogelijk is, is het mogelijk dat de dienst gebruik maakt van de SAML Metadata om aan te geven op welke verschillende domeinen een identiteit kan worden afgeleverd. De SAML Metadata wordt door de dienst op één plaats beschikbaar gesteld aan de Kennisnet Federatie. |
||
| − | Bij het versturen van een SAML authenticatieverzoek, geeft de dienst vervolgens aan, aan welke URL het antwoord moet worden verstrekt. |
||
| − | [[afbeelding:multi3.png]] |
||
| − | |||
| − | Om deze oplossing te realiseren, maakt Kennisnet een afspraak met de dienst, en wordt er een technische koppeling gerealiseerd tussen de Kennisnet Federatiehub als IDP op basis van de metadata die door de dienst op 1 locatie op een HTTPS URL wordt aangeboden. De dienst zorgt ervoor dat de AssertionConsumerService URLs van alle diensten SP1-a, SP1b, etc. hierin zijn opgenomen: |
||
| − | |||
| − | <SPSSODescriptor …> |
||
| − | ... |
||
| − | <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp1-a.sp1.nl/acs" index="0"/> |
||
| − | <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp1-b.sp1.nl/acs" index="1"/> |
||
| − | … |
||
| − | <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp1-z.sp1.nl/acs" index="n"/> |
||
| − | … |
||
| − | </SPSSODescriptor> |
||
| − | |||
| − | Een AuthnRequest dient de de juiste URL expliciet mee te geven: |
||
| − | |||
| − | <samlp:AuthnRequest |
||
| − | … |
||
| − | AssertionConsumerServiceURL="https://sp1-b.sp1.nl/acs" |
||
| − | ... |
||
| − | > |
||
| − | ... |
||
| − | </samlp:AuthnRequest> |
||
| − | |||
| − | |||
| − | |||
| − | Voordelen zijn |
||
| − | #Kennisnet registreert één dienst en heeft dus precies één koppeling te onderhouden met de dienst |
||
| − | #De dienst heeft zelf controle over de technische domeinen waarop een identiteit kan worden afgeleverd |
||
| − | |||
| − | Nadelen zijn |
||
| − | #Alle SAML SPs moeten dezelfde secret key delen voor het ondertekenen van SAML2 berichten |
||
| − | #Er is per definitie géén Single Logout meer mogelijk |
||
| − | |||
| − | De nadelen zijn gebaseerd op het feit dat het SAML protocol geforceerd wordt in een situatie waar het eigenlijk niet voor bedoeld is. Als zodanig is deze oplossing eigenlijk alleen acceptabel als tussenoplossing naar de IDP Proxy oplossing. |
||
| − | |||
| ⚫ | |||
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). |
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). |
||
| Regel 68: | Regel 31: | ||
Om deze oplossing te realiseren, moet Kennisnet elke omgeving van de dienst SP1 apart gaan registreren. |
Om deze oplossing te realiseren, moet Kennisnet elke omgeving van de dienst SP1 apart gaan registreren. |
||
| − | Voordelen zijn: |
+ | '''Voordelen zijn:''' |
#Het lijkt een simpele manier van koppelen |
#Het lijkt een simpele manier van koppelen |
||
| − | Nadelen zijn: |
+ | '''Nadelen zijn:''' |
#Het is niet schaalbaar |
#Het is niet schaalbaar |
||
#Kennisnet voert een deel van de administratie waarvoor de dienst verantwoordelijk is |
#Kennisnet voert een deel van de administratie waarvoor de dienst verantwoordelijk is |
||
| Regel 77: | Regel 40: | ||
#Dienst heeft geen overzicht op hoe de omgevingen zijn gekoppeld |
#Dienst heeft geen overzicht op hoe de omgevingen zijn gekoppeld |
||
| − | Deze wijze van koppelen is door Kennisnet niet gewenst. |
||
| − | |||
| − | ===Conclusie=== |
||
| − | Een koppeling van een dienst, die meerdere omgevingen heeft, wordt bij voorkeur uitgevoerd op basis van een IDP Proxy architectuur. Indien er geldige redenen zijn waardoor dit (nog) geen optie is, kan tijdelijk worden teruggevallen op een oplossing gebaseerd op de ACS URLs, echter deze oplossing zal Kennisnet alleen dan willen wanneer er zicht is op een oplossing gebaseerd op een IDP Proxy. |
||
| + | [[Categorie:Entree Federatie]] |
||
| − | Een koppeling waarbij Kennisnet de aparte omgevingen van een klant als aparte diensten administreert, is niet gewenst. |
||
Huidige versie van 11 apr 2019 om 07:00
Binnen Entree Federatie heeft iedere Service Provider een eigen unieke identifier. Deze identifier of entityID staat beschreven in de metadata van de Service Provider.
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:
- Kennisnet registreert één dienst en heeft dus precies één koppeling te onderhouden met de dienst
- 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.
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:
- Het lijkt een simpele manier van koppelen
Nadelen zijn:
- Het is niet schaalbaar
- Kennisnet voert een deel van de administratie waarvoor de dienst verantwoordelijk is
- Dienst introduceert een afhankelijkheid van de administratie van Kennisnet
- Dienst heeft geen overzicht op hoe de omgevingen zijn gekoppeld