Windows® Identity Foundation (WIF) поддерживает федеративную проверку подлинности в приложениях ASP.NET с помощью модуля WS-FAM. В этом разделе объясняются принципы работы федеративной проверки подлинности и способы ее применения.

Общие сведения о федеративной проверке подлинности

Федеративная проверка подлинности позволяет службе STS, находящейся в одном домене доверия, предоставлять сведения о проверке подлинности службе STS, находящейся в другом домене доверия, если между этими доменами установлено отношение доверия. Эта идея проиллюстрирована на приведенном ниже рисунке.

  1. Клиент в домене доверия Fabrikam отправляет запрос приложению проверяющей стороны в домене доверия Contoso.

  2. Проверяющая сторона перенаправляет клиента на службу STS в домене доверия Contoso. Эта служба не имеет сведений о клиенте.

  3. Служба STS Contoso перенаправляет клиента на службу STS в домене доверия Fabrikam, с которым у домена Contoso установлено отношение доверия.

  4. Служба STS Fabrikam проверяет удостоверение клиента и выпускает маркер безопасности для службы STS Contoso.

  5. Служба STS Contoso создает на основе маркера Fabrikam собственный маркер, распознаваемый проверяющей стороной, и отправляет его проверяющей стороне.

  6. Проверяющая сторона извлекает из маркера безопасности утверждения клиента и принимает решение об авторизации.

Использование модуля федеративной проверки подлинности с ASP.NET

Модуль WSFederationAuthenticationModule (WS-FAM) представляет собой HTTP-модуль, позволяющий добавить в приложение ASP.NET поддержку федеративной проверки подлинности. Федеративная проверка подлинности позволяет делегировать обработку логики проверки подлинности службе STS, а разработчику сосредоточиться на написании бизнес-логики.

При настройке модуля WS-FAM необходимо указать службу STS, на которую будут перенаправляться запросы, не связанные с проверкой подлинности. WIF позволяет выполнить проверку подлинности пользователя двумя способами:

  1. С помощью элемента управления FederatedPassiveSignIn. Когда непроверенный пользователь пытается получить доступ к защищенному ресурсу, такой пользователь перенаправляется на страницу входа в приложение. На странице входа расположен элемент управления FederatedPassiveSignIn, настроенный на основе сведений поставщика (службы STS). Если защита всего приложения не требуется и достаточно только страницы входа в приложение, на которой пользователи будут работать с данным элементом управления (в качестве примера такого приложения можно привести сайт финансового учреждения), то такой подход оправдан.

  2. Пассивное перенаправление: такой подход используется, когда непроверенный пользователь пытается получить доступ к защищенному ресурсу, и этого пользователя необходимо просто перенаправить службе STS, минуя страницу входа. Служба STS проверяет удостоверение пользователя и выпускает маркер безопасности, содержащий необходимые утверждения для этого пользователя. Для реализации этого подхода необходимо добавить в конвейер модулей HTTP модуль WS-FAM. Дополнительные сведения см. в разделе Установление отношения доверия между приложением проверяющей стороны ASP.NET и службой STS с помощью FedUtil.

При пассивном перенаправлении обмен данными происходит через ответ или перенаправление на стороне клиента (как правило, браузера). Модуль WS-FAM поддерживает два способа пассивного перенаправления.

  1. Можно добавить модуль WS-FAM в конвейер HTTP приложения, где этот модуль будет отслеживать запросы непроверенных пользователей и перенаправлять таких пользователей на указанную службу STS.

  2. Можно создать экземпляр модуля WS-FAM и использовать его для проверки запросов. Именно по этому принципу и работает элемент управления FederatedPassiveSignIn.

Модуль WS-FAM также создает несколько событий, позволяющих настроить его функции в приложении ASP.NET.

Принципы работы модуля WS-FAM

Модуль WS-FAM реализован в классе WSFederationAuthenticationModule. Как правило, модуль WS-FAM добавляется в конвейер HTTP приложения проверяющей стороны ASP.NET. Когда непроверенный пользователь пытается получить доступ к защищенному ресурсу, проверяющая сторона возвращает ответ HTTP "401 в авторизации отказано". Модуль WS-FAM перехватывает этот ответ, не позволяя клиенту получить его, и перенаправляет пользователя на указанную службу STS. Служба STS выпускает маркер безопасности, который опять перехватывается модулем WS-FAM. На основе этого маркера модуль WS-FAM создает для прошедшего проверку пользователя экземпляр класса IClaimsPrincipal, который позволяет применить обычные механизмы авторизации .NET Framework.

