Federatie

Federatie staat de overdracht van autorisatie-instantie toe aan andere leden van een interprise. Denk bijvoorbeeld aan het volgende bedrijfsprobleem: het autoonderdelenproductiebedrijf Contoso Ltd wil geautoriseerde werknemers van de klant Fabrikam Inc toestaan om veilig toegang te krijgen tot de webservice voor onderdelenorders van Contoso. Een beveiligingsoplossing voor dit scenario is dat Contoso een vertrouwensmechanisme met Fabrikam instelt om de toegangsautorisatiebeslissing te delegeren aan Fabrikam. Dit proces kan als volgt werken:

• Fabrikam, wanneer het een partner van Contoso wordt, stelt een vertrouwensovereenkomst met Contoso in. Het doel van deze stap is om akkoord te gaan met het beveiligingstokentype en de inhoud die de autorisatie van Fabrikam vertegenwoordigt en die acceptabel is voor Contoso. Het kan bijvoorbeeld worden besloten dat een vertrouwd X.509-certificaat met de onderwerpnaam 'CN=Fabrikam Inc Supplier STS' een SAML-token moet ondertekenen voor die SAML die wordt geaccepteerd door de Contoso-webservice. Verder kan worden besloten dat de beveiligingsclaim in het uitgegeven SAML-token moet zijn: 'https://schemas.contoso.com/claims/lookup' (voor autorisatie voor gedeeltelijk zoeken) of 'https://schemas.contoso.com/claims/order' (voor autorisatie voor het bestellen van onderdelen).
• Wanneer een Fabrikam-werknemer gebruikmaakt van de toepassing voor het bestellen van interne onderdelen, neemt deze eerst contact op met een service voor beveiligingstokens (STS) in Fabrikam. Die werknemer wordt geverifieerd met behulp van het interne Fabrikam-beveiligingsmechanisme (bijvoorbeeld gebruikersnaam/wachtwoord voor Windows-domein), zijn autorisatie voor het bestellen van onderdelen wordt geverifieerd en hij krijgt een saml-token met de korte levensduur met de juiste claims en ondertekend door het X.509-certificaat dat hierboven is besloten. De onderdelenvolgordetoepassing neemt vervolgens contact op met de Contoso-service die het uitgegeven SAML-token presenteert om de ordertaak te verifiëren en uit te voeren.

Hier fungeert de Fabrikam STS als de 'uitgevende partij' en fungeert de Contoso-onderdelenservice als de relying party.

Federatiefuncties

Hier volgen de ondersteunde beveiligingsfuncties voor de partijen of rollen die betrokken zijn bij een federatiescenario:

• Clientzijde: Voor het verkrijgen van het beveiligingstoken van de STS kan een WsRequestSecurityToken functie gebruiken. U kunt ook een beveiligingstokenproviderbibliotheek aan de clientzijde gebruiken, zoals CardSpace of LiveID, en vervolgens hun uitvoer gebruiken om lokaal een beveiligingstoken te maken met behulp van WsCreateXmlSecurityToken. Hoe dan ook, zodra de client het beveiligingstoken heeft, kan het een kanaal maken naar de service die WS_XML_TOKEN_MESSAGE_SECURITY_BINDING opgeeft om het token te presenteren, samen met een transportbeveiligingsbinding zoals WS_SSL_TRANSPORT_SECURITY_BINDING om het kanaal te beveiligen.
• Serverzijde: In een federatiescenario met een beveiligingstokenservice waarmee SAML-tokens worden uitgegeven, kan de server de WS_SAML_MESSAGE_SECURITY_BINDINGgebruiken, samen met een transportbeveiligingsbinding zoals WS_SSL_TRANSPORT_SECURITY_BINDING om het kanaal te beveiligen.
• STS-side: de STS is een webservicetoepassing en kan de beveiligingsvereisten opgeven voor degenen die hiervoor een beveiligingstoken aanvragen met behulp van een beschrijving van de beveiliging structuur tijdens het maken van de listener, net zoals elke andere beveiligde webservice zou doen. Vervolgens kunnen binnenkomende aanvraag nettoladingen worden geparseerd om de tokenaanvragen te valideren en uitgegeven tokens als nettoladingen voor antwoordberichten te verzenden. Op dit moment zijn er geen functies beschikbaar om deze parserings- en uitgiftestappen te helpen.

Houd er rekening mee dat de clientzijde het uitgegeven beveiligingstoken algemeen kan verwerken als een XML-beveiligingstoken zonder het tokentype te kennen of om een specifieke verwerking van het tokentype uit te voeren. De server moet echter het specifieke type beveiligingstoken begrijpen om het te begrijpen en te verwerken. De aanvraag- en antwoordstappen voor het beveiligingstoken maken gebruik van de constructies die zijn gedefinieerd in de specificatie WS-Trust.

Complexere federatiescenario's

Een federatiescenario kan betrekking hebben op meerdere STS's die een federatieketen vormen. Bekijk het volgende voorbeeld:

• De client wordt geverifieerd bij de LiveID STS met behulp van een LiveID-gebruikersnaam/-wachtwoord en verkrijgt een beveiligingstoken T1.
• Client wordt geverifieerd bij STS1 met behulp van T1 en verkrijgt een beveiligingstoken T2.
• De client wordt geverifieerd bij STS2 met behulp van T2 en verkrijgt een beveiligingstoken T3.
• De client wordt geverifieerd bij de doelservice S met behulp van T3.

Hier vormen de LiveID STS, STS1, STS2 en S de federatieketen. De STSs in een federatieketen kunnen verschillende rollen uitvoeren voor het algemene toepassingsscenario. Voorbeelden van dergelijke functionele STS-rollen zijn id-provider, autorisatiebeslissingsmaker, anonimisering en resourcemanager.

STS-aanvraagparameters en metagegevensuitwisseling

Om de client een geslaagde WsRequestSecurityToken aanroep te laten maken, moet deze de parameters van die aanroep (zoals het vereiste tokentype en claimtypen) kennen, de beveiligingsbeschrijving vereisten van het aanvraagkanaal naar de STS en het eindpuntadres van de STS. De clienttoepassing kan een van de volgende technieken gebruiken om deze informatie te bepalen:

• Codeer de informatie in de toepassing als onderdeel van de ontwerptijdbeslissingen.
• Lees deze informatie uit een configuratiebestand op toepassingsniveau dat is ingesteld door de lokale toepassings deployer.
• Detecteer deze informatie dynamisch tijdens runtime met behulp van de -functie voor het importeren van metagegevens met de WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT structuur.

Bekijk het bovenstaande 3 STS-voorbeeld om het gebruik van dynamische MEX met federatie te illustreren. De client doet eerst een dynamische MEX met S om informatie te verkrijgen over T3 (d.w.z. wat te vragen van STS2) en het dynamische MEX-adres van STS2 (d.w.z. waar STS2 te vinden). Vervolgens wordt die informatie gebruikt om een dynamische MEX met STS2 uit te voeren om informatie over T2 en STS1, enzovoort te ontdekken.

De dynamische MEX-stappen vinden dus plaats in de volgorde 4, 3, 2, 1 om de federatieketen op te bouwen en de tokenaanvraag- en presentatiestappen vinden plaats in de volgorde 1, 2, 3, 4 om de federatieketen te wikkelen.