Непредсказуемое поведение мультитенантного приложения Azure AD? - PullRequest
0 голосов
/ 13 ноября 2018

Я пытаюсь создать масштабируемую мультитенантную SAAS b2b в Azure AD с использованием Angular во внешнем интерфейсе и на узле + проектирование базы данных Azure MS SQL Sharded.

Я провел неделю, изучая MSдокументацию и примеры (штопор, приложения для опросов) и начали тестировать мультитенантное поведение в приложении angular7, в котором нет ничего, кроме аутентификации с adal-angular4 , которое я использовал для ~ 5 других проектовкоторые в настоящее время находятся в производстве.

Пока что я не могу на всю жизнь выяснить причину этого непредсказуемого поведения.У меня есть 3 арендатора: A - B - C

A - арендатор разработчика + моя учетная запись администратора, B - арендатор другой компании + моя учетная запись обычного пользователя, а C - арендатор уровня AD Free с моей личной учетной записью.

Я не сделал ничего другого для своего приложения в Azure AD на платформе AD разработчика, кроме как включил этот мультитенантный параметр и изменил значение Oauth2implicitflow на true.

  • Если явойдите с приложением Tenant A в приложение, все хорошо, в консоли я вижу GUID арендатора A под TID.

  • Если я захожу с Tenant B - он запрашивает разрешения в первый рази затем впускает меня (почему ??).

  • Если я захожу с «рабочей» учетной записью Tenant C, она не выдает ошибок, не запрашивает разрешения, возвращается на страницу без фактической регистрациии ничего на консоли.
  • Если я войду с «личной» учетной записью Tenant C, она скажет, что tenant live.com не подготовлен для приложения.

Мои вопросыявляются:

  1. Почемуэто даже позволило Арендатору B войти в приложение?Им определенно не предоставили возможность доступа к нему, и на консоли tid явно относится ко второму арендатору, что означает (я думаю), что учетная запись НЕ является гостем арендатора А, чтобы иметь возможность войти в систему.
  2. Я понятия не имею, почему арендатор C не выдает ошибку на стороне Azure, а вместо этого просто возвращается на страницу без фактического входа в систему.
  3. Есть ли какая-то документация, по которой мне не хватает, на которую арендаторы могут зарегистрироватьсяв приложение?Я просмотрел статью о регистрации и регистрации арендатора , но в действительности она не решает проблему.

Основываясь на прочитанной документации, поведение арендатора Bи C попытка войти в приложение не имеет смысла.

1 Ответ

0 голосов
/ 14 ноября 2018

Почему он даже позволил Арендатору B войти в приложение? Им определенно не предоставили возможность доступа к нему, и на консоли tid явно относится ко второму арендатору, что означает (я думаю), что учетная запись НЕ является гостем арендатора А, чтобы иметь возможность войти в систему.

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

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

...