Данный раздел посвящен вопросам проектирования.

• Рекомендации по использованию ClaimsPrincipal.IsInRole
  
  
• Ошибка входа в систему из-за регистра
  
  
• Определенные параметры конфигурации пропускаются
  
  
• Совместимость с IssuedTokenAuthentication.KnownCertificates
  
  
• Настройка виртуальных каталогов службы WCF для анонимного доступа
  
  
• ConfigureServiceHost
  
  
• Проверка подлинности SSPI с использованием куки-файлов не поддерживается
  
  
• Перенаправление FederatedPassiveSignIn.AutoSignIn
  
  
• Обработка параметров wtrealm и wreply
  
  
• Использование маркеров SAML 2
  
  
• Классы IPrincipal и IClaimsPrincipal
  
  
• Исключение "Превышена квота" при использовании маркеров SAML2, содержащих утверждения ActAs
  
  
• Защищенные диалоги
  
  
• Имя поставщика службы STS
  
  
• Срок действия SessionSecurityToken
  
  
• Некоторые утверждения и свойства ClaimsIdentity не сериализованы
  
  
• Режим проверки подлинности SPNego
  
  
• Ошибка при проверке SSL-сертификата
  
  
• Потокобезопасность при повторной сериализации маркеров начальной загрузки
  
  
• Совместимость флагов проверки подлинности WCF
  
  
• Команды WS-Trust
  
  

При включении WIF для службы WCF WSTrustServiceHost включает для службы автоматическую публикацию конечной точки MEX, поэтому виртуальный каталог службы необходимо настроить для анонимного доступа. WSTrustServiceHost, как правило, связывается со службой STS, однако к службе можно также добавить конечные точки, не являющиеся конечными точками службы STS. WIF не включает MEX для служб, не являющихся службами маркеров безопасности. Поддержку анонимного режима MEX можно отключить, присвоив свойству DisableWsdl значение true; это следует сделать в производственных средах, чтобы избежать некоторых MEX-атак. Также обратите внимание на то, что WIF включает MEX для тех базовых адресов, которые были зарегистрированы с WSTrustServiceHost, поэтому анонимный режим MEX включается только в том случае, если конечная точка была зарегистрирована с протоколом "http", а режим "MEX через HTTPS" доступен только в том случае, если конечная точка была зарегистрирована с протоколом "https".

Перечисленные ниже свойства предназначены для проверяющей стороны, поэтому они не сериализуются "на лету", а присвоение им значений во время выпуска маркеров не оказывает никакого влияния.

• Claim.Issuer. Свойство Issuer заполняется при получении возвращаемым значением IssuerNameRegistry для маркеров X509 и SAML.
  
  
• Claim.Properties. Свойство Properties по умолчанию пропускается и не сериализуется "на лету".
  
  
• ClaimsIdentity.Label. Свойство Label предназначено для заполнения при получении политикой проверяющей стороны.
  
  
• ClaimsIdentity.NameClaimType. Свойство NameClaimType предназначено для принимающей стороны. Этой свойство используется для выбора значения утверждения для IIdentity.Name.
  
  
• ClaimsIdentity.RoleClaimType. Свойство RoleClaimType предназначено для принимающей стороны. Это свойство используется для выбора значения утверждения для IsInRole() при выпуске маркера.
  
  
• ClaimsIdentity.AuthenticationType. Свойство AuthenticationType задается на принимающей стороне при проверке маркера обработчиком маркеров. В этом свойстве указывается способ проверки маркера.
  
  

При повторной сериализации маркеров начальной загрузки SAML (например при использовании ActAs) с использованием нескольких потоков необходимо синхронизировать вызовы; в противном случае маркеры могут быть повреждены. Дополнительные сведения об ActAs см. в разделах Сценарий делегирования удостоверения и Вопросы и ответы.

Метод ConfigureServiceHost настраивает проверяющую сторону Служба WCF (Windows Communication Foundation) с Windows® Identity Foundation (WIF). Чтобы указать сведения о конфигурации, перегрузите этот метод.

Если сеансы защищенного диалога между стороной, запрашивающей маркеры, и службой STS устанавливаться не будут, защищенные диалоги необходимо отключить. В отличие от класса WsHttpBinding класс WSFederationHttpBinding не позволяет отключить защищенные диалоги. Вместо этого необходимо создать настраиваемую привязку, заменяющую параметры защищенного сеанса на начальную загрузку. Конкретную реализацию подобного подхода см. в файле app.config клиента для примера Web Service/ClaimsAwareWebService в каталоге примеров. Необходимая конфигурация приведена ниже.

	Копировать код
