AD FS 2.0 в решениях для идентификации

ADFS 2.0Применение Active Directory Federation Services 2.0 в решениях для идентификации

Зульфигар Ахмед (Zulfiqar Ahmed)

Загрузка примера кода

Как разработчик вы наверняка хотя бы слышали о Windows Identity Foundation (WIF), которая ранее называлась Geneva Framework и которая предоставляет мощный API для поддержки заявок в приложениях и создания собственных сервисов Security Token Service (STS). Менее известна служба Active Directory Federation Services версии 2.0 (ADFS 2.0), изначально проходившая под кодовым названием «Geneva Server»; это корпоративное решение для объединения в федерацию и поддержки единого входа (single sign-on, SSO). ADFS 2.0 является эволюционным развитием ADFS 1.0 и поддерживает варианты с активной (WS-Trust) и пассивной федерацией (WS-Federation и SAML 2.0).

Я начну с обзора ADFS 2.0, а потом расскажу, как разработчики могут использовать ADFS 2.0 в своих решениях для идентификации. Основное внимание я уделю функциональности выдачи маркеров в ADFS 2.0, основанной на второй бета-версии. Как видно из рис. 1, выдача маркеров — не более чем малая часть ADFS 2.0, но она представляет особый интерес для .NET-разработчиков, переходящих к поддержке федеративной идентификации. С архитектурной точки зрения, ADFS 2.0 опирается на WIF и Windows Communication Foundation (WCF), поэтому, если вы хорошо знаете эти технологии, то без проблем освоите ADFS 2.0.

Рис. 1 Архитектура ADFS 2.0

Обзор ADFS 2.0

На высоком уровне ADFS 2.0 можно считать набором сервисов, показанных на рис. 2.

Центральное место в ADFS 2.0 занимает сервис маркеров защиты (Security Token Service, STS), который использует Active Directory как хранилище идентификаций, а также Lightweight Directory Access Protocol (LDAP), SQL или собственную базу данных как хранилище атрибутов. STS в ADFS 2.0 может выдавать маркеры защиты по различным протоколам, в том числе WS-Trust, WS-Federation и Security Assertion Markup Language (SAML) 2.0. ADFS 2.0 STS также поддерживает форматы маркеров SAML 1.1 и SAML 2.0.

ADFS 2.0 спроектирована с четким разделением между сетевыми протоколами и внутренним механизмом выдачи маркеров. Различные сетевые протоколы преобразуются в стандартизованную объектную модель на входе в систему, и на внутреннем уровне ADFS 2.0 использует одну и ту же объектную модель для каждого протокола. Это разделение делает возможным модель расширения ADFS 2.0, независимую от внутреннего устройства разных сетевых протоколов. Более подробные сведения о расширяемости ADFS 2.0 будут изложены в ADFS 2.0 SDK перед выпуском RTM-версии этой службы.

Рис. 2 Компоненты ADFS 2.0

ADFS 2.0 как провайдер идентификаций

Вы можете применять ADFS 2.0 в нескольких распространенных случаях. Самый простой и часто встречающийся из них — использование ADFS 2.0 в качестве провайдера идентификаций, благодаря чему она может выпускать SAML-маркеры для управляемых ею идентификаций. С этой целью нужно создать новую доверяющую сторону (relying party, RP). Доверяющая сторона в ADFS 2.0 — это представление приложения (веб-сайта или веб-сервиса), которое содержит всю информацию, связанную с защитой, например сертификат шифрования, правила преобразования заявок и т. д.

Настройка RP

Настройка новой RP через ADFS 2.0 осуществляется довольно легко. Вы можете воспользоваться мастером Add Relying Party через режим Policy в консоли управления ADFS 2.0. В этом мастере вы или системный администратор должны указать подходящие источники данных на странице Select Data Source мастера (рис. 3).

Рис. 3 Страница Select Data Source в мастере Add Relying Party

Первые два варианта позволяют автоматически сконфигурировать RP, используя метаданные федерации. Если у вас есть доступ к таким метаданным в сети или в локальном файле, выберите один из первых двух переключателей.В этом случае меньше вероятность ошибок, обеспечивается полная автоматизация процесса и возможность автоматического обновления любых деталей конфигурации RP, если они вдруг изменятся в будущем. Поддержка этих вариантов — важное усовершенствование по сравнению с ADFS 1.0, в которой не было такой автоматизации процессов.

