Patroon voor federatie van identity management

Onderdeel van: Thema's
Contact: Guus van den Berg; Guus.vandenberg@cip-overheid.nl
Status: Dit thema wordt momenteel opnieuw bekeken door de Expertgroep Beveiliging

Context

Organisaties gaan steeds meer samenwerken en willen daarbij externe of interne gebruikers toegang bieden tot IT-middelen. Dit gebeurt al dan niet in combinatie met SSO (Single Sign-On). Ondersteuning van gezamenlijk identiteitengebruik wordt geregeld met Federated Identity Management.

Organisaties die identiteiten uitwisselen

Succesvolle implementatie van federatie van identiteiten biedt organisaties kansen, maar ook bedreigingen. De kansen zijn:

Mogelijkheden voor nieuwe efficiënte vormen van bedrijfsvoering
Verhogen van gebruikerstevredenheid en imago
Terugdringen van kosten en risico’s
Integratie met toepassingen van partnerorganisaties

Wanneer de verschillen in volwassenheid van IT-beheer en IT-voorzieningen echter groot zijn, dan dreigt het tegengestelde resultaat van kans 1, 2 en 3 te gebeuren.

Probleem

Problemen verbonden aan het wederzijds kunnen benaderen van gegevens van partners onderling, zijn te relateren aan de volgende thema’s:

Samenwerking. Om elkaars identiteiten te kunnen gebruiken moeten strategische keuzes worden gemaakt. Gebruiken we identiteitsgegevens van partners of bieden we partner(s) juist onze identiteitsgegevens aan?
Vertrouwen. Hoe kunnen organisaties identiteitsinformatie uitwisselen met partners, om real-time sessies en transacties betrouwbaar te laten verlopen, met behoud van hun eigen beveiligingsniveau?
Fusie. Het samenvoegen van grootschalige infrastructuren en informatiesystemen van verschillende organisaties blijkt in de praktijk extreem complex. Oorzaak is dat organisaties in de informatieverwerking en de keuzes van standaarden autonoom zijn gegroeid tot het moment dat besloten wordt om te fuseren. Knelpunten zijn verschillen in toegepaste standaarden, formulering van attributen etc.
SaaS. Voor gebruikers van organisaties die “Software as a Service” afnemen is het niet aanvaardbaar dat ze voor elke nieuwe service een ander gebruikersaccount nodig hebben. (Koppeling van SaaS leverancier met IAM processen van de klant is noodzakelijk.)

Oplossing

Samenwerken met identiteiten dwingt organisaties tot de volgende strategische keuzes:

Identiteiten te centraliseren in één centrale IdM store voor alle samenwerkende organisaties óf
Identiteiten uit te wisselen, met behoud van de eigen IdM.

Het principe voor centraliseren van identiteiten tussen organisaties is geschetst in onderstaande figuur. Minimaal zijn er twee organisaties (of onderdelen van organisaties) betrokken in een federatie. Eén van de organisaties heeft de rol van Identity Provider (IDP), waarmee dit de federatievariant is met één centrale IdM, uitgevoerd door de IDP. In dit voorbeeld is dat organisatie 1. De IDP geniet van de andere organisaties RP (Relying Party’s) het vertrouwen voor adequaat identiteitenbeheer. Organisatie 2 vervult hier enkel de rol van Service Provider (SP) voor de gebruiker(s) van beide organisaties, bijvoorbeeld voor een SaaS applicatie, maar die rol had net zo goed tevens door organisatie 1 vervuld kunnen worden. In een federatieve ‘wolk’ kan immers elke organisatie fungeren als service provider. Organisatie 3 is een RP, die enkel identiteiten afneemt van de IDP en IT-services van de SP.

Federatie met centrale IdM in de vorm van een identity provider (IDP)

De toegang tot services verloopt bij federatie steeds in de volgende 6 stappen:

Gebruiker (subject) authenticeert zich bij de identity provider.
IDP geeft een ‘identity-assertion’ bericht (een soort ticket) terug aan de gebruiker.
Gebruiker vraagt op basis van de uitgegeven identity-assertion de SP om content.
SP vraagt IDP om identiteitsgegevens op basis van de assertion.
IDP geeft de SP de identiteitsgegevens.
SP controleert of de identiteit geautoriseerd is en geeft de gebruiker toegang tot resources.

