Użycie programu Active Directory Federation Services 2.0 w rozwiązaniach dotyczących tożsamości

Autor: Zulfiqar Ahmed

Jako deweloper znasz prawdopodobnie Windows Identity Foundation (WIF), zwaną wcześniej „Strukturą Geneva”, która udostępnia interfejs API, który pozwala twoim aplikacjom obsługiwać oświadczenia i umożliwia tworzenie indywidualnych usług tokenów zabezpieczających. Być może wersja 2.0 Active Directory Federation Service (AD FS 2.0), zwana wcześniej “Geneva server”, jest ci mniej znana – jest to federacja enterprise-ready, a zarazem rozwiązanie jednokrotnej rejestracji. AD FS 2.0 jest następcą AD FS 1.0 i obsługuje zarówno scenariusze aktywne (WS-Trust), jak i pasywne (WS-Federation oraz SAML 2.0).

Poniższy artykuł rozpoczynam od przeglądu AD FS 2.0, przechodząc dalej do prezentacji sposobów, w które deweloperzy mogą stosować AD FS 2.0 w przygotowywaniu rozwiązań dotyczących weryfikacji tożsamości. Skupiam się na funkcjonalności wystawiania tokenów w AD FS 2.0, na bazie wersji Beta 2. Na Rysunku 1 widać, że funkcjonalność ta jest tylko małym fragmentem AD FS 2.0. Jest ona jednak szczególnie interesująca dla deweloperów.NET, którzy idą w kierunku stosowania tożsamości federacyjnej. Co do architektury, AD FS 2.0 jest zbudowany na WIF i Windows Communication Foundation (WCF), więc jeśli znasz te technologie, powinieneś czuć się w nim swobodnie.

Rysunek 1: Architektura AD FS 2.0

 

Przegląd AD FS 2.0

Na poziomie ogólnym, AD FS 2.0 jest zbiorem usług pokazanych na Rysunku 2.

Sercem AD FS 2.0 jest usługa tokenu zabezpieczającego (STS), która używa Active Directory jako magazynu tożsamości i Lightweight Directory Access Protocol (LDAP), SQL lub magazynu niestandardowego jako magazynu atrybutów. Usługa STS w AD FS 2.0 może wystawiać tokeny zabezpieczające wywołującym stosującym różne protokoły, w tym WS-Trust, WS-Federation i SAML 2.0. STS AD FS 2.0 obsługuje również formaty tokenów SAML 1.1 i SAML 2.0.

W AD FS 2.0 wyraźnie rozdzielono protokoły sieciowe i wewnętrzny mechanizm generowania tokenów. Różne protokoły są przekształcane na model obiektowy w momencie wejścia do systemu, zaś wewnętrznie AD FS 2.0 używa tego samego modelu obiektowego dla każdego protokołu. Taka konstrukcja pozwala AD FS 2.0 na zaoferowanie jasnego modelu rozszerzalności, niezależnego od zawiłości poszczególnych protokołów. Dalsze informacje na temat rozszerzeń AD FS 2.0 zostaną podane w zestawie SDK dla AD FS 2.0, przed wersją RTM.

Rysunek 2: Składniki AD FS 2.0

 

AD FS 2.0 jako dostawca tożsamości

AD FS 2.0 może być używany w kilku popularnych scenariuszach. Najprostszym i najczęstszym z nich jest użycie AD FS 2.0 jako dostawcy tożsamości w celu wystawiania tokenów SAML dla tożsamości, którymi zarządza. Aby to zrobić, należy utworzyć nową jednostkę uzależnioną. Jednostka uzależniona w AD FS 2.0 jest reprezentacją aplikacji (np. witryny lub usługi sieci Web) i zawiera wszystkie informacje związane z bezpieczeństwem, takie jak certyfikat szyfrowania, reguły transformacji oświadczeń, itd.

Konfiguracja jednostki uzależnionej

