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 Command или ADFS GUI, где его можно найти)
- Как транзитивное доверие влияет на свойства заявок в Issuer и OriginalIssuer?
- Если транзитивное доверие используется вместе с преобразованиями утверждений, и поставщик (B) преобразует входящие утверждения из (C) таким образом, что они преобразуются в (новые) утверждения одного типа и значения, как это повлияет на свойства Issuer и OriginalIssuer?
ВАЖНО: поддерживается ли это или нет, мне нужны официальные источники по этому вопросу. Однако, если никто не сможет предоставить их, и кто-то сможет ответить на вопросы с его опытом, я буду готов дать ему награду даже без официальных источников.
1 ответ
Ну, так как никто не ответил, я взял время, настроил тестовую лабораторию и понюхал трафик HTTPS. Вот мои результаты исследований на случай, если кто-нибудь еще столкнется с этой вещью:
- У меня до сих пор нет официального источника для этих вопросов
- Прежде всего: да, транзитивное доверие возможно, и нет никакого способа заблокировать его, кроме юридических вопросов. Надежный SLA в любом случае является основой для любого сценария федерации.
- Не существует специальных "настроек" для его отключения или включения, но с помощью механизма правил утверждений доверенный партнер может настроить ЛЮБОЙ вид исходящих утверждений, ЕСЛИ будет обнаружен ЛЮБОЙ вид входящих претензий, поэтому нет способа "защитить" незаконный доступ.
- В моих тестах ни один из шаблонов правил, поставляемых с ADFS, не изменял свойство OriginalIssuer заявок. Кто-то может подумать: хорошо, поэтому я могу использовать это свойство, чтобы проверить исходный источник любого утверждения и создать фильтр, позволяющий только утверждениям поступать непосредственно (а не проходить через них, что по умолчанию влияет только на эмитента, но не на свойство OriginalIssuer) a доверенный партнер Но это неправильно, почему? Посмотрите на следующую строку.
- Как я уже сказал, шаблоны по умолчанию не затрагивают свойство OriginalIssuer. Но вы можете создавать собственные правила, используя механизм правил. Используя это, вы можете изменить практически все типы претензий, значения и их свойства. И да: также Оригинал. Таким образом, для поставщика федерации все выглядит так, как будто заявки поступают напрямую от доверенного партнера, где на самом деле они там только преобразуются.
Итак, я бы посоветовал хотя бы минимизировать "переходные" сценарии, если они нежелательны, - это проверить OriginalIssuer. Он не защищает от транзитивных входов в систему, но администратор должен был бы явно настроить его - что значительно упростило бы юридические отношения в случае нарушения SLA. Кроме того, я не думаю о возможности изменить OriginalIssuer как "ошибку", фактически: даже без этой функции каждое стороннее программное обеспечение всегда могло бы выступать в качестве прокси-сервера между бэкэнд-системами и доверенным провайдером идентификации., Например, IdP может создавать теневые учетные записи для партнера (C), поэтому всегда найдется обходной путь, поскольку при использовании федерации вы отказываетесь от контроля над тем, кто может делегировать права доступа к конкретным ресурсам.
В любом случае - если вам было так же интересно, как я справляюсь с тем, как ADFS 2.0 обрабатывает транзитивные доверительные отношения, теперь вы знаете, что вам не нужно создавать тестовую метку и прослушивать HTTPS-трафик.