В данном сценарии описывается приложение или веб-сайт с ресурсами высокой и низкой ценности, для доступа к которым предъявляются различные требования. Обычно приложение или веб-сайт сначала выполняет проверку подлинности пользователя с помощью менее надежного метода, а впоследствии, когда пользователь пытается получить доступ к особо ценным ресурсам, проверка подлинности выполняется с помощью более надежного метода.
Строгость метода проверки подлинности зависит от конкретного приложения; например, в некоторых приложениях в качестве менее надежного метода проверки подлинности используется проверка подлинности с помощью пароля, а в качестве более надежного — проверка подлинности с помощью смарт-карт. В других приложениях в качестве менее надежного метода проверки подлинности используется проверка подлинности с помощью сертификата, а в качестве более надежного — биометрическая проверка подлинности по отпечаткам пальцев. Ниже описаны ключевые аспекты данного сценария, не зависящие от используемых методов проверки подлинности.
- Способ взаимодействия приложения при
использовании необходимого метода проверки подлинности с
поставщиком, в роли которого выступает служба STS.
- Способ обработки службой запроса для
конкретного метода проверки подлинности.
Поскольку платформа WIF основана на стандартах (WS-*) и поддерживает спецификацию WS-Federation 1.2, она поддерживает и перечисленные выше ключевые аспекты.
На приведенной ниже схеме проиллюстрирован типичный сценарий многоэтапной проверки подлинности, в котором сотрудник Fabrikam.com получает доступ к ресурсам с высокой и низкой ценностью, предоставляемым приложением Contoso.com.
В сценарии участвуют следующие вымышленные пользователи:
- Владимир: системный администратор компании
Fabrikam, сотрудник, пытающийся получить доступ к ресурсам
Contoso.
- Дмитрий: разработчик приложения Contoso,
вносящий в него необходимые изменения.
- Андрей: системный администратор компании
Contoso.
Компоненты, задействованные в сценарии:
- web1: веб-приложение с ресурсами низкой
(LowValueResourcePage.aspx) и высокой (HighValueResourcePage.aspx)
ценности, в котором для загрузки данных из хранилища на сервере SQL
Server используется специальная веб-служба.
- sts1: служба STS, выполняющая функции
поставщика утверждений и выдающая утверждения, которые необходимы
приложению (web1).
- sts2: служба STS, выполняющая функции
поставщика удостоверений для Fabrikam.com и предоставляющая две
конечные точки: одну для менее надежного метода проверки
подлинности, другую — для более надежного. Для этой службы
установлено отношение доверия с Contoso.com, чтобы сотрудникам
Fabrikam был разрешен доступ к ресурсам Contoso.com.
Как показано на предыдущей диаграмме, в данном сценарии используется следующий поток.
- Приложение Contoso настроено на использование необходимых
утверждений для предоставления пользователю Fabrikam доступа к
защищенным ресурсам высокой и низкой ценности с помощью
соответствующих методов проверки подлинности. Дмитрий внес в
приложение необходимые изменения.
- Пользователь Fabrikam, Владимир, получает доступ к странице
приложения Contoso и по умолчанию входит в систему с помощью менее
надежного метода проверки подлинности.
- Пользователь Fabrikam, Владимир, пытается получить доступ к
особо ценному ресурсу и ему предлагается пройти дополнительную
проверку подлинности с помощью более надежного метода.
Основные этапы сценария
Обратите внимание, что данный сценарий носит исключительно иллюстративный характер. Фактические этапы его реализации в производственной среде могут отличаться от описанных.
Настройка поставщика удостоверений
Для администратора Fabrikam.com, Владимира, возможно три варианта действий:
- Приобрести и установить службу STS, такую как Службы федерации
Active Directory® (AD FS) 2.0.
- Подписаться на веб-службу STS, такую как LiveID STS.
- Создать пользовательскую службу STS с использованием WIF.
В данном сценарии предполагается, что Владимир выбрал
первый вариант и установил в качестве службы STS и поставщика
удостоверений службу Службы федерации Active Directory 2.0. Для
поддержки обоих методов проверки подлинности (более и менее
надежного) Владимир предоставляет в своей службе STS две конечных
точки: \windowsauth и \smartcardauth.
Изучив документацию к продукту Службы федерации Active Directory
2.0, Владимир устанавливает отношение доверия с доменом
Contoso.com.
Настройка поставщика утверждений
Возможные варианты действий Андрея, администратора Contoso.com, не отличаются от описанных выше вариантов для поставщика удостоверений. В данном сценарии предполагается, что Андрей выбирает первый вариант и устанавливает в качестве службы STS проверяющей стороны службу Службы федерации Active Directory 2.0. Изучив документацию к продукту Службы федерации Active Directory 2.0, Андрей устанавливает отношение доверия с доменом Fabrikam.com и самим приложением. Он также настраивает утверждения, необходимые приложению для предоставления доступа к ресурсам высокой и низкой ценности.
Изменения для конкретного приложения
Перечисленные ниже изменения расширяют возможности приложения и позволяют обеспечить поддержку многоэтапной проверки подлинности.
- Идентификация необходимых утверждений (то
есть стойкость методов проверки подлинности) для ресурсов высокой и
низкой ценности.
- Установление отношения доверия с поставщиком
утверждений с помощью Установление отношения
доверия между приложением проверяющей стороны ASP.NET и службой STS
с помощью FedUtil.
- Реализация в приложении поддержки
утверждений.
- Реализация перехода от менее надежной
проверки подлинности к более надежной.
Идентификация утверждений, необходимых для ресурсов с высокой и низкой ценностью
Приложение может запросить настраиваемое утверждение
или утверждение authenticationmethod, выпущенное
платформой по умолчанию. Значение этого утверждения должно
использоваться в качестве меры стойкости метода проверки
подлинности. В данном сценарии утверждение
authenticationmethod помечено как обязательное. Если
это утверждение принимает значение "CertorSmartcard", пользователю
предоставляется доступ к обоим типам ресурсов (с высокой и низкой
ценностью). Если же это утверждение принимает значение
"windowsauth", пользователю предоставляется доступ только к
ресурсам с низкой ценностью.
Дополнительные сведения об утверждении
authenticationmethod и возможных значениях для
различных типов маркеров см. в разделе Модель удостоверений на
основе утверждений.
Приложение может передать поставщику утверждений
сведения о необходимом методе проверки подлинности через параметр
wauth, описанный в спецификациях WS-Federation. Кроме
того, приложение может делегировать все аспекты проверки
подлинности поставщику утверждений и указать в качестве
обязательного утверждения собственное утверждение (например
утверждение privilegelevel с возможными значениями
"lowvalue" и "highvalue").
В данном сценарии используется параметр
wauth с двумя возможными настраиваемыми значениями:
"authstrength1" для ресурсов с низкой ценностью и "authstrength5"
для ресурсов с высокой ценностью.
В приведенном ниже примере кода продемонстрировано
использование элемента управления
FederatedPassiveSignIn для присвоения значений стойкости
проверки подлинности и передачи этих значений поставщику
утверждений. Обратите внимание, что параметр
AuthenticationType сериализуется "на лету" как
параметр WS-Federation wauth.
 Копировать код |