Третий вариант требует ручного ввода всех деталей конфигурации. Выбирайте соответствующий переключатель, только когда у вас нет доступа к метаданным федерации или когда вам нужен полный контроль над всеми деталями конфигурации RP.

А вообще очень поучительно пройти все этапы после выбора переключателя Enter relying party configuration manually просто для того, чтобы представлять, что нужно для настройки новой RP. На следующих нескольких страницах мастера вам предложат выбрать профиль — щелкните ADFS 2.0 Profile, если вы хотите поддерживать клиенты как на основе браузеров, так и на основе WCF, либо ADFS 1.x Profile, если вам нужна совместимость с ADFS 1.x и не требуется поддержка активных клиентов (WCF, CardSpace).Настройте сертификат для шифрования маркера, чтобы только RP с соответствующим закрытым ключом могла расшифровать и использовать выданный маркер.Затем укажите идентификатор, который будет идентифицировать эту RP во всех запросах на выдачу маркера.

После мастера Add Relying Party открывается Rules Editor. В этой утилите вы настраиваете правила выдачи и преобразования. На рис. 4 показан Rules Editor, сконфигурированный на выдачу маркера с одной заявкой, значение которой будет извлекаться из основного хранилища атрибутов. Заметьте, что атрибут displayName сопоставлен с заявкой Given Name. В ADFS 2.0 введен новый язык, специфичный для предметной области, который позволяет определять простые правила выдачи маркеров и преобразования заявок. Каждое правило состоит из условия и действия и заканчивается — как в [c] =>> a; — точкой с запятой. Логика преобразования — это серия правил, последовательно выполняемых в процессе выпуска маркера. Для определения этих правил на вкладке Simple View предоставляется специальный UI (рис. 4). Вкладка Advanced View позволяет создавать правила, напрямую используя язык, специфичный для предметной области.

Рис.4 Средство Rules Editor

Этот пример иллюстрирует, насколько легко сконфигурировать RP в ADFS 2.0. К моменту, когда ADFS 2.0 принимает запрос на выдачу маркера, она извлекает идентификатор из данных сетевого протокола (например, элемент appliesTo в случае WS-Trust) и использует его для поиска целевой RP. Найдя таковую, ADFS 2.0 использует параметры, заданные в мастере, для создания логики выдачи маркера.

Теперь рассмотрим, как с помощью WCF запросить маркер для данной RP от ADFS 2.0.

Запрос маркера с применением WCF

Существует два варианта взаимодействия с ADFS 2.0 STS при использовании WCF:

• явно запрашивать маркер, выступая в роли клиента WS-Trust;
• настраивать WCF-клиент так, чтобы инфраструктура неявно запрашивала маркер в процессе вызова.

В первом варианте вы используете класс WSTrustClient, который предоставляет простой API для запроса маркеров напрямую от STS по протоколу WS-Trust:

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);

Этот код запрашивает маркер, используя аутентификацию средствами Windows с защитой по транспортному протоколу. Как видите, в явном режиме вы получаете доступ к необработанному маркеру, который впоследствии можно будет использовать для вызова сервисов. Например, в смарт-клиенте вы могли бы запрашивать маркеры для различных сервисов в период запуска приложения или в процессе входа, сохранять их в кеше маркеров, а затем применять их на протяжении всего жизненного цикла приложения. Кроме того, в ситуации, когда многие сервисы находятся в пределах одних и тех же логических границ безопасности и используют один и тот же сертификат, явный режим позволяет получить единый маркер, который вы впоследствии будете применять для вызова всех этих сервисов.

В тестовой среде, где вы обычно имеете доступ к закрытому ключу RP, можно использовать следующий код для извлечения SAML-утверждения (assertion) из возвращаемого маркера:

//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="https://schemas.xmlsoap.org/ws/2005/05/identity/claims">
    <saml:AttributeValue>Zulfiqar Ahmed</saml:AttributeValue>
</saml:Attribute>

