В: В чем различие между ActAs и OnBehalfOf?

С точки зрения протокола WS-Trust:

• Элемент маркера безопасности запроса ActAs указывает, что запрашивающей стороне необходим маркер, содержащий утверждения о двух различных объектах: о запрашивающей стороне и внешнем объекте, представленном маркером в элементе ActAs.
  
  
• Элемент маркера безопасности запроса OnBehalfOf указывает, что запрашивающей стороне необходим маркер, содержащий утверждения только об одном объекте: о внешнем объекте, представленном маркером в элементе OnBehalfOf.
  
  

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

Функция OnBehalfOf используется в тех сценариях, где необходимо только удостоверение исходного клиента; эта функция фактически эквивалентна олицетворению удостоверения в Windows. При использовании функции OnBehalfOf окончательный получатель выпущенного маркера видит только утверждения об исходном клиенте, а сведения о посредниках не сохраняются. Одним из основных шаблонов использования функции OnBehalfOf является шаблон прокси-сервера, при котором клиент получает доступ к службе STS не напрямую, а через прокси-шлюз. Прокси-шлюз выполняет проверку подлинности вызывающей стороны и вносит сведения о ней в элемент OnBehalfOf сообщения маркера безопасности запроса, который затем отправляется на обработку службе STS. Результирующий маркер содержит только утверждения, связанные с клиентом прокси-сервера, поэтому прокси-сервер абсолютно прозрачен для получателя выпущенного маркера.

Обратите внимание, что WIF не поддерживает <wsse:SecurityTokenReference> и <wsa:EndpointReferences> в качестве дочерних элементов <wst:OnBehalfOf>. В спецификации WS-Trust предусмотрено три способа идентификации исходной запрашивающей стороны (от имени которой действует прокси-сервер). Эти способы перечислены ниже.

1. Ссылка на маркер безопасности. (Ссылка на маркер, полученная из сообщения или извлеченная из потока данных).
   
   
2. Ссылка на конечную точку. Используется в качестве ключа для поиска данных в потоке данных.
   
   
3. Маркер безопасности. Непосредственно идентифицирует запрашивающую сторону.
   
   

WIF поддерживает только маркеры безопасности, как зашифрованные, так и нешифрованные, в качестве непосредственного дочернего элемента <wst:OnBehalfOf>.

В: Почему при использовании Cardspace или WS-Fed появляется сообщение об ошибке "400 ошибочный запрос — слишком длинный запрос"?

О: См. статью Параметры реестра http.sys для служб IIS (на английском языке). Эта статья посвящена параметрам служб IIS. В данном случае интерес представляют два параметра:

• MaxFieldLength: верхний предел для каждого заголовка. Этот предел соответствует приблизительно 32 тысячам знаков для URL-адреса.
  
  
• MaxRequestBytes: верхний предел для суммарного размера строки запроса и заголовков. Значение по умолчанию — 16 КБ. Если это значение меньше значения MaxFieldLength, значение изменяется соответствующим образом MaxFieldLength.
  
  

В: Когда вызывается диспетчер проверки подлинности утверждений?

О: Диспетчер проверки подлинности утверждений обычно вызывается один раз за сеанс, за исключением указанных ниже случаев.

• Для безопасности транспорта маркеры, расположенные на транспортном уровне, будут вызывать диспетчер проверки подлинности утверждений при каждом вызове, даже при использовании сеансов.
  
  
• При наличии на уровне безопасности сообщений нескольких маркеров каждый маркер будет вызывать диспетчер проверки подлинности утверждений по отдельности. Например, два маркера в заголовке безопасности вызовут диспетчер проверки подлинности утверждений дважды за сеанс.
  
  
• Диспетчер проверки подлинности утверждений не вызывается при отсутствии маркеров, а именно во всех режимах проверки подлинности с анонимным входом (AnonymousForxxx). В данном случае рекомендуется использовать в качестве привратника диспетчер авторизации маркеров.
  
  

Примечание.
Не рекомендуется вызывать свойство Thread.CurrentPrincipal в диспетчере проверки подлинности маркеров и в диспетчере авторизации маркеров. Вместо этого рекомендуется использовать параметр incomingPrincipal метода Authenticate:

	Копировать код
class CustomClaimsAuthenticationManager : ClaimsAuthenticationManager { public override IClaimsPrincipal Authenticate(string resourceName, IClaimsPrincipal incomingPrincipal) { return base.Authenticate(resourceName, incomingPrincipal); } }

В: Как WIF обрабатывает дублирующиеся маркеры безопасности запроса и дублирующиеся элементы маркеров безопасности запроса?

О: При наличии дублирующихся маркеров безопасности запроса, выполняется синтаксический разбор только первого маркера; остальные маркеры пропускаются. Если в маркере безопасности запроса содержатся дублирующиеся элементы, используется значение только последнего элемента; все остальные значения пропускаются.

В: Что представляет собой запрещающий идентификатор безопасности (SID)?

О: Дополнительные сведения см. в статье Атрибуты идентификатора безопасности в маркере доступа (на английском языке)

В: Каким образом приложение проверяющей стороны проверяет отношение доверия с поставщиком?

О: В WIF принята концепция IssuerNameRegistry, которая представляет собой точку расширения для проверки отношения доверия с поставщиком. Эту точку расширения можно использовать двумя указанными ниже способами.

1. ConfigurationBasedIssuerNameRegistry, где можно настроить сертификат подписи поставщика в файле конфигурации приложения проверяющей стороны.
   
   
2. Настраиваемый класс IssuerNameRegistry, производный от класса IssuerNameRegistry, представленного в WIF. Пример реализации класса IssuerNameRegistry см. в файле Samples\End-to-end\Authentication Assurance\AuthAssuranceRP\App_Code\TrustedIssuerNameRegistry.cs.
   
   

В: В каком разделе реестра устанавливается WIF?

О: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsIdentityFoundation\setup\v3.5\.

В: Можно ли использовать экземпляр службы STS для вызова Issue в нескольких запросах маркеров?

О: В WIF используется модель создания экземпляров службы STS, привязанная к вызовам. Это означает, что каждый экземпляр STS предназначен для однократного использования: создается новый экземпляр службы STS, вызываются необходимые методы (например Issue), а затем этот экземпляр STS очищается. При попытке использовать один и тот же экземпляр STS для вызова метода Issue в нескольких запросах маркеров вместо того чтобы создавать новый экземпляр STS для каждого запроса, результаты будут непредсказуемыми.