• Artykuł

     

Platforma WIF - autoryzacja oparta na oświadczeniach, cz. I Udostępnij na: Facebook

W ostatnich latach znacznie wzrosła popularność federacyjnych modeli zabezpieczeń i funkcji kontroli dostępu opartych na oświadczeniach. W przypadku federacyjnego modelu zabezpieczeń uwierzytelnianie można przeprowadzać za pomocą usługi tokenu zabezpieczającego (Security Token Service, STS), która umożliwia wydawanie tokenów zawierających oświadczenia dotyczące tożsamości uwierzytelnionych użytkowników oraz ich praw dostępu. Federacja pozwala na uwierzytelnianie użytkowników w ich domenie oraz udzielanie im dostępu do aplikacji i usług należących do innej domeny, o ile między domenami została nawiązana relacja zaufania. Takie podejście eliminuje konieczność zastrzegania zduplikowanych kont pojedynczego użytkownika i zarządzania nimi oraz umożliwia stosowanie mechanizmów rejestracji pojedynczej (SSO). Dostęp oparty na oświadczeniach to podstawowy element federacyjnego modelu zabezpieczeń, w którym aplikacje i usługi autoryzują dostęp do funkcji na podstawie oświadczeń wystawcy (STS) w zaufanych domenach. Oświadczenia mogą zawierać informacje na temat użytkownika, ról lub uprawnień, co zapewnia znaczną elastyczność modelu autoryzacji. Zabezpieczenia federacyjne i dostęp oparty na oświadczeniach pozwalają stosować różne metody integracji aplikacji, działów firmy i partnerów w ramach bardziej rozległego środowiska.

Narzędzia do obsługi tej platformy również zostały znacznie udoskonalone. Windows Identity Foundation (WIF) to zaawansowana struktura modelu tożsamości zaprojektowana z myślą o opracowywaniu aplikacji i usług opartych na oświadczeniach oraz obsłudze aktywnych i pasywnych zabezpieczeń federacyjnych. Dzięki usłudze WIF można wdrożyć federację pasywną w dowolnych aplikacjach ASP.NET oraz bardzo łatwo zintegrować model autoryzacji opartej na oświadczeniach z aplikacjami ASP.NET i usługami WCF. Co więcej, platforma WIF zapewnia niezbędne elementy umożliwiające opracowywanie niestandardowych implementacji usługi STS, a także oferuje funkcje i mechanizmy sterujące zgodne ze scenariuszami uwierzytelniania opartymi na zarządzanych kartach informacyjnych i selektorach tożsamości, takich jak Windows CardSpace. 

Struktura WIF znacznie ogranicza ilość kodu wymaganego do wdrażania aplikacji rozszerzonych obsługujących zabezpieczenia federacyjne i oparte na oświadczeniach. Niniejszy dwuczęściowy artykuł dotyczy podstawowych funkcji platformy związanych z obsługą federacji pasywnej w aplikacjach ASP.NET oraz modeli zabezpieczeń opartych na oświadczeniach w środowiskach WCF i ASP.NET. Ten artykuł dotyczy technologii WCF, natomiast następny dokument będzie poświęcony platformie ASP.NET.

Zalety zabezpieczeń federacyjnych i opartych na oświadczeniach

Korzyści związane z zabezpieczeniami federacyjnymi i opartymi na oświadczeniach można podzielić na kilka obszarów:

  • Oddzielenie mechanizmu uwierzytelniania od aplikacji i usług.
  • Zamiana ról na oświadczenia, które umożliwiają bardziej elastyczną i szczegółową autoryzację.
  • Ograniczenie problemów informatycznych związanych z konfigurowaniem i usuwaniem użytkowników.
  • Udzielanie zaufanym domenom — w tym zewnętrznym partnerom federacyjnym — dostępu do funkcji aplikacji.