<customBinding> <binding name="MyCustomBinding"> <security authenticationMode="IssuedTokenForCertificate"> </security> <!-- здесь идут другие элементы привязки, например httpTransport --> </binding> </customBinding>

Ключевой момент заключается в отказе от использования режима проверки подлинности SecureConversation. Сведения Дополнительные сведения о о реализации этой конфигурации в коде см. в разделе Инструкции: отключение защищенных диалогов для WsFederationHttpBinding.

Этот вопрос касается сценария, в котором настраивается несколько типов утверждений, а для контроля доступа используется метод IsInRole. Не рекомендуется использовать несколько типов утверждений ролей с одинаковыми значениями. Вместо этого рекомендуется использовать только один тип утверждения роли.

Предположим, например, что в системе настроено несколько типов утверждений ролей: http://.../Role и http://.../Group. Входящий маркер содержит утверждение Group:Editor. Если в приложении вызывается функция IsInRole(“Editor”), будет возвращено значение true, поскольку маркер содержит утверждение Group:Editor. Также предположим, что приложение должно предоставлять доступ только в том случае, если маркер содержит утверждение Role:Editor (иными словами, утверждения Group:Editor недостаточно). В настоящее время WIF такую возможность не поддерживает.

Также можно применить модель утверждений непосредственно, не используя метод IsInRole.

Режим проверки подлинности SPNego установлен для привязки WsHttpBinding по умолчанию. Режим SPNego поддерживается, если свойству RequireCancellation присвоено значение true или false. Однако этот режим не поддерживается, если свойству RequireCancellation присвоено значение false, поскольку это значение указывает на то, что на уровне согласования установлен режим куки-файлов. Если параметру RequireCancellation присвоено значение true, это указывает на то, что на уровне согласования установлен сеансовый режим, который поддерживается. Также обратите внимание, что при использовании SSPI объект ClaimsAuthenticationManager не вызывается.

Для режима SPNego утверждения http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod и http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant не создаются.

Наконец, в режиме SPNego не поддерживаются маркеры начальной загрузки. В этом случает коллекция маркеров начальной загрузки пуста.

Проверка подлинности SSPI с использованием куки-файлов не поддерживается. Неподдерживаемые привязки, выполняющие проверку подлинности SSPI, могут возникнуть в следующих случаях:

1. при преобразовании привязки WSHttpBinding в настраиваемую привязку с присвоением свойству RequireCancellation значения false;
   
   
2. при вызове метода SymmetricSecurityBindingElement.CreateSspiNegotiationBindingElement.
   
   

При использовании маркеров SAML 2, содержащих утверждения ActAs, может возникнуть исключение "Превышена квота". Это происходит потому, что при использовании утверждения ActAs размер маркера SAML 2 может превысить установленный в Служба WCF (Windows Communication Foundation) размер по умолчанию, равный 8 КБ. Дополнительные сведения см. в статье http://go.microsoft.com/fwlink/?LinkId=150815 (на английском языке)

Для приложения проверяющей стороны, в котором используется ASP.NET, необходимо задать размер маркера по умолчанию в службе STS для SAML2 либо изменить политику службы STS таким образом, чтобы при запросе правильно задавалось значение параметра RST TokenType для SAML2. В приведенном ниже примере кода показано, как это сделать.

	Копировать код
// // При использовании стандартной привязки WS2007FederationHttpBinding // WS2007FederationHttpBinding binding = new WS2007FederationHttpBinding(); binding.Security.Message.IssuedTokenType = Saml2SecurityTokenHandler.TokenProfile11TokenType;

Для приложения проверяющей стороны, в котором используется ASP.NET, необходимо задать тип маркера по умолчанию в службе STS для SAML2. В приложении проверяющей стороны никакие параметры изменять не нужно; оно будет принимать любые маркеры, которые сможет обработать. В приведенном ниже примере кода показано, как это сделать.

	Копировать код
// В конструктор SecurityTokenServiceConfiguration необходимо добавить следующую строку: this.DefaultTokenType = Saml2SecurityTokenHandler.TokenProfile11TokenType;

Обратите внимание, что в качестве имени поставщика службы STS всегда необходимо использовать действительный абсолютный (а не относительный) универсальный код ресурса (URI):

	Копировать код
SecurityTokenServiceConfiguration stsConfig = new SecurityTokenServiceConfiguration("http://localhost:8081/STS"); SecurityTokenService sts = new SecurityTokenService(stsConfig);