|
|---|---|
<wif:FederatedPassiveSignIn AuthenticationType=https://WIFSample/authstrength1 ID="FederatedPassiveSignIn1" runat="Server" Issuer="https://sts1.contoso.com/AuthPassive/Default.aspx" SignInButtonType="Link" TitleText="Щелкните приведенную ниже ссылку, чтобы получить доступ к ресурсам с низкой ценностью" SignInText="Доступ к ресурсам с низкой ценностью" Realm="https://web1.contoso.com/AuthAssuranceRP/Default.aspx" OnSignInError="FederatedPassiveSignIn_SignInError" DisplayRememberMe="false" VisibleWhenSignedIn="false"> </wif:FederatedPassiveSignIn> |
|
Поставщик утверждений Contoso (sts1) обрабатывает
параметр wauth и перенаправляет пользователя на
соответствующую конечную точку поставщика удостоверений Fabrikam
(sts2).
Установление отношения доверия с поставщиком утверждений с помощью средства FedUtil
Чтобы принимать маркеры, выпущенные поставщиком утверждений, приложение должно установить отношение доверия с поставщиком требований. Установление отношения доверия между приложением проверяющей стороны ASP.NET и службой STS с помощью FedUtil позволяет выполнить эту задачу в два этапа:
- Регистрация приложения: FedUtil загружает метаданные федерации
из sts1 (служба STS проверяющей стороны) и приложения, выбирает
необходимые утверждения и обновляет файл web.config приложения.
- Публикация приложения: FedUtil создает метаданные федерации для
приложения (файл metadata.xml) и сохраняет их в папке приложения.
Эти данные доступны службе STS проверяющей стороны по запросу HTTP
GET.
Дополнительные сведения см. в разделе Установление отношения доверия между приложением проверяющей стороны ASP.NET и службой STS с помощью FedUtil.
Реализация в приложении поддержки утверждений и многоэтапной проверки подлинности
Для использования утверждений для многоэтапной проверки
подлинности и выполнения других задач, связанных с удостоверениями,
приложение должно извлекать утверждения из класса IClaimsPrincipal
и проверять наличие обязательного утверждения
authenticationmethod.
Подробные сведения о реализации в приложении поддержки утверждений см в подразделе ASP.NET раздела Создание приложений проверяющей стороны.
В приведенном ниже примере кода показано, как на
странице ресурса с высокой ценностью выполняется проверка
утверждения authenticationmethod, а доступ к странице
предоставляется только в том случае, если это утверждение принимает
значение "CertOrSmartcard". В данном примере кода также показано,
как перенаправить пользователя на страницу входа с многоэтапной
проверкой подлинности:
| Копировать код |
|
|---|---|
if ( Page.User.Identity.IsAuthenticated == true ) { if ( GetAuthStrengthClaim() != "CertOrSmartcard" ) { // Проверка подлинности пользователя выполнена с низкой степенью надежности. // Выполнить перенаправление на страницу входа с более надежным методом проверки подлинности. Response.Redirect( "HighAssuranceSignInPage.aspx" ); } // В противном случае пользователь успешно прошел проверку подлинности с высокой степенью надежности. // Разрешить доступ к ресурсам с высокой ценностью. } else { // Проверка подлинности пользователя не выполнена. Перенаправить пользователя на страницу "Default.aspx" Response.Redirect( "Default.aspx" ); }
private string GetAuthStrengthClaim() { IClaimsIdentity claimsIdentity = (IClaimsIdentity)((IClaimsPrincipal)Thread.CurrentPrincipal).Identities[0];
// Поиск утверждения проверки подлинности. IEnumerable<Claim> claimCollection = ( from c in claimsIdentity.Claims where c.ClaimType == System.IdentityModel.Claims.ClaimTypes.Authentication select c ); if ( claimCollection.Count<Claim>() > 0 ) { return claimCollection.First<Claim>().Value; }
return String.Empty; }
|
|
На странице HighAssuranceSignInPage.aspx размещен
элемент управления
FederatedPassiveSignIn с соответствующей конечной точкой
поставщика и параметром AuthenticationType:
| Копировать код |
|
|---|---|
<wif:FederatedPassiveSignIn AuthenticationType=https://WIFSample/authstrength5 ID="FederatedPassiveSignIn1" runat="Server" Issuer="https://sts2.fabrikam.com/AuthPassiveSTSCert/Login.aspx" SignInButtonType="Link" SignInButtonStyle-Height="50px" AutoSignIn="false" SignInText="High Assurance Sign-In" TitleText="Щелкните приведенную ниже ссылку, чтобы выполнить проверку подлинности с высокой степенью надежности" Realm="https://web1.contoso.com/AuthAssuranceRP/HighAssuranceSignInPage.aspx" OnSignInError="FederatedPassiveSignIn1_SignInError" VisibleWhenSignedIn="true" DisplayRememberMe="false"> <SignInButtonStyle Height="50px" /> </wif:FederatedPassiveSignIn> |
|
Автоматический переход к новой коллекции утверждений после успешной многоэтапной проверки подлинности
Одним из сложных аспектов данного сценария является автоматическое добавление утверждений пользователя с повышенными правами при успешной многоэтапной проверке подлинности.
Пользователь входит в систему с помощью исходного метода проверки подлинности ("windowsauth") и выпускает коллекцию утверждений (ClaimsCollectionA). Когда пользователь пытается получить доступ к ресурсам с высокой ценностью, он перенаправляется на страницу для многоэтапной проверки подлинности, как было показано в предыдущем разделе. После успешной повторной проверки подлинности выпускается новая коллекция утверждений (ClaimsCollectionB). Эту коллекцию необходимо обновить в удостоверении пользователя, чтобы при проверке приложением доступа к ресурсам с высокой ценностью в коллекции присутствовало необходимое утверждение.
Модуль WSFederationAuthenticationModule выполняет эту задачу путем обновления маркера безопасности сеанса на основе последних полученных утверждений. Это означает, что когда пользователь изначально входит в систему с помощью проверки подлинности Windows, модуль WSFAM выпускает маркер безопасности сеанса с необходимыми утверждениями; когда пользователь проходит многоэтапную проверку подлинности с помощью сертификата, модуль WSFAM обнаруживает, что пользователь уже прошел проверку подлинности и был выпущен новый маркер, и обновляет маркер безопасности сеанса на основе новой коллекции утверждений.
При новой проверке подлинности модуль WSFAM по
умолчанию запишет новый куки-файл, содержащий только новые
утверждения. Если приложению проверяющей стороны необходимо, чтобы
второй набор утверждений был добавлен к исходному набору, в
приложении необходимо обработать событие
SessionSecurityTokenCreated, создаваемое элементом
управления на странице входа. На этом этапе проверка подлинности
пользователя была выполнена с использованием старых утверждений (в
Thread.CurrentPrincipal), однако приложение также
получило доступ к новым утверждениям в аргументах события, что
позволяет объединить оба набора утверждений перед присвоением
свойству Thread.CurrentPrincipal нового значения. Все
настройки будут сохранены в новом куки-файле.
Примеры ресурсов
В комплект поставки WIF входит обширный список примеров. Поддержка многоэтапной проверки подлинности в WIF показана в примере End-to-end\Authentication Assurance. Обратите внимание, что данный пример подразумевает работу в одной системе с двумя настраиваемыми службами маркеров безопасности поставщика удостоверений и проверяющей стороны.