ADFS v.2.0 транзитивное доверие в сценарии федерации

В настоящее время я работаю с ADFS, чтобы установить федеративное доверие между двумя разделенными доменами.

Мой вопрос простой: поддерживает ли ADFS v. 2.0 транзитивное доверие между поставщиками федеративных удостоверений? И если да, см. Вопросы ниже. (Я говорю не о доверии лесов AD, а о полностью разделенных доменах с использованием чистого ADFS 2.0 в сценарии федерации)

Я знаю, что ADFS v 1.0 не работает, как указано в этот документ на странице 9. Но если посмотреть на правила утверждений, которые поставляются с ADFS 2.0, это кажется возможным, как подтвердил партнер Microsoft. Однако: документация по этой теме - беспорядок! Просто никаких заявлений по этой теме, связанных с ADFS v. 2.0, которые мне удалось найти (ЕСЛИ у вас есть документация по этому поводу, ПОЖАЛУЙСТА, помогите мне, ребята!).

Чтобы быть более ясным, давайте предположим этот сценарий:

Federation provider (A) trust federation provider (B) which trusts identity provider (C).
So, does (A) trust identities comming from (C) across (B)?

Дальнейшие вопросы в случае поддержки переходного доверия:

Можно ли каким-либо образом ограничить транзитивное доверие в ADFS? Если да, то как? (Команда Powershell или запись в меню графического интерфейса пользователя ADFS, где ее найти)
Как транзитивное доверие влияет на свойства требований Issuer и OriginalIssuer?
Если транзитивное доверие используется вместе с преобразованиями утверждений, и поставщик (B) будет преобразовывать входящие утверждения из (C) таким образом, чтобы они преобразовывались в (новые) утверждения того же типа, что и значение, как это повлияет на свойства Issuer и OriginalIssuer?

ВАЖНО: поддерживается он или нет, мне нужны официальные источники по этому поводу. Однако, если никто другой не сможет их предоставить, и кто-то сможет ответить на вопросы со своим опытом, я буду рад дать ему награду даже без официальных источников.

Ну, так как никто не ответил, я нашел время, создал тестовую лабораторию и проанализировал HTTPS-трафик. Вот результаты моих исследований на случай, если кто-нибудь еще когда-нибудь столкнется с этой штукой:

У меня до сих пор нет официального источника по этим вопросам
Во-первых: да, транзитивное доверие возможно и заблокировать его невозможно, кроме юридических вопросов. В любом случае правильное SLA является основой для любого сценария федерации.
Не существует специальной «настройки» для ее отключения или включения, но с помощью механизма правил утверждений доверенный партнер может настроить ЛЮБОЙ вид исходящих утверждений, ЕСЛИ обнаружен ЛЮБОЙ вид входящих утверждений, поэтому нет способа «защитить» незаконный доступ.
В моих тестах ни один из шаблонов правил, поставляемых с ADFS, не изменил свойство OriginalIssuer утверждений. Кто-то может подумать: хорошо, поэтому я могу использовать это свойство для проверки исходного источника любого утверждения и создания фильтра, чтобы разрешить только утверждения, поступающие непосредственно из (а не проходящие через него, что по умолчанию влияет только на эмитента, но не на свойство OriginalIssuer) надежный партнер. Но это неправильно, почему? Посмотрите на следующую строку.
Как я уже сказал, шаблоны по умолчанию не касаются свойства OriginalIssuer. Но вы можете создавать собственные правила, используя механизм правил. Используя его, вы можете изменить практически любой тип утверждения, значение и их свойства. И да: тоже OriginalIssuer. Таким образом, поставщику федерации кажется, что заявки поступают напрямую от доверенного партнера, а на самом деле они только там преобразуются.

Итак, что я бы посоветовал, по крайней мере, минимизировать «переходные» сценарии, если они нежелательны, - это проверить наличие OriginalIssuer. Он не защищает от транзитивных входов в систему, но администратор должен будет явно настроить его, что значительно упростит юридические отношения в случае аннулирования SLA. Кроме того, я не думаю о возможности изменить OriginalIssuer как о «ошибке», на самом деле: даже без этой функции каждое стороннее программное обеспечение всегда могло бы сделать его способным действовать как прокси между серверными системами и доверенным поставщиком удостоверений. . Например, IdP может создавать теневые учетные записи для партнера (C) - поэтому всегда будет обходной путь, поскольку при использовании федерации вы отдаете контроль над тем, кто может делегировать права доступа к определенным ресурсам.

В любом случае - если вам было так же любопытно, как я, как ADFS 2.0 обрабатывает транзитивные доверительные отношения, теперь вы знаете, что нет необходимости создавать тестовую лабораторию и анализировать HTTPS-трафик.