In plaats van de communicatie (4) en (5) via het z.g. background channel, te laten lopen, kan deze communicatie ook indirect via de gebruiker (RP). Voordeel hiervan is reductie van complexiteit omdat er dan geen extra communicatiekanaal nodig is. Om de identiteits/autorisatie gegevens in die opzet te beschermen, wordt encryptie of elektronische handtekeningen toegepast zoals gebeurt bij SAML en Kerberos.

Federatie met uitwisseling van identiteiten en behoud van eigen IdM

Onderstaande figuur schetst een eenvoudige architectuur, waarin medewerkers van een vertrouwde partnerorganisatie (federatieve) toegang kunnen krijgen tot een IT-middel van de eigen organisatie. Er is hier geen sprake van een seperate IDP en SP. Dit is de federatievariant, waarbij de organisaties identiteiten met elkaar uitwisselen. De organisaties zijn hier wederzijds zowel IDP als SP. Om dit te bewerkstelligen, wordt er eerst een System To System (STS) vertrouwensrelatie (trust) gedefinieerd tussen de Identity Federation Service van de Organisatie en de Identity Federation Service van de partner. In dat kader kunnen bijvoorbeeld afspraken gemaakt worden over (de betrouwbaarheid van) de te hanteren authenticatiemiddelen. De te hanteren betrouwbaarheidsniveaus zijn afhankelijk van de aard van de ontsloten dienst. De trust kan bijvoorbeeld worden gelegd door het Public Key Certificaat van de Identity Provider van de vertrouwde partij als vertrouwde bron op te nemen in de Federation Service van de eigen organisatie (pijl 13).

Federatieve toegang van de partner tot resources van de eigen organisatie

Op het moment dat de medewerker van de vertrouwde partij een IT-middel van de Organisatie wil gebruiken, genereert de Identity Federation Service van de vertrouwde partij een SAML-token waarmee de gebruiker toegang kan krijgen tot het middel van de partnerorganisatie. (pijl 14 en 15). Het Policy Enforcement Point vraagt vervolgens aan het Policy Decision Point of de toegang mag worden verleend (pijlen 8 t/m 11) en verleent vervolgens toegang (pijl 12).

Federatieve toegang van eigen organisatie tot resources van een vertrouwde partner

Ook hier wordt er eerst een vertrouwensrelatie (“Trust”) gedefinieerd tussen de Identity Federation Service van de organisatie en de Identity Federation Service van de vertrouwde partner. Deze trust wordt gelegd door het Public Key Certificaat van de Identity Provider van de Organisatie als vertrouwde bron op te nemen in de Federation Service van de vertrouwde partij (pijl 13).

Federatieve toegang eigen organisatie tot de vertrouwde partner

De (geauthenticeerde) medewerker van de organisatie vraagt bij de Identity Federation Service een (SAML) token aan voor het benaderen van IT-middel (pijlen 5 en 6). Met dit token verleent de organisatie haar medewerkers toegang tot IT-middelen van de vertrouwde partij (pijlen 16 en 17).

Basistopologiën voor federatie

Onderstaande figuur schetst drie basistopologieën voor federatie van identiteiten, ieder met zijn eigen karakteristieken en beperkingen.

In een Point-to-point topologie wisselen twee of meer organisaties identity assertions direct uit. Het aantal vertrouwensdomeinen (trust domains T) neemt echter snel toe: T = n * (n-1)/2, waarbij n het aantal trust domains is. Het opzetten en beheren van een trustdomain is kostbaar, zodat dit alleen een acceptabele oplossing is voor kleine aantallen deelnemende organisaties.
In een HUB-topologie fungeert de IDP als sterpunt. Organisaties (Relying Party’s) communiceren altijd via de hub. Voordeel van deze oplossing is de eenvoud. Belangrijke nadelen zijn dat slechts één organisatie Identity informatie in beheer heeft en de kwetsbaarheid voor de uitval van de centrale hub (single point of failure).
Een Netwerktopologie maakt federatie mogelijk voor grote aantallen organisaties. De federatieve configuratie kan meerdere hubs bevatten. Voordelen zijn dat organisaties hun identity informatie zelf veilig kunnen stellen en dat niet alle netwerkcommunicatie direct hoeft te verlopen. Er kunnen in het netwerk een aantal supernodes zijn ingericht om het aantal interconnecties en te beheren trustrelaties te beperken. Nadeel van deze topologie is complexiteit en formele afstemming van Id’s in het kader van de Wet Bescherming Persoonsgegevens (WBP).