Jeśli co najmniej jeden z powyższych celów jest związany ze stosowanym środowiskiem aplikacji, wdrożenie modelu opartego na oświadczeniach i umożliwiającego obsługę zabezpieczeń federacyjnych jest niezwykle przydatne.

Model uwierzytelniania i autoryzacji jest częścią każdego projektu wdrożenia aplikacji i usług. Na przykład aplikacja intranetowa zazwyczaj wymaga od użytkowników uwierzytelnienia się w konkretnej domenie za pomocą poświadczeń systemu Windows, natomiast aplikacja internetowa jest zwykle oparta na niestandardowym magazynie poświadczeń, takim jak Microsoft SQL Server. Aplikacje mogą wymagać certyfikatów lub uwierzytelnienia przy użyciu kart inteligentnych. Mogą także obsługiwać wiele typów poświadczeń stosowanych przez różne grupy użytkowników. Jeśli aplikacja będzie zawsze wymagać od użytkowników uwierzytelnienia się za pomocą jednego typu poświadczeń, zadanie jest łatwe. Częściej jednak typy poświadczeń dostępne w aplikacji zmieniają się w celu uzyskania zgodności z alternatywnymi trybami uwierzytelniania lub mechanizmami obsługującymi inne grupy użytkowników.

Na przykład aplikacja może obsługiwać użytkowników wewnętrznych za zaporą w domenie oraz użytkowników zewnętrznych za pośrednictwem Internetu. Dzięki oddzieleniu modelu zabezpieczeń od trybu uwierzytelniania w aplikacji — tak jak w przypadku mechanizmów opartych na oświadczeniach — wpływ nowych trybów uwierzytelniania na działanie aplikacji jest znikomy.

Co więcej, uniezależnienie autoryzacji od stałego zestawu ról zwiększa elastyczność działania aplikacji. Jeśli aplikacja będzie autoryzować dostęp na podstawie określonego zestawu ról, które zawsze będą mieć takie samo znaczenie w zakresie praw dostępu do funkcji, będzie to korzystne. Jednak znaczenie ról podczas korzystania z aplikacji często różni się w zależności od działu, zatem wdrożenie modelu zabezpieczeń może wymagać dostosowania, na przykład poprzez odmienną ocenę ról na podstawie domeny użytkownika lub umożliwienie tworzenia ról niestandardowych w celu kontrolowania praw dostępu. Platforma WIF ułatwia wdrożenie modelu zabezpieczeń opartych na oświadczeniach, co pozwala oddzielić role (jeśli istnieją) od mechanizmu autoryzacji. Dzięki temu role logiczne można mapować do bardziej szczegółowego zestawu oświadczeń, które służą do autoryzowania dostępu do aplikacji. Jeśli zmodyfikowane lub nowe role wymagają wydania innego zestawu oświadczeń, nie ma to wpływu na działanie aplikacji.

Oczywiście oświadczenia mogą oferować o wiele więcej możliwości niż role lub uprawnienia. Jedną z dodatkowych zalet modelu opartego na oświadczeniach jest fakt, że pojedyncze oświadczenie może zawierać informacje na temat uwierzytelnionego użytkownika, takie jak adres e-mail, pełna nazwa, data urodzenia itd. Oświadczeń można także używać do weryfikowania informacji bez udostępniania faktycznego wieku lub daty urodzenia użytkownika (są to dane, których użytkownicy często nie chcą publicznie ujawniać). Oświadczenie może wskazywać, czy wiek użytkownika pozwala na wykonanie danej akcji (wartość logiczna IsOver21 lub IsOver13), lub umożliwiać weryfikację przynależności użytkownika do konkretnego działu bez udostępniania listy wszystkich działów, do których należy użytkownik.