SAML-маркер содержит только заявки, настроенные для данной конкретной RP. Вернитесь к рис. 4, где показано, как маркер для этой RP был настроен так, чтобы возвращать единственный атрибут. Вы можете отредактировать конфигурацию RP и включить в выдаваемый маркер больше заявок; при этом все они должны быть отражены здесь. Кроме того, можно использовать язык политики заявок, чтобы напрямую определить логику преобразований и фильтрации.

Как WSTrustClient API, так и новые привязки WSTrust являются частью WIF, поэтому, чтобы предыдущий код мог работать, на клиенте нужно установить WIF. Вы, конечно, можете напрямую использовать WCF API для явного получения маркера, но WIF проще и удобнее.

В коде на рис. 5 IssuedSecurityTokenProvider является WCF-эквивалентом WSTrustClient и обычно используется привязкой wsFederationBinding при запросе маркеров в ваших интересах. Поскольку это открытый API, вы можете свободно применять его в своем коде, если вам нужен доступ к необработанным маркерам. Ну и CustomBinding — эквивалент WindowsWSTrustBinding.

Рис. 5 Доступ к необработанному маркеру через IssuedSecurityTokenProvider

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));

В неявном варианте можно использовать стандартную привязку wsFederationHttpBinding, и в этом случае инфраструктура WCF прозрачно получает маркер и посылает его сервису при вызове. Всякий раз, когда вы создаете новый WCF-прокси и применяете его для вызова сервиса, инфраструктура получает за вас новый маркер. Очевидно, что в некоторых ситуациях это перехлест. Код на рис. 6 настраивает фиктивный EmployeeService для запроса маркеров от ADFS 2.0.

Рис. 6 Неявное получение маркера через wsFederationHttpBinding

<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>

Связь концепций ADFS 2.0 с WCF

Основная задача ADFS 2.0 — выдавать маркеры аутентифицированным пользователям. Аутентификация может выполняться по разным механизмам (например, средствами Windows). Вы можете увидеть все поддерживаемые механизмы аутентификации, выбрав узел Endpoints в консоли управления.

Просматривая названия столбцов в Endpoints вы заметите две знакомые концепции безопасности WCF.

• Authentication Type в ADFS 2.0 эквивалентен clientCredentialType в WCF.
• Для Security Mode можно выбрать значения Transport, Message или Mixed. Mixed в ADFS 2.0 эквивалентен TransportWithMessageCredentials в WCF.

Различные комбинации значений этих двух параметров доступны через разные конечные точки, и вы выбираете конкретную конечную точку, исходя из своих требований к аутентификации. Например, если вам нужна аутентификация с использованием имени и пароля, вы можете выбрать конечную точку Clear Password.

В случае ADFS 2.0 STS, спроецировав эти концепции обратно на Address, Binding и Contract (ABC) в WCF, вы получите следующие эквиваленты:

• Address = базовый адрес ADFS 2.0 + URL Path конечной точки;
• Binding = Security Mode конечной точки + Authentication Type;
• Contract = стандартный протокол WS-Trust.

Объединение ADFS 2.0 в федерацию с другим STS

Кроме создания доверяющих сторон, вы можете устанавливать доверительные отношения между ADFS 2.0 и собственным STS или другой службой ADFS 2.0. Например, если у вас уже есть STS, который аутентифицирует пользователей и выдает маркеры, вы можете просто добавить его в качестве доверяемого провайдера идентификаций в ADFS 2.0, которая будет принимать маркеры, выдаваемые этим STS.

Настройка в качестве провайдера идентификаций

Настройка нового доверяемого провайдера идентификаций в ADFS 2.0 аналогична настройке новой RP. Используемый при этом мастер Add Identity Provider выглядит и работает во многом похоже на мастер Add Relying Party (вернитесь к рис. 3).

Чтобы попасть на страницу Configure Identifier, вновь выберите вариант настройки вручную (как это делалось на рис. 3) и на странице Choose Profile укажите ADFS 2.0 Profile. На странице Configure URL оставьте настройки, предлагаемые по умолчанию. Затем выберите идентификатор и сертификат открытого ключа для своего провайдера идентификаций и нажмите кнопку Finish в мастере, чтобы зарегистрировать новый провайдер идентификаций.