Tworzenie nowych jednostek uzależnionych w AD FS 2.0 jest proste. Kreatora dodawania jednostek uzależnionych można uruchomić z Węzła zasad konsoli zarządzania AD FS 2.0. Gdy go uruchomisz, ty bądź administrator systemu musicie określić odpowiednie źródła danych na ekranie Wybierz źródło danych, pokazanym na Rysunku 3.

Rysunek 3: Ekran Wybierz źródło danych w Kreatorze dodawania jednostek uzależnionych

Dwie pierwsze opcje pozwalają na automatyczną konfigurację jednostki uzależnionej przy użyciu metadanych federacji. Jeśli masz dostęp do metadanych federacji jednostki uzależnionej w sieci lub pliku lokalnym, wybierz jedną z tych opcji, gdyż są one mniej narażone na błędy, automatyzują cały proces i automatycznie się zaktualizują, jeśli w przyszłości zmienią się dane jednostki uzależnionej. Opcje te stanowią duży postęp w porównaniu z AD FS w wersji 1.0, która nie oferuje takich zautomatyzowanych procesów.

Trzecia opcja wymaga ręcznego wprowadzenia wszystkich danych konfiguracji. Używaj tej opcji tylko jeśli nie masz dostępu do metadanych federacji lub jeśli chcesz kontrolować szczegóły konfiguracji jednostki uzależnionej.

Dobrze jest przyjrzeć się opcji „Ręcznie wprowadź konfigurację jednostki zależnej”, by zobaczyć jakie kroki są potrzebne do utworzenia nowej jednostki. Na kilku kolejnych ekranach kreatora będziesz proszony o wybór profilu – wybierz Profil AD FS 2.0, jeśli chcesz obsługiwać zarówno aplikacje klienckie oparte na przeglądarce, jak i te oparte na WCF, bądź Profil AD FS 1.x, jeśli potrzebujesz tylko współdziałania z AD FS 1.x i nie obsługujesz aktywnych klientów (WCF, CardSpace); skonfigurowanie certyfikatu używanego do szyfrowania tokena, tak by tylko jednostka uzależniona z odpowiednim kluczem prywatnym mogła odszyfrować i użyć wydanego tokenu; a następnie o skonfigurowanie identyfikatora, który będzie używany do zidentyfikowania danej jednostki uzależnionej przy wszystkich żądaniach wystawienia tokenu.

Po zakończeniu działania Kreatora dodawania jednostek uzależnionych otwiera się Narzędzie edycji reguł. Pozwala ono skonfigurować reguły wysyłania i transformacji oświadczeń. Rysunek 4 przestawia Narzędzie edycji reguł skonfigurowane tak, by wystawiało token z pojedynczym oświadczeniem, którego wartość będzie pobierana z głównego magazynu atrybutów. Warto zauważyć, że atrybut Nazwa wyświetlana jest mapowany do żądania Imię. AD FS 2.0 wprowadza nowy tekstowy język, specyficzny dla domeny, który umożliwia definiowanie prostych reguł uzyskiwania procesu wystawiania i transformacji oświadczeń. Każda reguła składa się z warunku i akcji, i kończy się – jak w przypadku [c] =>a; ­ średnikiem. Logika transformacji to zestaw reguł wykonywanych kolejno podczas wystawiania tokenów. Pokazany na Rysunku 4 ekran Widok prosty jest interfejsem użytkownika, umożliwiającym zdefiniowanie tych reguł. Ekran Widok zaawansowany pozwala bezpośrednio definiować reguły za pomocą języka specyficznego dla

Rysunek 4: Narzędzie edytowania reguł

Powyższy przykład pokazuje jak prosta jest konfiguracja zaufanej jednostki uzależnionej w AD FS 2.0. W tym momencie, gdy AD FS 2.0 otrzymuje żądanie wystawienia tokenu, wyodrębnia z protokołu identyfikator (np. element appliesTo w przypadku WS-Trust) i stosuje go do wyszukania docelowej jednostki uzależnionej. Po jej znalezieniu, ustawienia określone w kreatorze są używane do pobrania logiki wystawiania tokenu.