Choć oddzielenie mechanizmu uwierzytelniania i określonych ról od aplikacji i usług ułatwia wprowadzanie zmian, model oparty na oświadczeniach jest również podstawowym elementem scenariuszy zabezpieczeń federacyjnych, które znacznie upraszczają udzielanie dostępu użytkownikom należącym do dowolnej zaufanej domeny. Federacja ogranicza ilość zadań administracyjnych i eliminuje niektóre zagrożenia związane z zarządzaniem tożsamością. Model tego rodzaju nie wymaga utrzymywania poświadczeń użytkownika w wielu aplikacjach lub domenach i pozwala zmniejszyć ryzyko dotyczące konfiguracji i usuwania kont w ramach wielu domen, na przykład gdy administrator zapomni usunąć dane konta z kilku miejsc. Gdy nie jest konieczne zarządzanie wieloma kopiami konta, synchronizacja haseł również przestaje być problemem. Mechanizm federacji ułatwia również wdrażanie środowisk pojedynczej rejestracji (SSO), ponieważ użytkownicy mogą zalogować się w jednej aplikacji i uzyskać dostęp do innego zasobu (m.in. w ramach wielu domen zabezpieczeń) bez konieczności ponownego uwierzytelnienia. Co więcej, w przypadku federacyjnych platform zabezpieczeń, takich jak program Active Directory Federation Server (ADFS) i usługa WIF, można łatwo dodawać nowe relacje zaufania między domenami. Upraszcza to dodawanie aplikacji do kolejnych domen w ramach jednostki przedsiębiorstwa lub domen partnerów zewnętrznych.

Aktywna federacja w ramach platformy WIF

Scenariusze federacji aktywnej są oparte na specyfikacjach WS-Federation Active Requestor Profile (zobacz dokument komitetu technicznego WS-Federation pod adresem oasis-open.org/committees/tc_home.php?wg_abbrev=wsfed) i WS-Trust (zobacz specyfikację protokołu WS-Trust 1.3 pod adresem docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html). Ogólnie specyfikacja WS-Trust opisuje transakcje z czterema operacjami usługowymi: Wystawienie, Sprawdzenie poprawności, Odnowienie i Anulowanie. Operacje te są wywoływane przez klientów odpowiednio w celu przekazania żądania tokenu bezpieczeństwa, sprawdzenia jego poprawności, odnowienia żetonu bezpieczeństwa, którego ważność wygasła, oraz anulowania tokenu, który nie powinien być używany. Zgodnie ze specyfikacją protokołu WS-Trust każda operacja przetwarza komunikaty w postaci żądań tokenu bezpieczeństwa (RST, Request for Security Token) i wysyła odpowiedzi w formie reakcji na żądanie RST (RSTR, RST Response). Wymienione funkcje WS-Trust są implementowane po stronie usługi STS (lub wystawcy tokenu), która jest ważnym uczestnikiem każdego scenariusza zabezpieczeń federacyjnych.

Na rysunku 1 przedstawiono prosty scenariusz federacji aktywnej. Scenariusz obejmuje aplikację kliencką systemu Windows (obiekt żądający), usługę WCF (stronę odpowiadającą — RP) oraz usługę STS należącą do domeny RP (RP-STS). Jak widać na ilustracji, klient korzysta z serwera proxy usługi WCF w celu koordynacji uwierzytelnienia w domenie RP-STS, przekazania żądania tokenu zabezpieczeń, a następnie wywołania usługi RP poprzez przekazanie wydanego tokenu wraz z żądaniem.

Rysunek 1. Prosty scenariusz federacji aktywnej.

W tym scenariuszu usługa RP-STS jest również dostawcą tożsamości (IdP) dla użytkowników uwierzytelniających się w domenie RP. Oznacza to, że usługa RP-STS jest odpowiedzialna za uwierzytelnianie użytkowników, przypisywanie im tożsamości oraz wydawanie poświadczeń na potrzeby autoryzacji w domenie RP. Usługa RP weryfikuje token zabezpieczeń wydany przez usługę RP-STS i autoryzuje dostęp na podstawie wydanych oświadczeń.

