Azure AD B2C - несколько настраиваемых политик Identity Experience Framework могут использоваться взаимозаменяемо

Для нескольких приложений. мы используем AAD B2C для нашей системы аутентификации. Мы выбрали индивидуальную политику. Одна из причин этого заключается в том, что мы хотим разрешить разным группам пользователей доступ к разным приложениям следующим образом:

  • суперпользователи могут получить доступ ко всем приложениям, включая нашу CMS
  • администраторы продукта могут получить доступ к CMS, ориентированной на клиента, и к конечному продукту
  • пользователи продукта могут получить доступ к конечному продукту

Для этого у нас есть политики:

  • B2C_1A_xxx_cms
  • B2C_1a_xxx_product
  • B2C_1A_xxx_customercms

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

https://{tenant}.b2clogin.com/{tenant}/b2c_1a_xxx_cms/oauth2/v2.0/authorize?response_type=id_token&scope={scope}%20openid%20profile&client_id={client_id}&redirect_uri={redirect_uri}&nonce={nonce}&client_info=1&x-client-SKU=MSAL.JS&x-client-Ver=1.4.4&client-request-id={client-request-id}&response_mode=fragment

В указанном выше URL-адресе пользователи могут получить доступ к CMS, заменив b2c_1a_xxx_cms на b2c_1a_xxx_product, тем самым минуя групповую проверку для конкретного приложения.

Исходная реализация наших политик основана на этом руководстве: https://docs.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-get-started

Как мы можем настроить эти политики таким образом, чтобы изменение URL-адреса и попытка входа в систему были невозможны?


person Maarten B    schedule 28.01.2021    source источник
comment
Я не понимаю, как ваш API обходит групповую проверку. Как правило, API должен проверять членство в группах пользователя, выполнившего вход, независимо от того, какую политику и приложение вы используете. Не могли бы вы объяснить это поподробнее?   -  person Allen Wu    schedule 01.02.2021
comment
Конечно! Проверка API срабатывает и работает отлично. Проблема в том, что во время входа в систему пользователь может выбрать другую политику, отредактировав URL-адрес входа. Разница в политике приводит к тому, что выполняется другой метод API, который проверяется для разных групп.   -  person Maarten B    schedule 01.02.2021
comment
Так, например: пользователь A из группы A может получить доступ к API A через политику A. Пользователь B из группы B может получить доступ к API B через политику B. Теперь пользователь B изменяет URL-адрес, чтобы войти в систему с политикой A и вызвать API A. Я понимаю верный? Но в этом случае я не думаю, что пользователь B может успешно получить доступ к API A, потому что он не может пройти аутентификацию членства в группе в политике A.   -  person Allen Wu    schedule 01.02.2021
comment
Поправьте меня, если есть недоразумения.   -  person Allen Wu    schedule 01.02.2021
comment
Проверка группы на стороне API выполняется независимо, и действительно невозможно получить доступ к API для пользователя B. Проблема здесь заключается в генерации токена JWT, который обеспечивает доступ к интерфейсу. Пользовательские перехватчики API используются во время входа в систему   -  person Maarten B    schedule 01.02.2021
comment
Привет, ты проверил мой ответ?   -  person Allen Wu    schedule 04.02.2021


Ответы (2)


Исходя из ваших требований, я думаю, вам нужен назначение приложения пользователям.

Но он доступен только в Azure AD, а не в Azure B2C.

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

person Allen Wu    schedule 02.02.2021

«Мы выполняем вызов API для внутренней аутентификации API, который проверяет членство пользователя в группах через MS Graph API. ”

Когда пользователь A вызывает политику B, этот API должен вернуть заявку в путешествие, которая не позволяет ему создать JWT. Этого можно добиться, создав «страницу блокировки» с использованием самопровозглашенного технического профиля. Вызовите это из шага оркестрации, используя это утверждение из API, чтобы вызвать его с предварительным условием.

person Jas Suri - MSFT    schedule 06.02.2021