Утверждения - это относящиеся к пользователям и понятные обоим партнерам в службе федерации Active Directory (ADFS) предложения (например, имя, удостоверение, ключ, группа, привилегия или возможность), которые используются для проверки подлинности в приложении.

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

Существует три способа прохождения утверждений через службу федерации:

  • от хранилища учетных записей к службе федерации учетных записей и партнеру по ресурсам;

  • от партнера по учетным записям к службе федерации ресурсов и приложению ресурса;

  • от хранилища учетных записей к службе федерации ресурсов и приложению ресурса.

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

Службой федерации поддерживаются три типа утверждений: идентификационные утверждения, утверждения о группе и настраиваемые утверждения. В приведенной ниже таблице эти типы утверждений описаны более подробно.

Тип утверждения Свойства

Удостоверение

UPN, электронная почта и общее имя упоминаются в AD FS как типы идентификационного утверждения.

  • Имя участника-пользователя (UPN): определяет имя участника-пользователя в стиле Kerberos, например: user@realm. Тип UPN может иметь только одно утверждение. Даже если требуется обратиться к нескольким значениям UPN, тип UPN может иметь только одно из них. Дополнительные UPN-имена могут быть сконфигурированы как типы настраиваемого утверждения.

  • Электронная почта: указывает имя электронной почты с применением стиля RFC (Request for Comments) 2822 в виде «пользователь@домен». Тип электронной почты может иметь только одно утверждение. Даже если требуется обратиться к нескольким значениям электронной почты, тип электронной почты может иметь только одно из них. Дополнительные адреса электронной почты могут быть сконфигурированы как типы настраиваемых утверждений.

  • Общее имя: произвольная строка, которая используется для персонализации. Примеры: «Иван Петров» или «Служащий компании Tailspin Toys». Тип «Общее имя» может иметь только одно утверждение. Важно помнить, что механизма, гарантирующего уникальность утверждения на общее имя, не существует. Поэтому при использовании этого типа утверждения для принятия решения об авторизации следует проявлять осмотрительность.

О группе

Указывает членство в группе или роли. Администраторы определяют индивидуальные утверждения, которые имеют групповой тип «Утверждения о группе». Например, можно определить следующий набор утверждений о группе: [разработчик, испытатель, руководитель программы]. Каждое утверждение о группе - это отдельная единица администрирования для заполнения и сопоставления утверждения. Значение утверждения о группе можно рассматривать как логическое значение, определяющее членство.

Настраиваемое

Утверждение содержит настраиваемую информацию о пользователе, например код сотрудника.

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

  1. На имя участника-пользователя (UPN)

  2. На электронную почту

  3. На общее имя

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

Сопоставление утверждений

В службах федерации Active Directory (AD FS) используется протокол пассивной запрашивающей стороны федерации веб-служб (WS-F PRP - WS-Federation Passive Requestor Protocol), в котором утверждения переносятся в токенах безопасности, выдаваемых службой федерации. Утверждения заполняются первоначально из хранилищ учетных записей, в качестве которых используются хранилища учетных записей доменных служб Active Directory (AD DS) или хранилища учетных записей служб Active Directory облегченного доступа к каталогам (AD LDS).

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

Процесс сопоставления требований

Наборы утверждений организации

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

В случае утверждений организации сопоставления не нуждаются в индивидуальном управлении между любыми двумя организациями, которым требуется взаимодействовать друг с другом. Каждая организация определяет одиночное сопоставление утверждений своей организации с другими утверждениями либо других утверждений с утверждениями своей организации. Это уменьшает сложность администрирования служб AD FS. Например, если в федерации имеется

x партнеров по учетным записям,

y приложений ресурса,

в федерации имеется x + y сопоставлений утверждений.

Это меньше возможного количества x × y сопоставлений утверждений. В качестве конкретного примера рассмотрим, когда в службе федерации имеется:

3 партнера по учетным записям,

7 приложений ресурса.

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

На электронную почту

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

