Изменить RelayState в AD FS

Рассмотрим следующую ситуацию: в настоящее время мы находимся на этапе миграции, когда большинство наших пользователей по-прежнему должны быть перенаправлены в существующее приложение A. Другие пользователи, которые соответствуют определенным критериям (назовем их бета-тестерами), вместо этого должны быть перенаправлены в новое приложение. приложение Б.

Пользователи достигают нашей AD FS с запросом POST, который содержит SAMLResponse и RelayState. Параметр RelayState сообщает нашей AD FS желаемое целевое приложение. До сих пор он всегда содержит «сайт A», так как пользователи еще не знают о сайте B ;-)

Мне интересно, есть ли способ динамически изменить процесс, в котором наша ADFS определяет целевое приложение на основе значения параметра RelayState? Итак, я ищу способ каким-то образом изменить RelayState на основе определенного утверждения, предоставленного пользователем. Например. если пользователь имеет запись «бета-тестер» в своем заявлении на роль, то наша ADFS должна перенаправить его на сайт B вместо сайта A.

Есть ли способ подключиться к конвейеру обработки AD FS? Пока я нашел только эту статью, описывающую, как " inject" пользовательский метод аутентификации. Но это явно не то, что я ищу.

Так может ли кто-нибудь сказать мне, есть ли какие-либо другие точки расширения, которые я мог бы использовать для достижения того, что я описал выше?


person khlr    schedule 01.11.2017    source источник


Ответы (2)


Извините, нет, нет возможности динамически изменить RelayState.

ADFS заблокирована (поскольку это система безопасности) и не имеет точек расширения.

Могли бы вы иметь два RP во время перехода?

person rbrayb    schedule 01.11.2017
comment
Благодарю за ваш ответ! Наличие двух RP кажется очевидным решением. К сожалению, для этого требуется, чтобы IdP предоставил две ссылки на наши приложения. И это то, чего я хотел бы избежать. - person khlr; 01.11.2017
comment
В любом случае у вас должно быть два RP, чтобы ADFS различал их. Просто дайте группе Б новый URL-адрес, и они смогут перейти к нему вручную. - person rbrayb; 02.11.2017
comment
Извините, я ошибся. Конечно, будут настроены две RP. Один для сайта A и один для сайта B. Но когда приходит ответ SAMLResponse, ADFS должна самостоятельно выбирать, перенаправлять ли пользователя на A или B. В идеале пользователь не должен видеть раскрывающийся список ADFS для ручного выбора RP. - person khlr; 02.11.2017

Один из подходов заключается в настройке прокси-сайта, на котором вы можете применять пользовательскую логику по мере необходимости для подобных сценариев. Мой опыт показывает, что во многих случаях удобно иметь точку входа в процесс федерации, т. е. точку псевдорасширения, где вы можете применять пользовательскую логику. Таким образом, каждый из IdP может перейти на https://proxy.mysite.com, и тогда этот сайт сделает определения на основе утверждений и, возможно, строки запроса, размещенных переменных или атрибутов заголовка, относительно того, куда направить (перенаправить) пользователя на следующий, https://a.mysite.com или https://b.mysite.com.

DNS также можно свернуть, чтобы выполнять такие действия, как прямой https://a.mysite.com на прокси-сервер. сайт и прокси-сайт могут затем посмотреть на имя хоста запроса и узнать, что пользователь намеревался перейти на a.mysite.com, но вы можете определить, является ли бета-тестер и направить на b.mysite.com или фактический сайт A .

person Gilligan    schedule 07.11.2017
comment
Да, это тоже был бы способ, который пришел нам в голову. Основным недостатком является то, что этот прокси должен быть настроен в первую очередь. Это означает, что его нужно разработать и разместить как еще одно высокодоступное приложение. Так что это как-то похоже на путь, но это кажется утомительным путем. - person khlr; 08.11.2017
comment
Это, безусловно, добавляет еще одну возможную точку отказа и сайт для управления. Если вы придумаете другой метод, мне было бы интересно узнать, что вы нашли. - person Gilligan; 13.11.2017