Teraz przyjrzyjmy się sposobom, w jaki można wykorzystać WCF do żądania wystawienia tokenu przez AD FS 2.0 dla utworzonej jednostki uzależnionej.

Żądanie wystawienia tokenu przy użyciu WCF

Istnieją dwie możliwości interakcji z usługą STS AD FS 2.0 przy użyciu WCF:

  • Jawne uzyskanie tokena, działając jako klient WS-Trust
  • Skonfigurowanie klienta WCF tak, by infrastruktura niejawnie uzyskiwała token przy wywołaniu.

W przypadku opcji jawnej, klasa WSTrustClient dostarcza proste i bezpośrednie API do wysyłania żądań tokenów do STS za pomocą protokołu WS-Trust, jak pokazano poniżej.

string baseUri = "https://bccoss.com/";

WindowsWSTrustBinding binding = new WindowsWSTrustBinding(SecurityMode.Transport);

WSTrustClient tokenClient = new WSTrustClient(binding,
    new EndpointAddress(baseUri + "Trust/2005/WindowsTransport/"),
    TrustVersion.WSTrustFeb2005,
    new ClientCredentials());

//create a token issuance issuance
RequestSecurityToken rst =
    new RequestSecurityToken(WSTrustFeb2005Constants.RequestTypes.Issue);
//Relying Party’s identifier
rst.AppliesTo = new EndpointAddress("http://local.zamd.net/");
//call ADFS STS
SecurityToken token = tokenClient.Issue(rst);

Ten kod wysyła żądanie wystawienia tokenu za pomocą Uwierzytelniania Windows z zabezpieczeniem transportu. Jak widać, w trybie jawnym otrzymujemy dostęp do surowego tokenu, którego można użyć do późniejszego wywoływania usług. Na przykład, w przypadku inteligentnej aplikacji klienckiej, można uzyskiwać tokeny dla różnych usług w momencie uruchamiania aplikacji bądź logowania, zachowywać je w pamięci podręcznej tokenów i używać ich w całym okresie istnienia aplikacji do wywoływania różnych usług wewnętrznych. W przypadku gdy wiele usług istnieje w tym samym logicznym obszarze zabezpieczeń i używa tego samego certyfikatu, można używać trybu jawnego do uzyskania jednego tokena i wywoływania za jego pomocą wszystkich tych usług.

W środowisku testowym, w którym mamy zwykle dostęp do klucza prywatnego jednostki uzależnionej, możemy użyć poniższego kodu do wyodrębnienia potwierdzenia SAML z uzyskanego tokenu.

//Private Key certificate of RP (local.zamd.net)
X509Certificate2 rpCertificate = new X509Certificate2("zamd.net.pfx", "pwd");
string assertion = Util.ExtractSAMLAssertion(token, rpCertificate);

<saml:Attribute AttributeName="givenname" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">
    <saml:AttributeValue>Zulfiqar Ahmed</saml:AttributeValue>
</saml:Attribute>

Token SAML zawiera tylko oświadczenia skonfigurowane dla danej jednostki uzależnionej. Rysunek 4 powyżej pokazuje sposób, w jaki token danych wyjściowych tej jednostki uzależnionej został skonfigurowany tak, by zwracał pojedynczy atrybut. Konfiguracje jednostki uzależnionej możesz edytować tak, by dane wyjściowe zawierały więcej oświadczeń; wszystkie powinny być tu widoczne. Możesz również użyć bezpośrednio języka zasad oświadczeń, by zdefiniować bogatą logikę transformacji i filtrowania