Basistopologieën voor federatie met centrale IdM

Afwegingen

Organisaties die identiteiten willen delen moeten de volgende vragen meenemen in hun afweging:

Naleving: Welke wet- en regelgeving is voor wie van toepassing? Welke aansprakelijkheid is van toepassing in het geval van beveiligingsincidenten? Welke privacyregels zijn van toepassing?
Organisatiestructuur: Op welke wijze wordt IT bestuurd in de organisatie waarmee samengewerkt moet worden? Centraal- of decentraal? Wat is het niveau van autonomie tussen de verschillende eenheden van het betreffende concern waarmee identiteiten gedeeld worden? Welke rol spelen functionele, regionale of politieke verschillen tussen de aangesloten organisaties?
Eigenaarschap en beheer van Id-gegevens: Wie is de bewerker van Id-gegevens en waar wordt beheer van Id- gegevens belegd?
Bestaande applicaties: Er bestaan verschillende standaarden voor federatie van identiteiten. Sommige standaarden werken samen, anderen niet. Moeten applicaties en infrastructuur worden aangepast?
Volwassenheid van partners: De volwassenheid van organisaties op de relevante gebieden heeft een grote impact op de resultaten die bereikt kunnen worden t.a.v. van federatie van identiteiten. Wat is de volwassenheid van de procesvoering? Voorbeelden daarvan zijn: Is risicomanagement ingevoerd? Hoe zit het met de naleving van IB-beleid? Hoe volwassen zijn de IT voorzieningen?
Ontvlechting: Organisaties die (overwegen te) fuseren moeten strategisch vooruitkijken naar een mogelijke ontvlechting van complexe IdM en AM infrastructuur oplossingen.

Voorbeelden

Een aantal voorbeelden van Federatieve IdM-diensten zijn:

DigiD, de dienst voor IdM voor identificatie van de Nederlandse burger voor de e-Overheid.
eHerkenning, de dienst voor identificatie van personen in de relatie tussen de e-Overheid en organisaties.
EduRoam: internationaal werkende dienst voor Federated identity management binnen het hoger onderwijs.

Implicaties

De volgende algemene architectuurprincipes zijn van invloed op het ontwerp en de acceptatie van federatie-implementaties:

Mate van autonomie: Organisaties die niet afhankelijk willen zijn van andere organisaties zullen bij voorkeur niet een partner als identityprovider willen laten fungeren.
Technische volwassenheid: Organisaties die beproefde technologie eisen voor hun bedrijfsvoering, zullen de relatieve onvolwassenheid van federatie maar moeizaam kunnen accepteren. Technieken voor provisioning en uitwisseling van attributen bij federatie van identiteiten zijn nog volop in ontwikkeling.
Eigenaarschap, uitvoering, besturing en outsourcing: Federatie werkt als outsourcing. Federatie impliceert het opgeven van een zeker niveau van autonomie op besturing van identiteitenbeheer. Dit houdt in, dat je nog steeds zelf identiteitenbeheer uitvoert, maar afspraken maakt over toegang, waarbij je besluit om gebruikers van partnerorganisaties niet in je eigen identiteitenbeheer op te nemen!
Doorbelasting: Federatie van identiteiten kan het terugverdienen van IdM voorzieningen versnellen. Voor interne doorbelasting van IdM kan nu tevens een extern rekenmodel worden benut. Dit kan zowel positief als negatief uitvallen, afhankelijk van de afspraken die gemaakt zijn met de partners.

Gerelateerde patronen

Patroon voor identity management

Standaarden

SAML 2.0 is verreweg de meest breed gedragen Federated IdM-standaard, gelet op leveranciersproducten, ondersteuning van providers en eisen van gebruikers. Voor de helft van de implementaties worden Open Source producten toegepast.
XACML: eXtensible Access Control Markup Language. Dit is een taal voor het uitdrukken van regels voor toegangsverlening. Het definieert de gebruikte begrippen en bevat modellen en een beschrijving van architectuurcomponenten, waarop de modellen in het thema Logische Toegang van dit document zijn gebaseerd.