Aby ułatwić omówienie kwestii związanych z wdrożeniem takiego scenariusza, opracowaliśmy aplikację Todo List. Dołączona próbka kodu zawiera klienta usługi WPF, usługę WCF oraz aktywną usługę STS zaimplementowaną za pomocą struktury WIF. W celu zapewnienia pełnego kontekstu w usłudze WCF o nazwie TodoListService zaimplementowano kontrakt ITodoListService pokazany na rysunku 2. Klient wywołuje usługę za pośrednictwem serwera proxy usługi WCF w celu pobrania, dodania, aktualizacji i usunięcia wszystkich elementów Todo. Usługa TodoListService autoryzuje dostęp do operacji na podstawie oświadczeń dotyczących tworzenia, odczytu, aktualizacji i usuwania.

Rysunek 2. Definicja usługi ITodoListService.

[ServiceContract(Namespace="urn:TodoListApp/2009/06")]
public interface ITodoListService
{
    [OperationContract]
    List<TodoItem> GetItems();
    [OperationContract]
    string CreateItem(TodoItem item);
    [OperationContract]
    string CreateItem(TodoItem item);
    [OperationContract]
    void DeleteItem(string id);
}

W celu wdrożenia tego scenariusza federacji aktywnej należy wykonać następujące cztery czynności:

  1. Udostępnienie punktu końcowego zabezpieczeń federacyjnych WCF usłudze TodoListService.
  2. Wygenerowanie serwera proxy usługi WCF dla aplikacji klienckiej oraz zainicjowanie go przy użyciu poświadczeń na potrzeby uwierzytelnienia w usłudze RP-STS.
  3. Włączenie mechanizmu WIF w usłudze TodoListService w celu umożliwienia autoryzacji opartej na oświadczeniach.
  4. Zastosowanie wymogów uprawnień (IsInRole) lub innych metod sprawdzania autoryzacji w celu sterowania dostępem do operacji usługi lub innych funkcji.

Kroki te zostaną omówione w następnych sekcjach.

Udostępnianie federacyjnych punktów końcowych

Usługi WCF oparte na oświadczeniach zazwyczaj udostępniają federacyjne punkty końcowe, które otrzymują wydane tokeny, na przykład zgodne ze standardem SAML. Usługa WCF oferuje dwa powiązania do obsługi scenariuszy zabezpieczeń federacyjnych zgodnych z protokołem WS-Trust. WSFederationHttpBinding to oryginalne, standardowe powiązanie oparte na standardzie WS-Trust 2005 (jest to wcześniejsza wersja protokołu), natomiast WS2007FederationHttpBinding to najnowsza wersja powiązania (wydana wraz z oprogramowaniem Microsoft .NET Framework 3.5) obsługująca zatwierdzony standard WS-Trust 1.3. Zazwyczaj należy korzystać z powiązania WS2007FederationHttpBinding, chyba że konieczność zapewnienia współdziałania wymusza zastosowanie wcześniejszej wersji. Usługa STS oparta na programie ADFS w wersji 2 lub platformie WIF obsługuje obie wersje protokołu WS-Trust.

Podczas udostępniania federacyjnego punktu końcowego usługi zwykle podaje się informacje na temat oczekiwanego formatu tokenu zabezpieczeń, wymaganych i opcjonalnych typów oświadczeń oraz zaufanego wystawcy tokenów. Na rysunku 3 przedstawiono kod modelu system.serviceModel usługi TodoListService, która udostępnia pojedynczy federacyjny punkt końcowy za pośrednictwem powiązania WS2007FederationHttpBinding.

Rysunek 3. Federacyjny punkt końcowy udostępniony przez usługę TodoListService.

<system.serviceModel>
  <services>
    <service name="TodoList.TodoListService" 