Zarówno API WSTrustClient, jak i nowe powiązania WSTrust są częścią WIF, więc aby powyższy kod zadziałał, aplikacja kliencka musi mieć zainstalowany WIF. API WCF można używać również bezpośrednio do jawnego uzyskiwania tokenów, ale prostota i łatwość użycia WIF sprawia, że z listy rzeczy do zrobienia możemy skreślić jedno zadanie.

Element IssuedSecurityTokenProvider w kodzie znajdującym się na Rysunku 5 jest odpowiednikiem WSTrustClient w WCF i jest zwykle używany przez wsFederationBinding przy żądaniu tokena wysyłanym w twoim imieniu. Jako że jest to publiczny interfejs API, możesz używać go w kodzie, gdy potrzebujesz dostępu do surowego tokena. Element CustomBinding jest odpowiednikiem WindowsWSTrustBinding.

Rysunek 5: Użycie elementu IssuedSecurityTokenProvider do uzyskiwania dostępu do surowego tokenu

sstring baseUri = "https://bccoss.com/";

//Limited edition of WSTrustClient:)
IssuedSecurityTokenProvider provider = new IssuedSecurityTokenProvider();
provider.SecurityTokenSerializer = new WSSecurityTokenSerializer();

//Relying Party's identifier
provider.TargetAddress = new EndpointAddress(new Uri("http://local.zamd.net"));
provider.IssuerAddress = new EndpointAddress(new Uri(baseUri + "Trust/2005/WindowsTransport/"));

provider.SecurityAlgorithmSuite = SecurityAlgorithmSuite.Basic256;
provider.MessageSecurityVersion = MessageSecurityVersion.
WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;

HttpsTransportBindingElement tbe = new HttpsTransportBindingElement();
tbe.AuthenticationScheme = AuthenticationSchemes.Negotiate;
CustomBinding stsBinding = new CustomBinding(tbe);

provider.IssuerBinding = stsBinding;
provider.Open();
//Request a token from ADFS STS
SecurityToken issuedToken = provider.GetToken(TimeSpan.FromSeconds(30));

W opcji niejawnej można użyć elementu wsFederationHttpBinding. W tym wypadku infrastruktura WCF w sposób przezroczysty pobiera token i wysyła go do usługi w ramach wywołania. Gdy tworzysz nowe proxy WCF i używasz go do wywołania usługi, infrastruktura dostarcza ci nowy token. Oczywiście w pewnych przypadkach byłaby to przesada. Kod pokazany na Rysunku 6 konfiguruje fikcyjny EmployeeService tak, by wymagał tokenów z AD FS 2.0.

Rysunek 6 Użycie elementu wsFederationHttpBinding do niejawnego uzyskiwania tokenów

<system.serviceModel>
  <services>
    <service name="EmployeeService.EmployeeService">
      <endpoint address="http://localhost:9990/ES"
        binding="ws2007FederationHttpBinding"
        contract="EmployeeServiceContract.IEmployeeService"
        bindingConfiguration="adfsFed"/>
    </service>
  </services>
  <bindings>
    <ws2007FederationHttpBinding>
      <binding name="adfsFed">
        <security mode="Message">
          <message negotiateServiceCredential="false" >
            <issuer address="https://bccoss.com/Trust13/KerberosMixed"
               binding="customBinding" bindingConfiguration="MixedKerberos"/>
          </message>
        </security>
      </binding>
     </ws2007FederationHttpBinding>
     <customBinding>
       <binding name="MixedKerberos">
         <security authenticationMode="KerberosOverTransport"/>
         <httpsTransport/>
       </binding>
     </customBinding>
   </bindings>
</system.serviceModel>

Mapowanie koncepcji AD FS 2.0 do WCF

Głównym zadaniem AD FS 2.0 jest wystawianie tokenów użytkownikom, których tożsamość została potwierdzona. Tożsamość użytkowników można potwierdzać przy użyciu różnych mechanizmów (takich jak Uwierzytelnianie Windows). Po wybraniu węzła Punkty końcowe w konsoli zarządzania, wyświetlą się wszystkie obsługiwane mechanizmy uwierzytelniania.