Запрос маркера с применением WCF

После регистрации дополнительного провайдера идентификаций в ADFS 2.0 логическая архитектура выглядит примерно как конфигурация, показанная на рис. 7.

Рис. 7 Архитектура ADFS 2.0 с дополнительным провайдером идентификаций

Код на рис. 8 позволяет явно получать маркер, что дает возможность локально кешировать его и передавать сервису по мере необходимости.

Рис. 8 Явное получение маркера через IssuedTokenWSTrustBinding

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);

IssuedTokenWSTrustBinding очень похожа на wsFederationHttpBinding в том плане, что она скрывает все сложности, связанные с промежуточными маркерами, прозрачно взаимодействуя с IP-STS для получения промежуточного маркера, который потом посылается R-STS в качестве маркера аутентификации.

Код на рис. 9 использует wsFederationHttpBinding, чтобы WCF-клиент мог неявно получить маркер в процессе вызова сервиса.

Заметьте, что я использую customBinding при взаимодействии с конечной точкой /IssuedTokenMixedSymmetricBasic256. Стандартная wsFederationHttpBinding здесь не работает, потому что она пытается установить защищенный сеанс, несовместимый с данной конечной точкой ADFS 2.0. Для объединения WCF-клиентов в федерацию с ADFS 2.0 нужно использовать либо customBinding, либо одну из новых привязок на основе WSTrust, поставляемых с WIF.

Рис. 9 Неявное получение маркера через wsFederationHttpBinding

<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>

ADFS 2.0 и клиенты, выполняемые в браузере

ADFS 2.0 полностью поддерживает единый вход через Web (WebSSO) и объединение в федерацию с применением протоколов WS-Federation или SAML 2.0.

Концептуально WS-Federation и протокол SAML похожи, даже несмотря на то, что они имеют разные форматы. Сетевой формат WS-Federation тесно связан с протоколом WS-Trust, поэтому он является логичным выбором, когда вы обслуживаете как активные, так и пассивные (выполняемые в браузере) клиенты. Протокол SAML обладает более широкой совместимостью. ADFS 2.0 полностью поддерживает оба протокола. Правильнее использовать один протокол (например, WS-Federation) в рамках ваших границ безопасности и применять ADFS 2.0 как концентратор-посредник различных протоколов для входящих и исходящих SSO-запросов.

Рассмотрим пример. Допустим, у вас есть простое приложение ASP.NET, функциональность которого доступна только аутентифицированным пользователям. Это автономное приложение, логика аутентификации реализована внутри него, поэтому взаимодействие с приложением потребует выполнения операций, показанных на рис. 10.

Рис.10 Прямая аутентификация в простом приложении ASP.NET

Здесь реализованы обычные механизмы аутентификации ASP.NET, например на основе форм. Наша цель — отделить функциональность аутентификации от этого приложения и задействовать ADFS 2.0.

В системе с ADFS 2.0, приведенной на рис. 11, приложение становится доверяющей стороной в ADFS 2.0 и поэтому доверяет маркерам, выдаваемым ADFS 2.0. Приложение использует WIF для выполнения всей черновой работы, связанной с разбором маркеров, извлечением заявок и т. д. Информация об идентификации предоставляется приложению через стандартные абстракции IIdentity/IPrincipal.

Распределенная аутентификация в ADFS 2.0 гораздо гибче прямой аутентификации и дает следующие основные преимущества.

• Аутентификация выносится из приложения, поэтому ее механизм можно изменять, не влияя на само приложение.
• Благодаря гибкости модели на основе заявок приложение может получать всю необходимую информацию как часть маркера, а не из множества разных источников.

Во второй бета-версии WIF введены новые шаблоны проектов, которые упрощают выделение логики аутентификации из приложений в STS. На момент написания статьи такие шаблоны были доступны только в C#.

Рис.11 Распределенная аутентификация в ADFS 2.0

Выделение логики аутентификации

Для выделения этой логики из приложения используйте диалоговое окно New Web Site в Microsoft Visual Studio. Выберите шаблон Claims-aware Web Site для создания стандартного веб-сайта ASP.NET с уже настроенными параметрами WIF.

