Windows identity foundation что это

Windows Identity Foundation ошибка 0x80096002

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Pyatilistnik.org. В прошлой статье мы подробно рассмотрели вопрос по решению ошибки STOP 0x00000050 сопровождающейся синим экранов Windows. Сегодня я хочу вас научить, как обойти ошибку установки Windows Identity Foundation в Windows Server 2012 R2 и Windows 8.1, ошибка имеет код 0x80096002 (Недопустимый сертификат лица, подписавшего сообщение или сертификат не найден).

Описание проблемы

У меня есть RDS ферма, состоящая из хостов Windows Server 2012 R2. В данную RDS ферму был добавлен новый хост подключений. Пользователь запустил на нем определенный софт, где сразу выскочила ошибка:

Установка Windows Identity Foundation

Когда вы начнете искать, что такое компонент Windows Identity Foundation, то вас приведет на ветку обсуждения, где попросят установить в вашу Windows 8.1 или Windows Server 2012 R2 обновление Windows6.1-KB974405-x64 (https://www.microsoft.com/ru-ru/download/details.aspx?id=17331. Скачав его и попытавшись запустить я получил ошибку:

Я не стал вдаваться в ситуацию, что за сертификат и чем подписан данный пакет, мне нужно было найти решение. В Windows Server 2012 R2 компонент Windows Identity Foundation устанавливается как фича. Вы запускаете PowerShell, и пишите:

В итоге вам покажут, что для установки доступен пакет «Windows Identity Foundation 3.5». Установим его командой:

Начнется установка пакета.

Проверяем установленный пакет Windows Identity Foundation 3.5, у него теперь статус «Installed».

Пробуем теперь запустить ваше приложение, ошибка «Не удалось загрузить файл или сборку Microsoft IdentityModel, Version=3.5.0.0» должна исправиться.

Так же проинсталлировать Windows Identity Foundation вы можете и через графический интерфейс, для этого откройте оснастку диспетчера серверов и выберите пункт «Добавить роли и компоненты».

Доходим до окна с выбором компонентов, где выставляем галку Windows Identity Foundation 3.5, после чего производим установку.

Если нужно установить компонент WID 3.5 в Windows 8.1, то откройте панель управления и выберите раздел «Программы и компоненты»

Перейдите в раздел «Включение или отключение компонентов Windows»

Установите галку Windows Identity Foundation 3.5 и нажмите «Ok», компонент будет добавлен в вашу операционную систему.

Источник

Windows identity foundation что это

Windows® Identity Foundation (WIF) — это платформа для построения приложений, поддерживающих удостоверения. Платформа поддерживает на уровне абстракций протоколы WS-Trust и WS-Federation и предоставляет разработчикам программные интерфейсы (API) для построения служб маркеров безопасности (STS) и приложений, поддерживающих утверждения. Приложения могут использовать WIF для обработки маркеров, выданных службами STS, и принятия решений на основе удостоверений на уровне веб-приложения или веб-службы.

Ниже перечислены основные возможности WIF.

Шаблоны Visual Studio WIF предлагает встроенные шаблоны Visual Studio для поддерживающих утверждения приложений веб-сайтов ASP.NET и веб-служб WCF и сокращает время на знакомство с моделью программирования на основе утверждений. Дополнительные сведения см. в разделе Шаблоны Visual Studio.

Установление отношений доверия между приложением, поддерживающим утверждения, и службой STS WIF предлагает служебную программу под названием FedUtil, которая позволяет легко устанавливать отношения доверия между приложениями, поддерживающими утверждения, и службой STS, например между службами федерации Active Directory2.0 и службой STS LiveID. FedUtil поддерживает приложения ASP.NET и WCF. Также эта программа интегрирована с Visual Studio, поэтому ее можно вызывать из обозревателя решений, щелкнув правой кнопкой проект и затем выбрав пункт «Добавить ссылку на службу STS», или из меню «Сервис» в Visual Studio. Дополнительные сведения см. в разделе FedUtil — служебная программа федерации для установления отношения доверия между проверяющей стороной и службой STS.

Элементы управления ASP.NET. Элементы управления ASP.NET упрощают разработку страниц ASP.NET для построения веб-приложений, поддерживающих утверждения. Дополнительные сведения см. в разделе Установление отношения доверия между приложением проверяющей стороны ASP.NET и службой STS с помощью элемента управления FederatedPassiveSignIn.

Преобразование утверждений в маркеры NT. WIF включает службу Windows под названием Служба c2WTS (Claims to Windows Token Service), которая выступает в роли посредника между поддерживающими утверждения приложениями и приложениями на основе маркеров NT. Она предоставляет разработчикам простой способ преобразования утверждений в удостоверение на основе маркера NT и позволяет регулировать доступ к ресурсам, которые запрашивают удостоверение на основе маркера NT у приложения, поддерживающего утверждения. Дополнительные сведения см. в разделе Общие сведения о службе c2WTS (Claims to Windows Token Service).

Добавление поддержки делегирования удостоверений в приложения, поддерживающие утверждения WIF предоставляет возможность поддерживать удостоверения исходных запрашивающих сторон в пределах нескольких служб. Эта возможность достигается за счет использования либо функции «ActAs», либо «OnBehalfOf» данной платформы и позволяет разработчикам добавлять поддержку делегирования удостоверений в приложения, поддерживающие удостоверения. Дополнительные сведения см. в разделах Интеграция с IIdentity и IPrincipal и Сценарий делегирования удостоверения.

Создание пользовательских служб маркеров безопасности (STS). WIF значительно облегчает создание пользовательской службы STS, которая поддерживает протокол WS-Trust. Такая служба также называется «активной службой STS».

Кроме того, платформа также обеспечивает возможности для создания служб STS, которые поддерживают протокол WS-Federation для включения клиентов веб-браузеров. Такие службы также называются «пассивными службами STS».

Платформа включает встроенные шаблоны Visual Studio для создания служб STS ASP.NET и WCF. Эти шаблоны позволяют создавать простые службы STS, а разработчики могут расширять их и реализовывать производственные службы, соответствующие их потребностям. Дополнительные сведения см. в разделах Инструкции: создание службы STS ASP.NET и Инструкции: создание службы STS WCF.

WIF поддерживает следующие основные сценарии.

Делегирование удостоверений. WIF позволяет поддерживать удостоверения сразу для нескольких служб, поэтому разработчики могут реализовать сценарий делегирования удостоверений. Дополнительные сведения см. в разделе Сценарий делегирования удостоверения.

Многоэтапная проверка подлинности. Требования к проверке подлинности для доступа к различным ресурсам в рамках одного приложения могут различаться. WIF предоставляет разработчикам возможность создания приложений, которые могут предъявлять возрастающие требования к проверке подлинности (например, начальный вход с проверкой подлинности с помощью имени пользователя и пароля, после чего используется проверка подлинности на основе смарт-карты). Дополнительные сведения см. в разделе Сценарий многоэтапной проверки подлинности.

WIF упрощает использование преимуществ модели удостоверений на основе утверждений, описанной в этой теме. В этой теме приводится обзор новых возможностей, предлагаемых в Windows® Identity Foundation (WIF) для обработки утверждений. Дополнительные сведения см. в Техническом документе по Windows Identity Foundation для разработчиков.

Доступ к утверждениям через Thread.CurrentPrincipal

Для доступа к набору утверждений текущего пользователя в приложении проверяющей стороны используйте Thread.CurrentPrincipal .

В следующем примере кода показано использование этого метода для получения интерфейса IClaimsIdentity:

Тип утверждения роли

Частью настройки приложения проверяющей стороны является определение типа утверждения роли. Этот тип утверждения используется методом IsInRole. Тип утверждения по умолчанию — http://schemas.microsoft.com/ws/2008/06/identity/claims/role .

Утверждения, извлеченные компонентом Windows Identity Foundation из маркеров различных типов

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

Сопоставление с маркером доступа Windows

GetOutputClaimsIdentity

Утверждение http://schemas.microsoft.com/ws/2008/06/identity/claims/confirmationkey , которое содержит сериализованный XML-код ключа подтверждения, если маркер содержит маркер проверки.

Утверждение http://schemas.microsoft.com/ws/2008/06/identity/claims/samlissuername из элемента Issuer.

Утверждения AuthenticationMethod и AuthenticationInstant, если маркер содержит инструкцию проверки подлинности.

В дополнение к утверждениям в разделе «SAML 1.1», кроме утверждений типа http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name , будут добавлены утверждения, связанные с проверкой подлинности Windows, и удостоверение будет представлено в WindowsClaimsIdentity.

См. «SAML 1.1, сопоставление с учетной записью Windows».

Утверждение AuthenticationMethod со значением http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/x509 . Утверждение AuthenticationInstant со значением, равным времени проверки сертификата в формате XmlSchema DateTime.

Утверждения из сертификата X509, не сопоставленные с Windows, и утверждения из учетной записи Windows, полученные путем сопоставления сертификата с Windows.

Утверждение AuthenticationMethod со значением http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password . Утверждение AuthenticationInstant со значением, равным времени проверки пароля в формате XmlSchema DateTime.

Windows (Kerberos или NTLM)

AuthenticationMethod со значением http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/ и название поставщика системы безопасности, проводящего проверку подлинности, в нижнем регистре (например, Kerberos, NTML, Negotiate и т. д.). Утверждение AuthenticationInstant со значением, равным времени создания маркера доступа Windows в формате XmlSchema DateTime.

Утверждение AuthenticationMethod со значением http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/signature . Утверждение AuthenticationInstant со значением, равным времени проверки подлинности ключа RSA (то есть времени проверки подписи) в формате XMLSchema DateTime.

Тип проверки подлинности

Коды URI, выпущенные в утверждении «AuthenticationMethod»

Источник

Экспресс-курс по изучению

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

Принятие авторизации на основе утверждений и федеративной модели безопасности позитивно отражается на приложениях WCF и ASP.NET по многим причинам. При организации безопасности на основе утверждений приложения отделяются от режима проверки подлинности; в результате такие обстоятельства, как изменение требований к учетным данным или поддержка новых типов, не отражаются на приложениях. И что важнее всего — авторизация на основе утверждений поддерживает федеративные модели безопасности. Наиболее важное предлагаемое преимущество модели федеративной безопасности состоит в том, что приложения могут предоставлять доступ пользователям, которые прошли процедуру аутентификации в другом домене. В результате сокращаются непроизводительные расходы в сфере ИТ, связанные с подготовкой и отзывом пользователей, снижается вероятность ошибок, проистекающих из управления повторяющимися учетными записями в различных приложениях и доменах, и открывается возможность безопасного установления доверительных отношений между приложениями, департаментами или даже между корпорациями.

Работая над статьей, я исходила из того, что читателям известно, в чем состоят преимущества от использования рассматриваемых технологий. Далее я кратко опишу концепцию федеративной безопасности, а за этим последует экспресс-обзор средств WIF для WCF и ASP.NET. Я подробно расскажу об участниках и о потоке коммуникации как для активного, так и для пассивного федерирования, разъясняя при этом базовые требования к каждому из сценариев с WIF. Кроме того, в общих чертах будет представлен процесс построения активной или пассивной службы маркеров безопасности Security Token Service (STS) с WIF.

Азы федеративной безопасности

Начнем с краткого введения в тему «федеративная безопасность». На рисунке 1 представлен сценарий федеративной безопасности, а также участники в самом общем виде.

Субъектом является сторона, которой будет предоставлен доступ к приложению. Как правило, это конечный пользователь, взаимодействующий с клиентским приложением или с веб-приложением через браузер.
Инициатором запроса является агент (клиентское приложение или браузер), запрашивающий маркер безопасности с описанием субъекта.
Проверяющей стороной Relying Party (RP) может быть веб-приложение (ASP.NET) или служба, которая подтверждает доступ к средствам и функциональным возможностям на основе утверждений, изложенных в маркере безопасности. Этот маркер должен быть выдан доверенным издателем маркеров.
Задача проверки прав доступа возлагается на провайдера удостоверений Identity Provider (IdP). Из этого следует, что в домене провайдера (скажем, в каталоге Active Directory или в специализированной базе данных учетных данных) имеется хранилище учетных данных.
Служба STS ответственна за выдачу субъекту маркера безопасности. Если STS размещена в провайдере удостоверений (IdP), она, вероятно, выдаст маркер безопасности, содержащий идентификационные утверждения для субъекта. STS может также предоставлять и иные утверждения, имеющие отношение к авторизации у проверяющей стороны.
В разных сценариях могут использоваться разные форматы маркеров безопасности; однако стоит отметить, что весьма популярным форматом маркеров при использовании федеративной модели является язык Security Assertion Markup Language (SAML). SAML — это совместимый формат маркеров безопасности на базе языка XML. Он позволяет транспортировать утверждения SAML: выпускающая служба STS подписывает маркер и, как правило, зашифровывает его для передачи проверяющей стороне.

Между проверяющей стороной и STS должны быть установлены доверительные отношения. Если служба STS не имеет сведений о той или иной проверяющей стороне, она не будет выдавать для нее маркеры. В свою очередь, проверяющая сторона не принимает маркеры от службы STS, которой она не доверяет. Проверяющая сторона указывает на необходимые для успешной аутентификации утверждения; инициатор запроса обращается к STS, запрашивая для субъекта маркер безопасности, в котором передаются требования проверяющей стороны и учетные данные для субъекта; STS (в провайдере удостоверений) проверяет подлинность субъекта, собирает утверждения по идентичности, а также иные относящиеся к делу утверждения и выдает маркер безопасности, содержащий эти утверждения. Запросившая сторона передает маркер проверяющей стороне для осуществления авторизации; проверяющая сторона удостоверяется в том, что маркер поступил от доверенного издателя, и предоставляет права доступа в соответствии с полученными утверждениями.

Этот коммуникационный поток основывается на протоколе WS-Trust (см. docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html). Инициирующая сторона передает службе STS запрос маркера безопасности Request for Security Token (RST) в соответствии с данной спецификацией, и STS направляет ей в ответ Request for Security Token Response (RSTR). В спецификацию WS-Federation (см. документацию WS-Trust 1.3 OASIS Standard) входят два профиля для федерации с WS-Trust: Active Requestor Profile (сценарий с использованием клиента с расширенными возможностями и веб-службы) и Passive Requestor Profile (сценарий с использованием браузера и веб-приложения). С помощью приложения WIF, созданного посредством. NET Framework, вы можете реализовывать сценарии, основанные на этих протоколах.

Windows Identity Foundation

WIF — новая модель идентичности для платформы. NET Framework. Она предоставляет средства, необходимые для построения приложений и служб на основе утверждений, для поддержки сценариев активной и пассивной федеративной безопасности и для создания по мере необходимости специализированных реализаций STS. Кроме того, модель располагает встроенными средствами поддержки информационных карточек (для выполнения сценариев, связанных с применением Windows CardSpace). WIF позволяет реализовывать сценарии на основе утверждений и сценарии федеративной безопасности с использованием гораздо меньших объемов кода. Вот несколько примеров того, что можно сделать с помощью модели WIF (это далеко не полный список).

Заменять классические механизмы безопасности WCF новым, более гибким механизмом вызовов аутентификации и авторизации. Это можно делать даже в тех случаях, когда модель федеративной безопасности не применяется.
Создавать для служб WCF модель безопасности на основе утверждений, которая хорошо интегрируется с классическими методами обеспечения безопасности. NET Framework на основе ролей.
Подобным же образом реализовывать на основе утверждений приложения ASP.NET, позволяющие задействовать классические приемы обеспечения безопасности на основе ролей, включая существующие элементы управления доступом ASP.NET.
Поддерживать пассивную федеративную систему в приложениях ASP.NET.
Реализовывать специализированную службу STS, соответствующую требованиям, которым не удовлетворяет существующая платформа STS, таким как Active Directory Federation Services (ADFS). Построение полнофункциональной специализированной STS связано с проведением больших объемов работ и потому должно рассматриваться как последнее средство.
Выпускать управляемые информационные карточки от STS для поддержки выбора идентичности с помощью CardSpace.
Поддерживать выбор информационных карточек с помощью приложений ASP. NET.

Разумеется, для каждой из перечисленных тем характерны те или иные детали реализации, и в каждом случае они могут быть специфичными. Их стоит обсудить в будущем. А пока вернемся к экспресс-курсу по изучению WIF.

Активное федерирование с использованием WIF

Для осуществления активного федерирования необходимо иметь клиентское приложение (источник запроса), веб-службу (проверяющая сторона) и службу STS для выдачи маркеров (эта служба может быть частью провайдера удостоверения). На рисунке 2 представлен простой сценарий активной федерации с использованием одной службы STS. В данном случае служба WCF проверяющей стороны экспонирует федеративную конечную точку; STS экспонирует конечную точку WS-Trust; клиент использует посредник WCF для подтверждения прав доступа к конечной точке STS и запрашивает маркер безопасности, а затем передает этот маркер по первому вызову проверяющей стороне, с тем чтобы установить для пользователя защищенный сеанс связи.

Настройка WIF для службы WCF

Для создания службы WCF необходимо экспонировать федеративную конечную точку и настроить службу для использования WIF. В листинге 1 показана возможная конфигурация для службы RP Service, представленной на рисунке 2.

К федеративной конечной точке применяется стандарт связывания S2007 FederationHttpBinding, основанный на спецификации WS-Trust 1.3 (которая является новейшей версией стандарта). В настройках связывания указываются следующие данные:

какой формат маркера ожидается, в данном случае это SAML 1.1;
какие утверждения необходимы, в данном случае указывается утверждение простого имени;
где размещается конечная точка обмена метаданными доверенного издателя; данные необходимы для того, чтобы клиент мог сформировать федеративный proxy.

В дополнение к федеративной конечной точке служба настраивается для WIF с использованием функции . Данная функция устанавливает компоненты FederatedServiceCredentials и IdentityModelServiceAuthorizationManager взамен применяемых по умолчанию ServiceCredentials и ServiceAuthorizationManager. Эти компоненты WIF (наряду с прочими) обеспечивают новый механизм обработки поступающих маркеров безопасности и адресованных службе вызовов авторизации. Их функционирование определяется отдельным разделом настроек , который активирует среду WIF. В листинге 2 показаны главные параметры, которые необходимо указать для службы WCF.

Итак, мы получили службу WCF, готовую к использованию в федеративной модели. Клиент будет генерировать proxy WCF из метаданных службы, основанных на этой настройке, и должен будет представить соответствующие учетные данные ClientCredentials для подтверждения прав доступа к STS. Для реализации активной федеративной модели установка среды WIF на клиенте не требуется, хотя надо сказать, что в эту среду входит ряд весьма полезных компонентов, применяемых в определенных реализациях клиентов.

Теперь, когда служба готова к работе в составе федерации, возникает вопрос: как осуществить авторизацию для получения доступа к операциям и базовым функциям? Если службу интересует только одно обстоятельство, а именно есть ли у пользователя право доступа к STS, достаточно установить, что маркер безопасности выдан доверенным провайдером. Скорее всего, вы будете исходить из того, что STS выдает маркер с утверждениями, полезными для целей получения авторизации, такими как роли или разрешения. WIF присоединяет к каждому потоку запросов прошедшего процедуру аутентификации участника безопасности — в данном случае типа ClaimsPrincipal, который представляет собой оболочку для коллекции утверждений из выданного маркера безопасности. Как и любой тип участника безопасности, реализующий IPrincipal, ClaimsPrincipal экспонирует метод IsInRole (), который может быть использован для реализации управления доступом.

Вы можете задействовать настройки модели идентичности для указания на то, какой тип утверждений представляет «роль» для вызовов IsInRole (), или написать код для проверки экземпляра ClaimsPrincipal на наличие определенного набора утверждений. Первая из моделей «чище», и для ее функционирования достаточно, чтобы с целью проверки доступа использовался только один тип утверждений.

Реализация активной STS с использованием WIF

В сценарии, представленном на рисунке 2, применяется специализированная STS, поэтому я кратко опишу, что нужно сделать для ее реализации. Впрочем, имейте в виду, что в этом сжатом описании для краткости я опускаю большое количество деталей. Весьма примитивную службу STS можно реализовать следующим образом.

Создайте подкласс на основе типа SecurityTokenService и выполните переопределение для GetScope () и GetOutputClaimsIdentity ().
С помощью одного из контрактов WS-Trust, реализованного в базовом типе STS, создайте конечную точку WCF для службы STS.

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

Переопределению для GetOutputClaimsIdentity () предоставляется доступ к участнику безопасности на основе IClaimsPrincipal. Этот тип содержит утверждения, касающиеся пользователя, прошедшего проверку подлинности; в данном случае они базируются на учетных данных пользователя, применяемых в системе Windows. Перед выпуском маркера обычно осуществляется конвертация этих утверждений в понятный набор утверждений для проверяющей стороны. Для этого нужно инициализировать новый экземпляр ClaimsIdentity. В данном примере хранилище учетных данных возвращает соответственные утверждения, касающиеся прошедшего аутентификацию пользователя. Для исследования дополнительных деталей вам следует рассмотреть образец кода, но, в сущности, изложенным выше исчерпываются главные аспекты простой реализации службы STS.

Представленная в листинге 4 настройка модели службы показывает, как демонстрационная STS из рисунка 2 экспонирует конечный пункт WS-Trust 1.3 с помощью синхронной версии контракта: IWSTrust13 SyncContract. Связывание основывается на принимаемых по умолчанию параметрах WS2007 HttpBinding; это означает, что для аутентификации вызовов службе STS требуются учетные данные Windows. В данном примере будет достаточно модели идентичности, принимаемой по умолчанию, — например, нет необходимости переопределять процедуру обработки входящих учетных данных.

Пассивное федерирование с использованием WIF

Для осуществления пассивного федерирования требуется браузер (запрашивающая сторона), веб-приложение (проверяющая сторона) и пассивная служба STS для выпуска маркеров. На рисунке 3 представлен простой сценарий пассивной федерации, где проверяющей стороной является приложение ASP.NET, предназначенное для реализации пассивной федерации, и специализированная STS, тоже пассивная — в том смысле, что она базируется на браузере, а не является реализацией службы на базе WCF. Когда пользователь ищет проверяющую сторону, он перенаправляется для аутентификации на STS, а затем, после получения маркера, вновь направляется на проверяющую сторону. В этот момент устанавливается сеанс безопасной связи и генерируется cookie-файл сеанса.

Пассивная федерация все еще связана с передачей сообщений по протоколу WS-Trust в форме RST и RSTR; в последнем случае применяется выданный маркер безопасности. Различие состоит в том, что они передаются как строки запроса и параметры формы, а не сообщения по протоколу Simple Object Access Protocol (SOAP). В следующих разделах речь пойдет о том, как настраиваются приложения ASP.NET, а также о пассивных реализациях STS.

Включение пассивной федерации для ASP.NET

Среда WIF включает в себя два модуля HTTP для поддержки пассивной федерации: WSFederationAuthenticationModule (FAM) и SessionAuthenticationModule. Модуль FAM отвечает за перенаправление с проверяющей стороны на STS и осуществляет обработку RSTR с целью извлечения маркера безопасности, а также установления ClaimsPrincipal для потока запросов. SessionAuthenticationModule управляет сеансом аутентификации: генерирует маркер безопасности сеанса, который содержит ClaimsPrincipal; записывает его в cookie-файл; управляет временем жизни cookie-файла сеанса и восстанавливает ClaimsPrincipal из cookie-файла, когда он есть. С целью подключения этих двух модулей добавьте показанный в листинге 5 код к разделу (для Microsoft IIS 6.x) и к разделу (для IIS 7).

Чтобы обеспечить возможность обработки запросов с помощью модуля FAM, необходимо для режима аутентификации выбрать параметр None и заблокировать доступ к узлу анонимных пользователей:

Кроме того, модуль FAM инициализируется посредством настройки модели идентичности. Вы должны указать по меньшей мере следующие параметры: список доверенных издателей сертификатов, идентификаторы URI уполномоченной аудитории, типы утверждений, необходимых для авторизации и конфигурацию для пассивной федерации. Первые три из них функционируют таким же образом, как и в активной федерации, тогда как настройка для пассивной федерации применяется лишь в сценариях ASP.NET. В листинге 6 представлен пример настройки модели идентификации для пассивного узла.

В разделе нужно включить функцию пассивного перенаправления, чтобы организовать пассивную федерацию для приложения ASP.NET. В результате модулю FAM будет предписано осуществлять процесс обработки поступающих на узел запросов и перенаправлять в службу STS все вызовы, не прошедшие процедуру аутентификации. Параметр «издатель» указывает на STS, куда следует перенаправлять вызовы. Область определения настроек фактически указывает издателю (как части RST), для кого будет выдан маркер, и эти данные должны соответствовать одному из кодов URI для соответствующей аудитории. Когда RSTR возвращается приложению, модуль FAM обрабатывает этот ответ и формирует ClaimsPrincipal для потока запросов.

И вновь ClaimsPrincipal оказывается полезным для управления доступом. При использовании приложений ASP.NET флажок IsInRole () полезен не только для динамических проверок; помимо прочего, этот метод инкапсулируется в большинстве элементов управления доступом. Вероятно, если вы сможете выбрать тот или иной тип утверждения в качестве «ролевого» типа утверждения (это настраиваемый параметр), у вас появится возможность продолжать реализацию безопасности на основе ролей с помощью привычных приемов; правда, нужно иметь в виду, что ролевая проверка превращается в проверку утверждений.

Реализация пассивной STS в среде WIF

В среде WIF пассивная STS может быть реализована двумя способами: с помощью элемента управления доступом FederatedPassiveTokenService (управляющий элемент STS) или при помощи модуля FAM с использованием дополнительного специального кода. Для простоты я остановлюсь на реализации с помощью управляющих элементов. Архитектура данной реализации представлена на рисунке 4 (будем исходить из того, что перед выпуском маркеров вы проверяете подлинность пользователей методом аутентификации с помощью форм).

Когда модуль FAM перенаправляет на STS вызов, поступивший проверяющей стороне, вместе с запросом передается и запрос маркера безопасности. В данном случае FormsAuthenticationModule перенаправит вызов на страницу регистрации, передавая исходный запрос в строке запроса ReturnUrl. В обратном послании страницы регистрации пользователь аутентифицируется (с помощью модели провайдера ASP.NET или специального кода), затем перенаправляется на ReturnUrl, который представляет собой исходный RST, и, вероятно, попадает на страницу, содержащую элемент управления STS.

Элемент управления STS обрабатывает входящие запросы RST до загрузки страницы (на этапе PreRender). Элемент управления связан со специализированной реализацией STS. Эта реализация STS программно предписывает модулю FAM сформировать ClaimsPrincipal для прошедшего аутентификацию пользователя, после чего вызываются те же переопределения для GetScope () и GetOutputClaimsIdentity (); последнее из них вновь отвечает за то, чтобы реальные утверждения были выпущены и включены в маркер безопасности. После этого элемент управления перенаправляет вызов обратно проверяющей стороне (URL, указывающий, куда следует адресовать ответ, содержится в RST), передавая RSTR в форме параметра POST. В этот момент модуль FAM обрабатывает RSTR на проверяющей стороне и устанавливает ClaimsPrincipal в поток запросов для авторизации.

Метод, предполагающий использование этого управляющего элемента, отличается изяществом; в данном случае требуется весьма малый объем кода — только код специализированной STS, как отмечалось выше. Разумеется, у него есть недостаток: значительная часть механизма пассивной федерации не поддается настройке, если не считать возможности осуществления нескольких простых переопределений до и после обработки RST. В следующих статьях я рассмотрю несколько более сложных сценариев, предполагающих индивидуализацию кода.

Источник

Windows identity foundation что это

<img onError="javascript: wp_broken_images = window.wp_broken_images || function(){}; wp_broken_images(this);" decoding="async" src="http://pyatilistnik.org/wp-content/uploads/2016/02/pyatilistnik-3.png"/>

Windows Identity Foundation ошибка 0x80096002

Windows Identity Foundation ошибка 0x80096002

Описание проблемы

Установка Windows Identity Foundation

Windows identity foundation что это

Доступ к утверждениям через Thread.CurrentPrincipal

Тип утверждения роли

Утверждения, извлеченные компонентом Windows Identity Foundation из маркеров различных типов

Экспресс-курс по изучению

Азы федеративной безопасности

Windows Identity Foundation

Активное федерирование с использованием WIF

Настройка WIF для службы WCF

Реализация активной STS с использованием WIF

Пассивное федерирование с использованием WIF

Включение пассивной федерации для ASP.NET

Реализация пассивной STS в среде WIF

Добавить комментарий Отменить ответ