Zauważysz dwie znane koncepcje bezpieczeństwa WCF jako nagłówki kolumn węzła Punkty końcowe.

  • Typ uwierzytelniania w AD FS 2.0 to odpowiednik terminu clientCredentialType w WCF.
  • Dostępne wybory trybu zabezpieczeń to Transport, Widomość lub Mieszany. Tryb mieszany jest odpowiednikiem TransportWithMessageCredentials z WCF w AD FS 2.0.

Różne kombinacje tych wartości są uwidocznione za pomocą różnych punktów końcowych, a wybór danego punktu końcowego zależy od indywidualnych potrzeb uwierzytelniania. Na przykład, jeśli potrzebujesz uwierzytelniania za pomocą nazwy użytkownika/hasła, wybierasz punkt końcowy uwierzytelniania Clear Password.

W przypadku usługi STS AD FS 2.0, przy mapowaniu tych pojęć z powrotem do Address, Binding i Contract (ABC) w WCF, otrzymujemy następujące ekwiwalenty:

  • Address = adres podstawowy AD FS 2.0 + ścieżka URL punktu końcowego
  • Binding = Tryb zabezpieczeń punktu końcowego + Typ uwierzytelniania
  • Contract = Standardowy protokół WS-Trust

Tworzenie federacji AD FS 2.0 z inną usługą STS

Poza dodawaniem jednostek uzależnionych, można ustanowić relację zaufania między AD FS 2.0 i niestandardową usługą STS, bądź innym AD FS 2.0. Na przykład, jeśli masz już usługę STS, która uwierzytelnia użytkowników i wystawia tokeny, możesz po prostu dodać ją jako zaufanego dostawcę tożsamości w AD FS 2.0, co pozwoli na akceptowanie pochodzących od niej tokenów.

Konfiguracja Dostawców tożsamości

Konfiguracja nowego zaufanego dostawcy tożsamości w AD FS 2.0 przebiega podobnie jak konfiguracja nowej jednostki uzależnionej. Kreator dodawania dostawcy tożsamości wygląda i działa bardzo podobnie do Kreatora dodawania jednostek uzależnionych (patrz: Rysunek 3).

Aby przejść do ekranu Konfiguracji identyfikatora, wybierz ponownie konfigurację manualną (tak jak na Rysunku 3) i zaznacz Profil AD FS 2.0 na ekranie Wyboru profilu. Na ekranie Konfiguracji adresu URL pozostaw ustawienia domyślne. Następnie wybierz identyfikator i certyfikat klucza publicznego swojego dostawcy tożsamości i zakończ działanie kreatora, aby zarejestrować nowego dostawcę tożsamości.

Żądanie wystawienia tokenu przy użyciu WCF

Po zarejestrowaniu dodatkowego dostawcy tożsamości w AD FS 2.0, architektura logiczna ma konfigurację pokazaną na Rysunku 7.

Rysunek 7: Architektura AD FS 2.0 z dodatkowym dostawcą tożsamości

Kod na Rysunku 8 pozwala na jawne pobranie tokenu, dając możliwość umieszczenia tokenu w lokalnej pamięci podręcznej i wysyłania go w razie potrzeby do innych usług.

Rysunek 8: Używanie elementu IssuedTokenWSTrustBinding do jawnego pobierania tokenu

string adfsStsUri = "http://bccoss.com/Trust/2005/IssuedTokenAsymmetricBasic256";

//binding for local STS(IP-STS)
WSHttpBinding localStsBinding = new WSHttpBinding(SecurityMode.Message);

localStsBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
localStsBinding.Security.Message.EstablishSecurityContext = false;
localStsBinding.Security.Message.NegotiateServiceCredential = false;