Чтобы запустить мастер Federation Utility (рис. 12), щелкните правой кнопкой мыши узел Web Site в Solution Explorer и выберите Modify STS Reference из меню.

Рис.12 Federation Utility

В данном примере мы выберем параметр Use an existing STS и укажем ADFS 2.0 в качестве STS. Мастеру потребуется URL документа метаданных для автоматического создания всех необходимых конфигураций. URL документа метаданных доступен как конечная точка в ADFS 2.0.

Метаданные федерации содержат важную информацию, в том числе сертификат подписи STS, предлагаемые заявки и URL, по которому осуществляется выдача маркеров. Стандартизованный формат этой информации дает возможность автоматизировать установление доверительных отношений между STS и доверяющими сторонами.

На странице Summary мастера дается сводный список изменений, которые будут внесены в файл web.config.

Мастер Federation Utility настраивает WIF для вашего веб-сайта, чтобы обеспечить следующую функциональность.

• Все неаутентифицированные запросы будут перенаправляться в ADFS 2.0.
• Любой запрос, содержащий действительный маркер, будет обработан, а информация об идентификации будет представлена приложению в виде ClaimsIdentity/ClaimsPrincipal. Приложение будет по-прежнему обращаться к этой информации с использованием стандартных абстракций IPrincipal/IIdentity независимо от ее источника.

Перед тестированием приложения вам нужно внести еще одно изменение в конфигурацию ADFS 2.0. Вы должны создать дополнительную конечную точку RP для клиентов на основе браузера. Такая точка необходима из-за того, что после обработки запроса на выдачу маркера в ADFS 2.0 потребуются две части данных, прежде чем эта служба сможет вернуть маркер браузеру:

• адрес, по которому следует отправить маркер;
• протокол (SAML или WS-Federation), по которому будет передан маркер.

Вы можете добавить к RP пассивную конечную точку на вкладке Endpoints диалогового окна Test RP Properties. Например, если вы выбираете WS-Federation в качестве Endpoint Type, то ADFS 2.0 будет возвращать маркеры RP по протоколу WS-Federation. А уже внутри RP инфраструктура WIF, полностью поддерживающая протокол WS-Federation, будет обрабатывать эти маркеры.

Теперь, когда вы попытаетесь перейти к приложению, вы будете автоматически переадресованы в ADFS 2.0 для аутентификации, где сможете выбрать метод аутентификации: Windows Integrated Authentication, Certificate Authentication или Username/Password Form.

После успешной проверки подлинности вы (вместе с маркером, выданным ADFS 2.0) будете перенаправлены обратно в приложение. WIF обработает этот маркер и создаст конечную идентификацию (в виде заявок), доступную приложению через стандартные механизмы ASP.NET (например, Page.User).

Федерация на основе браузера

Базовый сценарий внешней аутентификации можно расширить в федеративный, создав дополнительный доверяемый провайдер идентификаций. Параметры провайдера идентификаций показываются в процессе аутентификации.

Вы можете проходить проверку подлинности с помощью ADFS 2.0 или другого доверяемого провайдера идентификаций. Во втором случае вы перенаправляетесь в этот провайдер и после успешной аутентификации возвращаетесь в ADFS 2.0, которая потом аутентифицирует вас на основе маркера, выданного доверяемым провайдером идентификаций.

Мощный инструмент

Как вы видели в этой статье, ADFS 2.0 STS предоставляет простое готовое решение для поддержки заявок в ваших WCF-сервисах и приложениях на основе браузеров. Сам STS является не более чем малой частью ADFS 2.0, которая также включает систему обеспечения CardSpace, механизм преобразований на основе правил, инфраструктуру автоматизированного управления доверительными отношениями, сервисы управления и конфигурирования вместе с соответствующими средствами. В сочетании с WIF служба ADFS 2.0 становится мощным инструментом для программирования решений в области идентификации на платформе Windows.

Зульфигар АхмедЗульфигар Ахмед (Zulfiqar Ahmed) — старший консультант в группе UK Application Development Consulting (ADC).С ним можно связаться через веб-сайт http://zamd.net