Federacja

Federacja umożliwia delegowanie urzędu autoryzacji innym członkom międzyoperajności. Rozważmy na przykład następujący problem biznesowy: Firma produkująca części automatyczne Contoso Ltd chce zezwolić autoryzowanym pracownikom firmy Fabrikam Inc na bezpieczny dostęp do usługi sieci Web zamówień części firmy Contoso. Jednym z rozwiązań zabezpieczeń dla tego scenariusza jest skonfigurowanie mechanizmu zaufania z firmą Fabrikam w celu delegowania decyzji o autoryzacji dostępu do firmy Fabrikam. Ten proces może działać w następujący sposób:

• Firma Fabrikam, gdy staje się partnerem firmy Contoso, konfiguruje umowę zaufania z firmą Contoso. Celem tego kroku jest uzgodnienie typu tokenu zabezpieczającego i zawartości, która będzie reprezentować autoryzację firmy Fabrikam i będzie akceptowalna dla firmy Contoso. Na przykład można zdecydować, że zaufany certyfikat X.509 o nazwie podmiotu "CN=Fabrikam Inc Supplier STS" powinien podpisać token SAML dla tego języka SAML, który ma zostać zaakceptowany przez usługę internetową Firmy Contoso. Ponadto można zdecydować, że oświadczenie zabezpieczeń w wystawionym tokenie SAML powinno mieć wartość "https://schemas.contoso.com/claims/lookup" (w przypadku autoryzacji wyszukiwania części) lub "https://schemas.contoso.com/claims/order" (w przypadku autoryzacji porządkowania części).
• Gdy pracownik firmy Fabrikam używa wewnętrznej aplikacji do zamawiania części, najpierw kontaktuje się z usługą tokenu zabezpieczającego (STS) wewnątrz firmy Fabrikam. Ten pracownik jest uwierzytelniany przy użyciu wewnętrznego mechanizmu zabezpieczeń firmy Fabrikam (np. nazwy użytkownika/hasła domeny systemu Windows), jego autoryzacja do zamawiania części jest weryfikowana i wystawia krótkotrwały token SAML zawierający odpowiednie oświadczenia i podpisany przez certyfikat X.509 wybrany powyżej. Aplikacja porządkowania części następnie kontaktuje się z usługą Contoso przedstawiającą wystawiony token SAML w celu uwierzytelnienia i wykonania zadania zamawiania.

W tym miejscu usługa Fabrikam STS działa jako "podmiot wystawiający", a usługa części firmy Contoso działa jako "jednostka uzależniona".

Funkcje federacji

Poniżej przedstawiono obsługiwane funkcje zabezpieczeń dla stron lub ról zaangażowanych w scenariusz federacji:

• Po stronie klienta: w celu uzyskania tokenu zabezpieczającego z usługi STS można użyć funkcji WsRequestSecurityToken. Alternatywnie można użyć biblioteki dostawcy tokenów zabezpieczających po stronie klienta, takiej jak CardSpace lub LiveID, a następnie użyć ich danych wyjściowych do lokalnego utworzenia tokenu zabezpieczającego przy użyciu WsCreateXmlSecurityToken. Tak czy inaczej, gdy klient ma token zabezpieczający, może następnie utworzyć kanał do usługi, określając WS_XML_TOKEN_MESSAGE_SECURITY_BINDING przedstawić token, wraz z powiązaniem zabezpieczeń transportu, takim jak WS_SSL_TRANSPORT_SECURITY_BINDING w celu ochrony kanału.
• Po stronie serwera: w scenariuszu federacyjnym z usługą tokenu zabezpieczającego, która wystawia tokeny SAML, serwer może używać WS_SAML_MESSAGE_SECURITY_BINDING, wraz z powiązaniem zabezpieczeń transportu, takim jak WS_SSL_TRANSPORT_SECURITY_BINDING w celu ochrony kanału.
• StS po stronie: należy pamiętać, że usługa STS jest aplikacją usługi sieci Web i może określić wymagania dotyczące zabezpieczeń dla tych, którzy żądają tokenu zabezpieczającego z niego przy użyciu opisu zabezpieczeń struktury podczas tworzenia odbiornika tak samo jak każda inna bezpieczna usługa sieci Web. Następnie może przeanalizować ładunki komunikatów żądań przychodzących w celu zweryfikowania żądań tokenu i wysłania z powrotem wystawionych tokenów jako ładunków komunikatów odpowiedzi. Obecnie nie są udostępniane żadne funkcje ułatwiające analizowanie i wydawanie kroków.

Należy pamiętać, że strona klienta może obsługiwać wystawiony token zabezpieczający w sposób ogólny jako token zabezpieczający XML bez znajomości typu tokenu lub wykonywania określonego przetwarzania typu tokenu. Jednak serwer musi zrozumieć określony typ tokenu zabezpieczającego, aby go zrozumieć i przetworzyć. Kroki żądania i odpowiedzi tokenu zabezpieczającego używają konstrukcji zdefiniowanych w specyfikacji WS-Trust.

Bardziej złożone scenariusze federacji

Scenariusz federacji może obejmować wiele usług STS, które tworzą łańcuch federacyjny. Rozważmy następujący przykład:

• Klient uwierzytelnia się w usłudze LiveID STS przy użyciu nazwy użytkownika/hasła liveID i uzyskuje token zabezpieczający T1.
• Klient uwierzytelnia się w usłudze STS1 przy użyciu języka T1 i uzyskuje token zabezpieczający T2.
• Klient uwierzytelnia się w usłudze STS2 przy użyciu T2 i uzyskuje token zabezpieczający T3.
• Klient uwierzytelnia się w usłudze docelowej S przy użyciu T3.

W tym miejscu usługa LiveID STS, STS1, STS2 i S tworzą łańcuch federacyjny. Usługi STS w łańcuchu federacji mogą wykonywać różne role dla ogólnego scenariusza aplikacji. Przykładami takich ról funkcjonalnych usługi STS są dostawcy tożsamości, twórca decyzji autoryzacji, anonimizator i menedżer zasobów.

Parametry żądania usługi STS i wymiana metadanych

Aby klient nawiązał pomyślne wywołanie WsRequestSecurityToken, musi znać parametry tego wywołania (takie jak wymagany typ tokenu i typy oświadczeń), opis zabezpieczeń wymagania kanału żądania do usługi STS oraz adres punktu końcowego usługi STS. Aplikacja kliencka może używać dowolnej z następujących technik do określania tych informacji:

• Zakodowanie twardych informacji w aplikacji w ramach decyzji dotyczących czasu projektowania.
• Przeczytaj te informacje z pliku konfiguracji na poziomie aplikacji skonfigurowanego przez narzędzie do wdrażania aplikacji lokalnych.
• Dynamiczne odnajdywanie tych informacji w czasie wykonywania przy użyciu funkcji importowania metadanych ze strukturą WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT.

Aby zilustrować użycie dynamicznego MEX z federacją, rozważmy powyższy przykład 3 STS. Klient najpierw wykona dynamiczną MEX z S, aby uzyskać informacje o T3 (tj. o to, co należy zapytać z STS2), a także adres STS2 dynamiczny MEX (tj. gdzie znaleźć STS2). Następnie użyje tych informacji, aby wykonać dynamiczną MEX z STS2 w celu odnalezienia informacji o T2 i STS1 itd.

W związku z tym dynamiczne kroki MEX mają miejsce w kolejności 4, 3, 2, 1 w celu utworzenia łańcucha federacji, a żądanie tokenu i procedura prezentacji mają miejsce w kolejności 1, 2, 3, 4, aby odwinąć łańcuch federacyjny.