Поскольку протокол HTTP не поддерживает сведения о состоянии, необходимо предусмотреть механизм, позволяющий избежать повторения этого процесса при каждой попытке доступа пользователя к защищенному ресурсу. Для этого используется модуль SessionAuthenticationModule. Когда служба STS выпускает для пользователя маркер безопасности, модуль SessionAuthenticationModule создает для пользователя маркер безопасности сеанса и сохраняет этот маркер в куки-файл. При последующих запросах модуль SessionAuthenticationModule перехватывает этот куки-файл и восстанавливает с его помощью объект IClaimsPrincipal пользователя.

Если необходимо обеспечить в приложении проверяющей стороны поддержку утверждений без использования службы STS (например, проверяющая сторона может использовать проверку подлинности с помощью форм или встроенную проверку подлинности Windows), воспользуйтесь модулем ClaimsPrincipalHttpModule. Этот модуль размещается в конвейере HTTP приложения и перехватывает сведения о проверке подлинности. Этот модуль создает для каждого пользователя объект IClaimsPrincipal, используя имя пользователя, сведения о членстве в группах и иные сведения, необходимые для проверки подлинности. Модуль ClaimsPrincipalHttpModule необходимо поместить в конец конвейера <httpModules>, который является первым элементом в разделе <modules> объекта <system.webServer> служб IIS 7.

На приведенной ниже схеме показан весь поток данных при перенаправлении пользователя на страницу входа для установления учетных данных и последующем перенаправлении на целевую страницу после проверки подлинности.

На приведенной ниже схеме подробно показано, что происходит при проверке подлинности пользователя в службе STS и отправке маркеров безопасности на страницу входа.

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

На приведенной ниже схеме показан весь поток данных при пассивном перенаправлении. Запрос автоматически перенаправляется через службу STS для установления учетных данных без использования страницы входа.

На приведенной ниже схеме подробно показано, что происходит при проверке подлинности пользователя в службе STS и обработке маркеров безопасности модулем WSFederationAuthenticationModule.

События

Классы WSFederationAuthenticationModule и SessionAuthenticationModule и их родительский класс, HttpModuleBase, создают события на разных этапах обработки HTTP-запроса. Эти события обрабатываются в файле global.asax приложения ASP.NET.

  • При перехвате маркера безопасности, выпущенного службой STS, модуль WS-FAM создает событие SecurityTokenReceived.

  • После проверки маркера модуль WS-FAM создает событие SecurityTokenValidated.

  • При создании для пользователя маркера безопасности сеанса модуль SessionAuthenticationModule создает событие SessionSecurityTokenCreated.

  • При перехвате последующих запросов с куки-файлом, который содержит маркер безопасности сеанса, модуль SessionAuthenticationModule создает событие SessionSecurityTokenReceived.

  • Перед тем как перенаправить пользователя поставщику, модуль WS-FAM создает событие RedirectingToIdentityProvider с параметром "federation request". Перед отправкой запроса поставщику запрос можно изменить.

  • При успешной записи куки-файла и входе пользователя в систему модуль WS-FAM создает событие SignedIn.

  • Модуль WS-FAM создает событие SigningOut один раз за сеанс при закрытии сеанса для каждого пользователя. Это событие не создается, если сеанс закрывается на стороне клиента (например при удалении куки-файла сеанса). В среде с единым входом служба STS поставщика удостоверений также может отправить каждой проверяющей стороне запрос на выход из системы. В этом случае также создается это событие, в котором свойству IsIPInitiated присвоено значение true.

Примечание.
Свойство Thread.CurrentPrincipal нельзя использовать во время событий, создаваемых модулями WSFederationAuthenticationModule и SessionAuthenticationModule. Значение свойства Thread.CurrentPrincipal задается после проверки подлинности, а события вызываются во время этого процесса.

Поддерживаемые сценарии

Ниже перечислены сценарии, поддерживаемые модулем WS-FAM.

  • Доступ к утверждениям в приложении проверяющей стороны ASP.NET, в котором для проверки подлинности используется WS-Federation. Если в приложении проверяющей стороны используется проверка подлинности с помощью форм или встроенная проверка подлинности Windows, необходимо использовать только модуль ClaimsPrincipalHttpModule. Дополнительные сведения см. в разделе Инструкции: доступ к утверждениям на странице ASP.NET.

  • Вход в приложение ASP.NET с помощью управляемой карточки. В этом случае можно использовать только модуль SessionAuthenticationModule.

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

В следующем фрагменте конфигурации описаны атрибуты, которые можно настроить в элементе конфигурации <federatedAuthentication>:

  Копировать код
<federatedAuthentication> <!-- <wsFederattion> определяет значения параметров для службы STS, работающей по протоколу WS-FEDERATION. Этот атрибут определяет параметры модуля WSFederationAuthenticationModule.

АТРИБУТЫ

passiveRedirectEnabled — Boolean — значение по умолчанию: false Определяет, включено ли в модуле автоматическое перенаправление несанкционированных запросов на службу STS.

