KNF:Multi-Tenant-SAML-SP: verschil tussen versies
| Regel 20: | Regel 20: | ||
#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 |
||
| − | [[Categorie:Kennisnet Federatie]] |
||
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. |
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: 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 Entree 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 Entree 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: |
||
| − | |||
| − | <syntaxhighlight lang="xml"> |
||
| − | <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> |
||
| − | </syntaxhighlight> |
||
| − | |||
| − | |||
| − | Een AuthnRequest dient de de juiste URL expliciet mee te geven: |
||
| − | |||
| − | <syntaxhighlight lang="xml"> |
||
| − | <samlp:AuthnRequest |
||
| − | … |
||
| − | AssertionConsumerServiceURL="https://sp1-b.sp1.nl/acs" |
||
| − | ... |
||
| − | > |
||
| − | ... |
||
| − | </samlp:AuthnRequest> |
||
| − | </syntaxhighlight> |
||
| − | |||
| − | |||
| − | '''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 83: | Regel 38: | ||
#Dienst introduceert een afhankelijkheid van de administratie van Kennisnet |
#Dienst introduceert een afhankelijkheid van de administratie van Kennisnet |
||
#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. |
||
| − | |||
| − | Een koppeling waarbij Kennisnet de aparte omgevingen van een klant als aparte diensten administreert, is niet gewenst. |
||
Versie van 31 jul 2018 13:05
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: SAML SP is IDP proxy voor eigen domein
In deze oplossing sluit de dienst SP1 aan als SAML SP 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 de Entree Federatiehub als IDP en de IDP Proxy van de dienst als SP. 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. 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:
- 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