Если служба STS выпускает управляемую карточку, и при этом в качестве имени поставщика указан недопустимый URL-адрес, приложению CardSpace импортировать карточку не удастся.

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

1. Установите приложение пассивной федеративной проверяющей стороны ASP.NET с виртуальным каталогом, в имени которого встречаются заглавные буквы, например "MyRP".
   
   
2. Попробуйте получить доступ к проверяющей стороне по URL-адресу, в котором имя виртуального каталога записано строчными буквами (например "myrp"). Например, можно запрограммировать или настроить поставщик службы STS таким образом, чтобы он отправил маркер проверяющей стороне по этому URL-адресу.
   
   
3. При входе клиента в систему возникнет ошибка.
   
   

Это происходит потому, что куки-файл, записанный на стороне клиента, никогда не возвращается веб-приложению браузером клиента, поскольку регистр атрибута PATH куки-файла отличается от регистра запрошенного URL-адреса. В данном примере атрибут PATH ссылается на виртуальный каталог "MyRP", а запрошенный URL-адрес — на виртуальный каталог "myrp". Атрибут PATH извлекается непосредственно из имени виртуального каталога через свойство AppDomainAppVirtualPath. Поскольку при сопоставлении путей куки-файлов в браузере клиента учитывается регистр, федеративный куки-файл никогда не отправляется обратно при последующем перенаправлении.

Чтобы устранить эту проблему, при доступе к проверяющей стороне убедитесь, что в URL-адресе, который ссылается на контент веб-приложения, используется правильный регистр.

Чтобы воспроизвести ошибку при проверке SSL-сертификата, когда WinHTTP не предоставляется конфигурация прокси-сервера, выполните указанные ниже действия.

1. Установите приложение, которое подключается к веб-службе по протоколу SSL. Запустите приложение с учетной записью Network Service или Local System. Укажите в файле app.config приложения, что подключение осуществляется через прокси-сервер.
   
   
2. Приложение выдаст следующее исключение:
   
   

   Копировать код

   WebException: System.Net.WebException: Ошибка подключения к веб-службе: Базовое соединение закрыто: Не удалось установить доверительные отношения для защищенного канала SSL/TLS. ---> System.Net.WebException: Базовое соединение закрыто: Не удалось установить доверительные отношения для защищенного канала SSL/TLS. ---> System.Security.Authentication.AuthenticationException: Удаленный сертификат недействителен согласно результатам проверки подлинности.

Это происходит потому, что приложение предоставляет платформе .NET сведения о конфигурации прокси-сервера в файле app.config, а WinHTTP этих сведений не получает. Это приводит к сбою запросов AIA и промежуточных центров сертификации в процессе проверки допустимости цепочки сертификатов.

Чтобы устранить эту проблему, настройте прокси-сервер WinHTTP в соответствии с конфигурации в файле app.config приложения с помощью программы proxycfg.exe или функции WinHttpSetDefaultProxyConfiguration.

По умолчанию служба STS, созданная с помощью WIF, поддерживает только команду "issue". Такая служба не предоставляет команды "renew", "cancel" и "validate" в виде операций WSDL. Чтобы настроить это поведение, переопределите метод IsOperationSupported.

Если параметру AutoSignIn элемента управления FederatedPassiveSignIn присвоено значение true, убедитесь, что параметру DestinationPageUrl присвоен URL-адрес, отличный от URL-адреса страницы входа. В противном случае при успешной проверке подлинности пользователя в службе STS браузер попадет в бесконечный цикл перенаправления. Это происходит потому, что при перенаправлении пользователя на ту же страницу, с которой он был изначально отправлен службе STS, элемент управления определяет, что текущий запрос не является обратной передачей и не содержит маркер. В результате элемент управления снова отправляет пользователя службе STS.

Когда приложение получает запрос на обслуживание, идентифицировать вызывающую сторону можно двумя способами. Первый способ заключается в использовании классов IPrincipal и IIdentity. Такой подход поддерживается как ASP.NET, так и WCF, а WIF полностью интегрируется с этой моделью в обеих платформах, что позволяет использовать существующий код для новой модели удостоверений на основе утверждений и новых режимов проверки подлинности. WIF может предоставлять значения для конкретного типа утверждения в виде ролей удостоверений .NET Framework, что позволяет использовать для авторизации в коде приложения функцию IsInRole. Администратор (или программа) может выбрать универсальный код ресурса (URI) типа утверждения, а модель удостоверений .NET предоставит в виде ролей все значения, связанные с данным типом утверждения, которые отображаются в участнике вызывающей стороны.