behaviorConfiguration="serviceBehavior">
      <endpoint address="" binding="ws2007FederationHttpBinding" bindingConfiguration="wsFed" contract="Contracts.ITodoListService" />
      <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      <host>
        <baseAddresses>
          <add baseAddress="https://localhost:8000/TodoListService"/>
        </baseAddresses>
      </host>
    </service>
  </services>
  <bindings>
    <ws2007FederationHttpBinding>
      <binding name="wsFed">
        <security mode="Message" issuedTokenType=
“http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-.1#SAMLV1.1" issuedKeyType="SymmetricKey" negotiateServiceCredential="true">
          <message>
            <claimTypeRequirements>
              <add claimType= 
“https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" isOptional="false"/>
              <add claimType= "urn:TodoListApp/2009/06/claims/permission" 
isOptional="false"/>
            <claimTypeRequirements>
            <issuerMetadata address="https://localhost:8010/rpsts/mex" />
          </message>
        </security>
      </binding>
    </ws2007FederationHttpBinding>
  </bindings>
  <behaviors>
    <serviceBehaviors>
      <behavior name="serviceBehavior">
        <serviceMetadata/>
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Scenariusze zabezpieczeń federacyjnych zazwyczaj są oparte na tokenach SAML, choć nie jest to ścisłym wymogiem. W tym scenariuszu zostały użyte tokeny SAML 1.1, na co wskazuje identyfikator URI issuedTokenType (docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf). W przypadku alternatywnego typu tokenu, takiego jak SAML 1.0 lub SAML 2.0, należy użyć identyfikatora URI odpowiedniego dla danego standardu. Oczywiście usługa STS wskazana w konfiguracji powiązania federacyjnego musi obsługiwać żądany typ tokenu.

Inne ważne ustawienia w sekcji komunikatu to issuedKeyType oraz negotiateServiceCredential. Ustawienie issuedKeyType wskazuje, czy klucz potwierdzenia (zobacz stronę pod adresem blogs.msdn.com/vbertocci/archive/2008/01/02/on-prooftokens.aspx) jest symetryczny (wartość domyślna), czy też asymetryczny (wymaga większego narzutu). To ustawienie również musi być zgodne z usługą STS. Jeśli ustawienie negotiateServiceCredential ma wartość „true”, klient nie wymaga uprzedniego dostępu do klucza publicznego domeny RP, ale negocjacja nie jest realizowana za pomocą protokołu gwarantującego współdziałanie. Jeśli klient nie jest zgodny z platformą WCF, należy przypisać ustawieniu negotiateServiceCredential wartość „false”. Nie jest to jednak powód do zmartwień. Po ustawieniu wartości “false” serwer proxy generuje za pomocą narzędzia SvcUtil kopię klucza publicznego domeny RP zakodowaną przy użyciu algorytmu base64.

Typy oświadczeń podane w sekcji claimTypeRequirements wskazują wymagane i opcjonalne oświadczenia używane przez usługę na potrzeby autoryzacji. W tym przypadku usługa oczekuje na oświadczenie nazwy w celu zidentyfikowania użytkownika oraz na co najmniej jedno niestandardowe oświadczenie uprawnień, które określa prawa użytkownika do tworzenia, odczytu, aktualizowania lub usuwania elementów Todo. (Te typy oświadczeń zostały wymienione na rysunku 4poniżej). Lista typów oświadczeń znajduje się w metadanych usługi, zatem dany klient może uwzględnić te informacje w żądaniu RST. Usługa STS często zna oświadczenia, które zostaną wydane dla określonej domeny RP, co oznacza, że lista w powiązaniu federacji nie musi zawierać wszystkich oświadczeń.

Rysunek 4. Oświadczenia wydawane dla użytkownika w scenariuszu aplikacji Todo List.

W tym scenariuszu zaufanym wystawcą tokenu jest usługa RP-STS zaimplementowana w ramach platformy WIF. Usługa RP-STS udostępnia pojedynczy punkt końcowy protokołu WS-Trust pod adresem https://localhost:8010/rpsts, a adres wymiany metadanych to https://localhost:8010/rpsts/mex. Na rysunku 3 adres metadanych wystawcy jest podany w sekcji issuerMetadata, zatem serwer proxy wygenerowany przez klienta jest w stanie wykryć dostępne punkty końcowe usługi STS.