EndpointAddress localStsEpr = new EndpointAddress(
   new Uri("http://localhost:9000/STS/"),
   new X509CertificateEndpointIdentity(new X509Certificate2(@"MyCustomSTSPublicKey.cer")));

//This binding will transparently acquire all the intermediate tokens as part of the call. (R-STS)
IssuedTokenWSTrustBinding fedBinding = new IssuedTokenWSTrustBinding(localStsBinding, localStsEpr);
fedBinding.TrustVersion = TrustVersion.WSTrustFeb2005;

EndpointAddress adfsStsEpr = new EndpointAddress(
    new Uri(adfsStsUri),
    new X509CertificateEndpointIdentity(new X509Certificate2("AdfsStsPubicKeyOnly.cer")));

WSTrustClient trustClient = new WSTrustClient(fedBinding, adfsStsEpr, TrustVersion.WSTrustFeb2005,
null);

//Create a security token request
RequestSecurityToken rst = new RequestSecurityToken(RequestTypeConstants.Issue);
//Set Relying Party's identifier accordingly
rst.AppliesTo = new EndpointAddress("http://local.zamd.net");

SecurityToken finalToken = trustClient.Issue(rst);

Element IssuedTokenWSTrustBinding jest bardzo podobny do wsFederationHttpBinding, gdyż ukrywa złożoność tokenów pośrednich, przezroczyście komunikując się usługą STS protokołu IP, by uzyskać token pośredni, który jest później przesyłany jako token uwierzytelniania do usługi R-STS.

Kod pokazany na Rysunku 9 zawiera element wsFederationHttpBinding w celu umożliwienia klientowi WCF niejawnego uzyskiwania tokenu w trakcie wywoływania usługi.

Warto zauważyć, że do komunikacji z punktem końcowym /IssuedTokenMixedSymmetricBasic256 używam elementu customBinding. Standardowy element wsFederationHttpBinding nie działa tu, gdyż próbuje nawiązać bezpieczną sesję, która jest niekompatybilna z tym punktem końcowym AD FS 2.0. Aby utworzyć federację klientów WCF z AD FS 2.0, należy użyć customBinding lub jednego z nowych wiązań opartych na WS-Trust, przesyłającego za pomocą WIF.

Rysunek 9: Użycie elementu wsFederationHttpBinding do niejawnego uzyskiwania tokenów

<system.serivceModel>
   <bindings>
      <wsFederationHttpBinding>
         <binding name="R-STS">
            <security mode="Message">
               <message>
                  <issuer address="https://bccoss.com/Trust/2005/IssuedTokenMixedSymmetricBasic256" binding="customBinding" bindingConfiguration="IP-STS"/>
               </message>
            </security>
         </binding>
      </wsFederationHttpBinding>

      <customBinding>
         <binding name="IP-STS">
            <security authenticationMode="IssuedTokenOverTransport">
               <issuedTokenParameters>
                  <issuer address="http://localhost:9000/CustomSTS" binding="wsHttpBinding"/>
               </issuedTokenParameters>
            </security>
            <httpsTransport/>
         </binding>
      </customBinding>
   </bindings>

   <client>
      <endpoint address="http://localhost:9990/ES" binding="wsFederationHttpBinding" bindingConfiguration="R-STS"
contract="ServiceReference1.IEmployeeService" name="WSFederationHttpBinding_IEmployeeService"/>
      </client>
</system.serviceModel>

AD FS 2.0 i aplikacje klienckie oparte na przeglądarkach

AD FS 2.0 doskonale obsługuje rejestrację jednokrotną w sieci Web (WebSSO) i federację zarówno przy użyciu protokołu WS-Federation, jak i SAML 2.0.

