Dela via

Federation

  • Artikel

Federation tillåter delegering av auktoriseringsbehörighet till andra medlemmar i ett interpris. Tänk till exempel på följande affärsproblem: Bildelstillverkningsföretaget Contoso Ltd vill tillåta auktoriserade anställda hos kunden Fabrikam Inc att på ett säkert sätt få åtkomst till Contosos webbtjänst för delbeställningar. En säkerhetslösning för det här scenariot är att Contoso konfigurerar en förtroendemekanism med Fabrikam för att delegera beslutet om åtkomstauktorisering till Fabrikam. Den här processen kan fungera på följande sätt:

  • Fabrikam, när det blir partner till Contoso, skapar ett förtroendeavtal med Contoso. Målet med det här steget är att komma överens om vilken typ av säkerhetstoken och innehåll som ska representera Fabrikams auktorisering och som kan godkännas av Contoso. Det kan till exempel beslutas att ett betrott X.509-certifikat med ämnesnamnet "CN=Fabrikam Inc Supplier STS" ska signera en SAML-token för att SAML ska accepteras av Contoso-webbtjänsten. Vidare kan det beslutas att säkerhetsanspråket i den utfärdade SAML-token ska vara antingen "https://schemas.contoso.com/claims/lookup" (för en del uppslagsauktorisering) eller "https://schemas.contoso.com/claims/order" (för delbeställningsauktorisering).
  • När en Fabrikam-anställd använder det interna beställningsprogrammet för delar kontaktar den först en säkerhetstokentjänst (STS) i Fabrikam. Den anställde autentiseras med hjälp av den interna Fabrikam-säkerhetsmekanismen (till exempel användarnamn/lösenord för Windows-domän), hans behörighet att beställa delar verifieras och han får en kortlivad SAML-token som innehåller lämpliga anspråk och signeras av X.509-certifikatet som beslutats ovan. Programmet för att beställa delar kontaktar sedan Contoso-tjänsten som presenterar den utfärdade SAML-token för att autentisera och utföra beställningsuppgiften.

Här fungerar Fabrikam STS som "utfärdande part" och Contosos partstjänst fungerar som den förlitande parten. diagram som visar en utfärdande part och en förlitande part i en federation.

Federationsfunktioner

Följande är säkerhetsfunktioner som stöds för de parter eller roller som ingår i ett federationsscenario:

  • Klientsidan: För att hämta säkerhetstoken från STS kan man använda WsRequestSecurityToken funktion. Alternativt kan man använda ett bibliotek för säkerhetstoken på klientsidan, till exempel CardSpace eller LiveID, och sedan använda sina utdata för att lokalt skapa en säkerhetstoken med hjälp av WsCreateXmlSecurityToken. Hur som helst, när klienten har säkerhetstoken kan den sedan skapa en kanal till tjänsten som anger WS_XML_TOKEN_MESSAGE_SECURITY_BINDING för att presentera token, tillsammans med en transportsäkerhetsbindning, till exempel WS_SSL_TRANSPORT_SECURITY_BINDING för att skydda kanalen.
  • Serversidan: I ett federationsscenario med en tjänst för säkerhetstoken som utfärdar SAML-token kan servern använda WS_SAML_MESSAGE_SECURITY_BINDINGtillsammans med en transportsäkerhetsbindning som WS_SSL_TRANSPORT_SECURITY_BINDING för att skydda kanalen.
  • STS-sida: Observera att STS är ett webbtjänstprogram och kan ange säkerhetskrav för dem som begär en säkerhetstoken från den med hjälp av en säkerhetsbeskrivning struktur vid skapande av lyssnare precis som andra säkra webbtjänster. Den kan sedan parsa nyttolaster för inkommande begärandemeddelanden för att verifiera tokenbegäranden och skicka tillbaka utfärdade token som nyttolaster för svarsmeddelanden. För närvarande tillhandahålls inga funktioner för att hjälpa dessa parsnings- och utfärdandesteg.

Observera att klientsidan kan hantera den utfärdade säkerhetstoken allmänt som en XML-säkerhetstoken utan att känna till tokentypen eller utföra tokentypsspecifik bearbetning. Servern måste dock förstå den specifika säkerhetstokentypen för att förstå och bearbeta den. I stegen för begäran och svar för säkerhetstoken används de konstruktioner som definierats i WS-Trust-specifikationen.

Mer komplexa federationsscenarier

Ett federationsscenario kan omfatta flera STS som utgör en federationskedja. Tänk på följande exempel:

  • Klienten autentiserar till LiveID STS med ett Användarnamn/lösenord för LiveID och hämtar en säkerhetstoken T1.
  • Klienten autentiserar till STS1 med T1 och hämtar en säkerhetstoken T2.
  • Klienten autentiserar till STS2 med T2 och hämtar en säkerhetstoken T3.
  • Klienten autentiserar till måltjänsten S med hjälp av T3.

Här utgör LiveID STS, STS1, STS2 och S federationskedjan. STS:erna i en federationskedja kan utföra olika roller för det övergripande programscenariot. Exempel på sådana STS-funktionsroller är identitetsprovider, beslutsfattare för auktorisering, anonymisering och resurshanterare.

STS-begäransparametrar och metadatautbyte

För att klienten ska kunna göra ett lyckat WsRequestSecurityToken--anrop måste den känna till parametrarna för det anropet (till exempel den nödvändiga tokentypen och anspråkstyperna), säkerhetsbeskrivningen kraven för begärandekanalen till STS och slutpunktsadressen för STS. Klientprogrammet kan använda någon av följande tekniker för att fastställa den här informationen:

  • Hårdkoda informationen i programmet som en del av beslut om designtid.
  • Läs den här informationen från en konfigurationsfil på programnivå som konfigurerats av den lokala programdistribueraren.
  • Identifiera den här informationen dynamiskt vid körning med hjälp av metadataimport funktion med WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT struktur.

För att illustrera användningen av dynamisk MEX med federation bör du överväga 3 STS-exemplet ovan. Klienten kommer först att göra en dynamisk MEX med S för att hämta information om T3 (dvs. vad du ska fråga från STS2) samt sts2 dynamisk MEX-adress (dvs. var du hittar STS2). Den använder sedan den informationen för att göra en dynamisk MEX med STS2 för att identifiera information om T2 och STS1 och så vidare.

Därför sker de dynamiska MEX-stegen i ordning 4, 3, 2, 1 för att bygga upp federationskedjan och tokenbegäran och presentationsstegen sker i ordning 1, 2, 3, 4 för att varva ned federationskedjan.

Not

Windows 7 och Windows Server 2008 R2: WWSAPI stöder endast Ws-Trust och Ws-SecureConversation enligt definitionen i Lightweight Web Services Security Profile (LWSSP). Mer information om Microsofts implementering finns i avsnittet MESSAGE Syntax i LWSSP.