issuer — String — значение по умолчанию: "" Универсальный код ресурса (URI) поставщика маркеров.

realm — String — значение по умолчанию: "" Универсальный код ресурса (URI) запрашивающей области.

freshness — Float — значение по умолчанию: "" Значение требуемой свежести.

reply — String — значение по умолчанию: "" Универсальный код ресурса (URI) адреса для ответа.

request — String — значение по умолчанию: "" Универсальный код ресурса (URI) запроса WS-FEDERATION.

requestPtr — String — значение по умолчанию: "" Универсальный код ресурса (URI) указателя запроса WS-FEDERATION.

resource — String — значение по умолчанию: "" Универсальный код ресурса (URI) значения запроса WS-FEDERATION.

authenticationType — String — значение по умолчанию: "" Параметр wauth, указанный приложением для службы STS

requireHttps — Boolean — значение по умолчанию: false Логический флаг, указывающий, требуется ли использование протокола HTTPS для URL-адреса поставщика

signInMode — String — значение по умолчанию: "Session" Указывает, предназначен ли данный куки-файл для использования в сеансе или одноразового использования

homeRealm — String — значение по умолчанию: "" Ввод значения homeRealm

signInQueryString — String — значение по умолчанию: ""

signOutQueryString — String — значение по умолчанию: ""

signOutReply — String — значение по умолчанию: ""

--> <wsFederation passiveRedirectEnabled="true|false" issuer="http://sts.com/request.aspx" realm="http://sts.com/request.aspx" freshness="10" reply="" request="" requestPtr="" resource="" /> <!-- <cookieHandler> задает обработчик CookieHandler, предназначенный для чтения и записи необработанных куки-файлов на уровне протокола HTTP. В модуле SessionAuthenticationModule обработчик cookieHandler используется для чтения и записи куки-файлов.

РЕЖИМЫ

Default (по умолчанию) То же самое, что и Chunked.

Chunked Используется экземпляр класса ChunkedCookieHandler. Этот обработчик куки-файлов гарантирует, что размер отдельных куки-файлов не превысит максимально допустимый. Это обеспечивается путем "разбиения" одного логического куки-файла на несколько более мелких.

Custom Используется экземпляр настраиваемого класса, производного от класса CookieHandler, на который ссылается элемент <customCookieHandler>.

АТРИБУТЫ

domain — String — значение по умолчанию: "" Значение домена для всех записываемых куки-файлов.

hideFromScript — Boolean — значение по умолчанию: true Определяет, будет ли для записываемых куки-файлов использоваться флаг "HttpOnly". Некоторые браузеры используют этот флаг, запрещая сценариям на стороне клиента доступ к значению куки-файла.

name — String — значение по умолчанию: "FedAuth" Определяет базовое имя для записываемых куки-файлов.

path — String — значение по умолчанию: HttpRuntime.AppDomainAppVirtualPath Определяет путь для записываемых куки-файлов. 

requireSsl — Boolean — значение по умолчанию: false Определяет, будет ли для записываемых куки-файлов использоваться флаг "Secure" . Если это значение задано, куки-файлы сеанса будут доступны только по протоколу HTTPS.

--> <cookieHandler mode="Default|Chunked|Custom" domain=".example.com" hideFromScript="true" name="FedAuth" path="/" requireSsl="false"> <!-- Атрибут <chunkedCookieHandler> может использоваться только в режиме cookieHandler/@mode Default или Chunked. Он управляет обработчиком ChunkedCookieHandler.

АТРИБУТЫ

chunkSize — Int32 — значение по умолчанию: 2000 Максимальный размер (в знаках) данных куки-файла HTTP для каждого отдельного куки-файла HTTP. При настройке этого атрибута следует проявлять осторожность. В разных браузерах установлены различные ограничения на размер куки-файлов и их количество на каждый домен. В спецификации Netscape указаны следующие ограничения: 300 куки-файлов всего, 4096 байт на заголовок куки-файла (включая метаданные, а не только значение куки-файла) и 20 куки-файлов на каждый домен. 

--> <chunkedCookieHandler chunkSize="2000" /> <!-- Атрибут <customCookieHandler> может использоваться только в режиме cookieManager/@mode Custom. Этот атрибут ссылается на настраиваемый тип, который должен быть производным от CookieHandler. См. примечания перед элементом <configuration> в ссылках на настраиваемый тип.

--> <customCookieHandler type="MyTypes.MyCookieHandler, MyTypes" /> </cookieHandler> </federatedAuthentication>
Примечание.
Если параметр wauth задается приложением, то проверка его надежности должна также выполняться в приложении. WIF не выполняет подобную проверку.
Примечание.
Если атрибут requiredClaims задается в конфигурации приложения, приложение должно проверить эти утверждения в классе ClaimsAuthenticationManager. WIF не выполняет подобную проверку.