Второй подход заключается в использовании класса IClaimsPrincipal, предоставляемого WIF. В отличие от модели удостоверений .NET этот класс непосредственно предоставляет утверждения, полученные от WIF. Это позволяет получить о вызывающей стороне все доступные сведения. При включении WIF необходимо использовать класс IClaimsPrincipal. Необходимо отметить, что при включении WIF в WCF WCF ServiceSecurityContext не позволяет получить удостоверение и утверждения вызывающей стороны; для доступа к сведениям о вызывающей стороне в коде приложения необходимо использовать класс IClaimsPrincipal. Экземпляр класса IClaimsPrincipal можно получить с помощью свойства Thread.CurrentPrincipal. Этот способ подходит для всех типов проверки подлинности при условии, что в приложении WCF включена поддержка WIF.

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

Если пользователь выбирает для приложения проверяющей стороны куки-файлы, срок действия соответствующего объекта SessionSecurityToken устанавливается равным значению свойства DefaultTokenLifetime класса SessionSecurityTokenHandler. Чтобы изменить срок действия маркера, воспользуйтесь подключаемым модулем в настраиваемом классе SessionSecurityTokenHandler. WIF не поддерживает установку срока действия SessionSecurityToken в файлах web.config и app.config.

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

1. ServiceHost.Credentials.IssuedTokenAuthentication
   
   
2. ServiceHost.Credentials.ClientCertificate.Authentication
   
   
3. ServiceHost.Credentials.UserNameAuthentication
   
   

Если в веб-службах WCF, для которых включена проверка подлинности WIF, не задано значение IssuedTokenAuthentication.KnownCertificates, платформа устанавливает значение по умолчанию SimpleIssuerTokenResolver, при котором разрешаются все SKI необработанных данных, которые поступают "на лету", и отклоняются все остальные типы SKI, например IssuerSerial. Если свойство IssuedTokenAuthentication.KnownCertificates задано, платформа по умолчанию создает распознаватель маркеров на основе значения KnownCertificates. При этом такой распознаватель будет отклонять SKI необработанных данных, не указанные в значении KnownCertificates. Такое поведение актуально на момент выпуска данной бета-версии.

Сообщение с запросом SignIn, отправляемое службе STS, должно содержать либо параметр wtrealm, либо параметр wreply. Параметр wtrealm используется для принятия решений, связанных с политикой. Параметр wreply не следует использовать в качестве URL-адреса перенаправления, не убедившись предварительно в том, что соответствующее значение разрешено политикой.

В элементе <tokenhandlerconfiguration> параметры конфигурации, заданные на уровне <certificateValidation>, пропускаются, а параметры конфигурации, заданные на уровне <certificateValidator>, утверждаются. Это проиллюстрировано в приведенном ниже примере конфигурации.

	Копировать код
<tokenHandlerConfiguration> <!— Следующие параметры пропускаются --> <certificateValidation mode="ignored" revocationMode="ignored" trustedStoreLocation="ignored"> <! – Следующие параметры утверждаются --> <certificateValidator type="honored" /> </certificateValidation> </tokenHandlerConfiguration>

Если параметры конфигурации заданы как на уровне <serviceConfiguration>, так и на уровне <securityTokenHandlers>, параметры, заданные на уровне <securityTokenHandlers>, утверждаются, а параметры, заданные на уровне <serviceConfiguration>, пропускаются. Это проиллюстрировано в приведенном ниже примере конфигурации.

Копировать код

<serviceConfiguration> <issuerNameRegistry type="ignored" /> <serviceTokenResolver type="ignored" /> <audienceUris> ignored </audienceUris> <certificateValidation> ignored </certificateValidation> <issuerTokenResolver type="ignored" /> <securityTokenHandlers> <securityTokenHandlerConfiguration> <issuerNameRegistry type="honored" /> <serviceTokenResolver type="honored" /> <audienceUris> honored </audienceUris> <certificateValidation> honored </certificateValidation> <issuerTokenResolver type="honored" /> <securityTokenHandlerConfiguration> </securityTokenHandlers> </serviceConfiguration>

Не следует задавать свойства модулей HTTP (ClaimsAuthorizationModule, ClaimsPrincipalHttpModule, SessionAuthenticationModule и WSFederationAuthenticationModule) в обработчике события Application_Start. Это связано с тем, что обработчик события вызывается только один раз, поэтому при создании нескольких экземпляров модулей HTTP их свойства заданы не будут. Следовательно, свойства модулей HTTP необходимо задавать в конфигурации.