Załóżmy, że usługa STS ma udostępniać wiele punktów końcowych, na przykład w celu uwierzytelniania użytkowników w intranecie za pomocą poświadczeń systemu Windows Windows (pod adresem https://localhost:8010/rpsts/internal) oraz uwierzytelniania użytkowników w Internecie przy użyciu nazwy użytkownika i hasła (pod adresem https://localhost:8010/rpsts/external). Usługa RP może określić konkretny punkt końcowy wystawcy powiązany z konfiguracją federacyjnego punktu końcowego, aby po wygenerowaniu serwera proxy przez klienta konfiguracja komunikacji z usługą STS była zgodna z tym, a nie pierwszym zgodnym punktem końcowym. Cel ten można osiągnąć, podając adresy metadanych (issuerMetadata) i elementów dostawcy w następujący sposób:

<issuerMetadata address="https://localhost:8010/rpsts/mex" />
<issuer address="https://localhost:8010/rpsts/mex/external" />

Zaletą takiego podejścia jest uproszczenie generowania serwerów proxy dla klientów, gdy dostępnych jest wiele punktów końcowych STS, a domena RP ma mieć wpływ na wybór używanego punktu końcowego. Jeśli domena RP nie decyduje o punkcie końcowym uwierzytelniania klienta, najlepiej jest określić wyłącznie ustawienie issuerMetadata i umożliwić aplikacji klienckiej określenie odpowiedniego punktu końcowego uwierzytelniania.

Należy pamiętać, że jeśli konfiguracja usługi nie uwzględnia elementu issuerMetadata i zawiera tylko adres wystawcy, adres ten powinien być przypisany do logicznego identyfikatora URI (https://localhost:8010/rpsts/issuer), który nie musi być mapowany na fizyczny adres punktu końcowego usługi STS. Odpowiednia konfiguracja po stronie klienta spowoduje wyświetlenie użytkownikowi monitu o wybranie zarządzanej karty informacyjnej pochodzącej od tego samego dostawcy (za pośrednictwem usługi Windows CardSpace). Karta musi również spełniać kryteria dotyczące formatu żądanego tokenu i typów oświadczeń. Więcej informacji na temat scenariuszy federacji aktywnej za pomocą usługi Windows CardSpace można znaleźć pod adresem wpfandcardspace.codeplex.com.

Generowanie serwera proxy klienta

W przypadku generowania serwera proxy dla klienta systemu Windows za pomocą narzędzia SvcUtil lub polecenia Dodaj odwołanie do usługi adres wymiany metadanych wystawcy jest używany do gromadzenia informacji o punktach końcowych udostępnionych przez wystawcę. Możliwe są m.in. następujące scenariusze:

  • Jeśli powiązanie federacji dla punktu końcowego usługi RP podaje adres metadanych wystawcy bez adresu danego wystawcy, konfiguracja klienta będzie uwzględniać pierwszy punkt końcowy STS zgodny z protokołem oraz inne zgodne punkty końcowe, skomentowane i dostępne do użycia przez dewelopera po stronie klienta.
  • Jeśli powiązanie federacji dla usługi RP podaje adres metadanych wystawcy i jego konkretny adres, konfiguracja klienta będzie uwzględniać ten adres (o ile jest on zgodny z protokołem).
  • Jeśli powiązanie federacji dla usługi RP podaje tylko adres metadanych, konfiguracja klienta będzie uwzględniać wyłącznie ten adres i nie będzie zawierać konfiguracji powiązania dla wystawcy. Jak wspomniano wcześniej, oznacza to, że zostanie uruchomiony selektor tożsamości, taki jak CardSpace.

Jeśli klient generuje serwer proxy dla usługi TodoListService o konfiguracji podanej na rysunku 3, a usługa STS udostępnia pojedynczy punkt końcowy, wersja konfiguracji powiązania WS2007FederationHttpBinding po stronie klienta będzie uwzględniać następujące ustawienia wystawcy i jego metadanych (issuerMetadata):

<issuer address="https://localhost:8010/rpsts" 
        binding="ws2007HttpBinding" 
        bindingConfiguration="https://localhost:8010/rpsts">
  <identity>
    <certificate encodedValue="[certyfikat RP-STS zakodowany za pomocą algorytmu base64]" />
  </identity>
</issuer>
<issuerMetadata address="https://localhost:8010/rpsts/mex" />

Należy pamiętać, że element wystawcy określa punkt końcowy wystawcy i konfigurację powiązania wymaganą do komunikacji z tym punktem końcowym. W takiej sytuacji klient uwierzytelnia się w usłudze STS przy użyciu nazwy użytkownika i hasła zgodnie z zabezpieczeniami komunikatów, jak przedstawiono w następującej konfiguracji powiązania WS2007HttpBinding:

<ws2007HttpBinding>
    <binding name="https://localhost:8010/rpsts" >
        <security mode="Message">
            <message clientCredentialType="UserName" 
                     negotiateServiceCredential="false" 
                     algorithmSuite="Default" 
                     establishSecurityContext="false" />
        </security>
    </binding>
</ws2007HttpBinding>

Punkt końcowy klienta kojarzy konfigurację powiązania federacji z punktem końcowym usługi RP:

<client>
  <endpoint address="https://localhost:8000/TodoListService" 
            binding="ws2007FederationHttpBinding" 
            bindingConfiguration="wsFed"
            contract="TodoList.ITodoListService" name="default">
    <identity>
      <certificate encodedValue="[certyfikat RP-STS zakodowany za pomocą algorytmu base64]" />
    </identity>
  </endpoint>
</client>

W przypadku takiej konfiguracji przed wywołaniem usługi wystarczy zainicjować serwer proxy klienta przy użyciu prawidłowej nawy użytkownika i hasła:

TodoListServiceProxy _Proxy = new TodoListServiceProxy("default");

if (!ShowLogin()) return;

this._Proxy.ClientCredentials.UserName.UserName = this.Username;
this._Proxy.ClientCredentials.UserName.Password = this.Password;
this._TodoItems = this._Proxy.GetItems();

Wydawanie tokenu

Serwer proxy najpierw podaje poświadczenia umożliwiające uwierzytelnienie w usłudze RP-STS, wysyłając żądanie (RST) tokenu zabezpieczeń SAML 1.1, co wskazuje, że domena RP wymaga co najmniej jednej nazwy i oświadczenia uprawnień. Użytkownik jest uwierzytelniany na podstawie danych w magazynie poświadczeń STS, a po uwierzytelnieniu uzyskuje odpowiednie oświadczenia. Następnie serwer proxy przetwarza odpowiedź RSTR zawierającą wydany token i przekazuje go do domeny RP w celu zainicjowania bezpiecznej sesji uwierzytelnionego użytkownika.

W tym przykładzie usługa STS jest oparta na platformie WIF i uwierzytelnia użytkowników na podstawie niestandardowego magazynu poświadczeń, wydając oświadczenia dla poszczególnych użytkowników, jak pokazano na rysunku 4.

Należy pamiętać, że usługa STS oparta na programie ADFS w wersji 2 uwierzytelnia użytkowników na podstawie domeny systemu Windows i wydaje oświadczenia zgodnie z konfiguracją środowiska ADFS. Niestandardowa usługa STS oparta na platformie WIF może uwierzytelniać użytkowników na podstawie dowolnego magazynu poświadczeń, ale niezbędne jest samodzielne wdrożenie kodu zarządzającego tym magazynem oraz procesem mapowania odpowiednich oświadczeń.