W zamyśle protokoły WS-Federation i SAML są podobne, mimo że mają inne reprezentacje sieciowe. Format WS-Federation jest ściśle powiązany z protokołem WS-Trust, więc jest logicznym wyborem, gdy obsługujesz zarówno aktywne, jak i pasywne (oparte na przeglądarce) aplikacje klienckie. Protokół SAML lepiej współpracuje z klientami różnych dostawców. AD FS 2.0 obsługuje oba te protokoły. Dobrze jest używać w swoim obszarze zabezpieczeń jednego protokołu (np. WS-Federation) i korzystać z AD FS 2.0 jako brokera protokołów dla przychodzących i wychodzących SSO.

Spójrzmy na przykład. Mamy prostą aplikację ASP.NET, która obsługuje tylko uwierzytelnionych użytkowników. Jako, że jest to samodzielna aplikacja, zawiera ona logikę uwierzytelniania, a interakcja z nią przebiegałaby według schematu pokazanego na Rysunku 10.

Rysunek 10: Bezpośredni uwierzytelnianie w prostej aplikacji ASP.NET

Stosowane są tu zwykłe mechanizmy uwierzytelniania ASP.NET, takie jak uwierzytelnianie formularzy. Naszym celem jest wyodrębnienie z aplikacji funkcjonalności uwierzytelniania i użycie w jej miejsce AD FS2.0.

W konfiguracji AD FS 2.0 pokazanej na Rysunku 11 aplikacja staje się zaufaną jednostką uzależnioną wewnątrz AD FS 2.0, a co za tym idzie ufa tokenom wystawianym przez AD FS 2.0. Aplikacja stosuje WIF do wykonywania trudnych zadań takich jak analiza tokenów, czy wyodrębnianie oświadczeń. Informacje na temat tożsamości są dostarczane do niej za pomocą standardowych abstrakcji IIdentity/IPrincipal.

Rozproszone uwierzytelnianie w AD FS 2.0 jest dużo bardziej elastyczne niż uwierzytelnianie bezpośrednie i przynosi duże korzyści:

  • Uwierzytelnianie odbywa się poza aplikacją, więc mechanizm uwierzytelniania może zostać zmieniony (na przykład z nazwy użytkownika na Kerberos) bez pływu na nią.
  • Elastyczny model oparty na oświadczeniach może dostarczyć do aplikacji wszystkie potrzebne informacje (jako składniki tokenu) bezpośrednio - aplikacja nie musi sama uzyskiwać informacji z różnych źródeł.

W wersji Beta 2 WIF wprowadzono nowe szablony projektów, które ułatwiają wyodrębnienie logiki uwierzytelniania aplikacji do STS. W chwili pisania tego artykułu, szablony te są dostępne tylko w C#.

Rysunek 11: Rozproszone uwierzytelnianie w AD FS 2.0

Wyodrębnianie logiki uwierzytelniania

Aby wyodrębnić logikę uwierzytelniania aplikacji, należy użyć okna dialogowego Nowa witryna sieci Web w Microsoft Visual Studio. Następnie należy wybrać szablon Witryna sieci Web obsługująca oświadczenia, by utworzyć standardową witrynę ASP.NET prekonfigurowaną za pomocą WIF.

Aby uruchomić Kreatora narzędzia federacji pokazanego na Rysunku 12, należy nacisnąć prawym przyciskiem myszy węzeł Witryna sieci Web w

Rysunek 12: Narzędzie federacji

Do tego przykładu użyjemy opcji „Użyj istniejącej usługi STS” i zdefiniujemy AD FS 2.0 jako STS. Kreator wymaga podania adresu URL dokumentu metadanych, aby automatycznie dokonać wymaganej konfiguracji. Adres URL dokumentu metadanych jest dostępny jako punkt końcowy w AD FS 2.0.

Metadane federacji zawierają ważne informacje, takie jak certyfikat podpisywania usługi STS, oferowane oświadczenia i adres URL wystawiania tokenów. Standardowy format informacji pozwala narzędziom automatycznie ustalać relacje zaufania między usługami STS i jednostkami uzależnionymi.