В следующем примере описывается федерация AD FS, существующая между двумя организациями, «Tailspin Toys» и «Adventure Works». В этом примере организация «Tailspin Toys» является партнером по учетным записям, а организация «Adventure Works» - партнером по ресурсам.

  • Организация «Tailspin Toys», действующая как служба федерации учетных записей, сопоставляет утверждения организации на электронную почту с исходящим утверждением на электронную почту для организации «Adventure Works». В качестве части этого сопоставления организация отображает все суффиксы электронной почты на tailspintoys.com. Для заданного утверждения организации на электронную почту (e-mail=jsmith@sales.tailspintoys.com) исходящее утверждение на электронную почту будет следующим (e-mail=jsmith@tailspintoys.com).

  • Организация «Adventure Works», действующая как служба федерации ресурсов, сопоставляет входящие утверждения организации «Tailspin Toys» на электронную почту с утверждением организации на электронную почту и как часть этого сопоставления, выполняет фильтрацию списка суффиксов относительно строки tailspintoys.com. Поэтому входящее утверждение организации «Tailspin Toys» на электронную почту (e-mail=jsmith@tailspintoys.com) принимается, а входящее утверждение организации «Tailspin Toys» на электронную почту (e-mail=jsmith@adventure-works.com) отбрасывается.

На имя участника-пользователя

Утверждения на имя участника-пользователя (UPN) всегда сопоставляются с утверждениями на имя участника-пользователя (UPN). Они подвергаются сопоставлению и фильтрации суффиксов так же, как и утверждения на электронную почту. Однако, так как доменные службы Active Directory (AD DS) допускают существование UPN без символа @, служба федерации учетных записей присоединяет символ @, сопровождаемый суффиксом, если определено сопоставление суффиксов UPN. В противном случае, если какой-либо суффикс пропускается, служба федерации передает UPN как есть, без символа @. Если на стороне ресурсов разрешены любые суффиксы UPN, то UPN без символа @ принимается. В противном случае, если разрешен конкретный суффикс UPN, то UPN без символа @ отклоняется.

На общее имя

Утверждения на общее имя всегда сопоставляются с утверждениями на общее имя. Для них нет дополнительных правил.

Настраиваемые

Настраиваемые утверждения всегда сопоставляются с настраиваемыми утверждениями. Например, если задан набор входящих утверждений, состоящих из (UPN, Custom=[EmployeeNumber, TaxPayerID]), и набор утверждений организации, состоящих из (UPN, Custom=[Employee, SSN]), то можно создать сопоставления EmployeeNumber с Employee и TaxPayerID с SSN.

О группе

Утверждения о группах всегда сопоставляются с утверждениями о группах. Например, если задан набор входящих утверждений, состоящих из (UPN, Group=[One, Two, Three]), и набор утверждений организации, состоящих из (UPN, Group=[X,Y,Z]), то можно создать сопоставления One с Y, Two с X и Three с Z.

Сопоставление «группа-с-UPN»

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

Например, список сопоставлений утверждений о группах с утверждениями на UPN мог бы быть следующим:

  1. Dev сопоставляется с developers@internal.tailspintoys.com;

  2. Test сопоставляется с testers@internal.tailspintoys.com;

  3. PM сопоставляется с progmgrs@internal.tailspintoys.com.

Если имеется набор входящих утверждений, состоящих из (Common name=John Smith, Group=[Dev]), то набор утверждений организации содержит (Common name=John Smith, UPN=developers@internal.tailspintoys.com). Помните, что список является упорядоченным. Поэтому для набора утверждений, состоящих из (Common name=John Smith, Group=[Dev,PM]), получается следующий результат: (Common name=John Smith, UPN=developers@internal.tailspintoys.com). Кроме того, если входящее утверждение имеет UPN, то UPN перезаписывается. Это специальное правило сопоставления поддерживает, в частности, групповые учетные записи ресурсов, которые получают доступ к прежним версиям ресурсов. Порядок сопоставлений утверждений о группах с утверждениями на UPN определяется в политике доверия службы федерации.

Аудит утверждений

Некоторые утверждения о группе и настраиваемые утверждения могут создаваться с возможностью аудита. Когда аудит включен, имя утверждения может записываться в журнале системных событий безопасности, но значение утверждения при этом опускается. Пример утверждения с возможностью аудита - код социального страхования. Имя утверждения «Код социального страхования» записывается, но фактическое значение кода, которое хранится в данном утверждении, не показывается. При создании и сопоставлении утверждения его значение аудитом не затрагивается.

Примечание

Утверждения идентификационных типов всегда подвергаются аудиту.

См. также

Содержание