Ekran Podsumowanie w kreatorze podsumowuje zmiany, które zostaną wprowadzone w pliku web.config.

Kreator narzędzia federacji konfiguruje WIF twojej witryny sieci Web, aby dostarczyć następujące funkcjonalności:

  • Wszystkie nieuwierzytelnione zapytania będą przekierowywane do AD FS 2.0.
  • Każde zapytanie zawierające prawidłowy token będzie przetworzone, a dane dotyczące tożsamości zostaną przedstawione aplikacji w formie ClaimsIdentity/ClaimsPrincipal. Aplikacja nadal będzie uzyskiwała dane dotyczące tożsamości przy użyciu standardowej abstrakcji IPrincipal/IIdentity, niezależnie od ich źródła.

Przed przetestowaniem tej aplikacji, należy dokonać jeszcze ostatniej zmiany konfiguracji AD FS 2.0. Należy dodać kolejny punkt końcowy do jednostki uzależnionej dla klientów opartych na przeglądarce. Jest to niezbędne, gdyż kiedy AD FS 2.0 przetworzy żądanie wystawienia tokenu, potrzebuje do wysłania go z powrotem do przeglądarki dwóch informacji:

  • Adresu, pod który należy wysłać token
  • Protokołu (SAML lub WS-Federation), za pomocą którego ma być wysłany token

Do jednostki uzależnionej można dodać pasywny punkt końcowy w karcie Punkty końcowe okna dialogowego Testuj właściwości RP. Na przykład jeśli wybierzemy jako ty punktu końcowego WS-Federation, AD FS 2.0 odeśle token do jednostki uzależnionej przy użyciu protokołu WS-Federation. W jednostce uzależnionej, WIF, który rozumie protokół WS-Federation, przetwarza te tokeny.

Teraz, gdy próbujemy przeglądać aplikację jesteśmy automatycznie przekierowywani do AD FS 2.0 w celu uwierzytelnienia; tam można wybrać metodę uwierzytelnienia: Uwierzytelnianie zintegrowane systemu Windows, Uwierzytelnianie certyfikatu lub Formularz nazwa użytkownika/hasło.

Po pozytywnym uwierzytelnieniu, wraz z tokenem wystawionym przez AD FS 2.0, jesteśmy przekierowywani do aplikacji. WIF przetwarza token i udostępnia tożsamość (w formie oświadczeń) aplikacji przy użyciu standardowych mechanizmów ASP.NET (na przykład Page.User).

Federacja oparta na przeglądarce

Podstawowy scenariusz zewnętrznego uwierzytelniania można rozszerzyć do scenariusza federacyjnego, dodając zaufanego dostawcę tożsamości. Opcje dostawców tożsamości pokazywane są w procesie uwierzytelniania.

Uwierzytelnienia można dokonać przy pomocy AD FS 2.0 lub innego zaufanego dostawcy tożsamości. Jeśli wybierzemy innego dostawcę tożsamości, jesteśmy do niego przekierowywani, a po prawidłowym uwierzytelnieniu trafiamy z powrotem do AD FS 2.0, które dokonuje uwierzytelnienia na podstawie tokenu wystawionego przez zaufanego dostawcę tożsamości.

Potężne narzędzie

Jak widać, usługa STS AD FS 2.0 oferuje proste, gotowe rozwiązanie pozwalające usługom WCF i aplikacjom opartym na przeglądarkach obsługiwać oświadczenia. Usługa STS jest tyko drobnym elementem AD FS 2.0 ­ zawiera on również system automatyzacji dostępu do zasobów CardSpace, mechanizm transformacji oświadczeń, automatyczną infrastrukturę zarządzania zaufaniem, usługi zarządzania i konfiguracji oraz ich narzędzia. Wraz z WIF, AD FS 2.0 stanowi potężne narzędzie do programowania rozwiązań dotyczących tożsamości w platformie Windows.