Как интегрировать одностраничное веб-приложение AAD с несколькими арендаторами со встроенным Power BI с использованием идентификации на основе токенов RLS
Мы пытаемся поддержать сценарий, который представляет собой комбинацию следующего:
- Войдите в систему SPA с помощью AAD, используя шаблон мультитенантного приложения. Данные всех арендаторов в ОДНОМ экземпляре.
- Встроенный отчет Power BI на основе прямого запроса к экземпляру SQL Azure с идентификатором RLS на основе токенов, как описано здесь.
Мы хотим, чтобы пользователь вошел в систему только один раз в нашем SPA, после чего он сможет видеть встроенный отчет Power BI только с теми данными, которые он должен видеть (RLS).
Мы склонны заключать, что эти две концепции несовместимы, но мы надеемся, что ошибаемся и будем исправлены здесь.
Наши соображения вкратце:
- Для поддержки "мультитенантного SPA со всеми данными клиента в одном экземпляре БД" мы должны использовать / common полномочия. В результате вошедший в систему пользователь является идентификатором AAD арендатора.
- Для поддержки "Power BI, встроенного с использованием идентификатора RLS на основе токенов" и, следовательно, для применения RLS на уровне БД, нам нужно, чтобы соответствующий пользователь был пользователем БД. Но каждый такой пользователь на основе AAD должен быть (гостевым) пользователем в арендаторе БД (= арендаторе независимого поставщика программного обеспечения). Этот пользователь является идентификатором внутри нашего (независимого поставщика программного обеспечения) клиента AAD, в отличие от собственного клиента AAD.
Так что, если нет способа сопоставить пользователя из 1) с пользователем из 2), мы не видим способа заставить это работать вместе. Также я не понимаю, как мы могли бы применить для этого от имени аутентификации.
Мы фактически построили сценарий и обнаружили, что:
- при использовании / common в качестве авторизации SPA мы получили следующее сообщение об ошибке в отчете Power BI:
"Не удалось загрузить данные для этого визуального входа в систему для пользователя". Исключение было вызвано интерфейсом IDbConnection ".
- только когда мы установим полномочия входа в SPA для клиента независимого поставщика программного обеспечения, мы получим правильно встроенный отчет Power BI с соответствующим примененным RLS. Однако это не вариант, поскольку в этом случае мы больше не можем поддерживать сценарий "Многопользовательский SPA со всеми данными клиента в одном экземпляре БД".
Обращение в службу поддержки MS еще не помогло, поскольку их ответ был в основном таким:
Поведение соответствует ожиданиям, см. Пояснения и предложения ниже
Описанный сценарий соответствует ожиданиям:
Сценарий представляет собой доступ к SQL Azure с единым входом (т. Е. Использует удостоверение конечного пользователя для доступа к базе данных SQL Azure).
Конечный пользователь является гостем в клиенте ISV.
Когда выполняется вход на https://login.microsoftonline.com/026eae68-____-____-____-cf31af66b9e4, токен пользователя будет токеном B2B для клиентов ISV, который является действительным токеном для базы данных SQL, если доступ B2B настроен правильно, как описано в сводке.
В противном случае, когда вход выполняется на https://login.microsoftonline.com/common/, токен пользователя будет обычным токеном AAD, дающим доступ к домашнему клиенту пользователя, и недействительным для доступа к базе данных SQL.
Предложения:
Если всем конечным пользователям предоставляется гостевой доступ к клиенту ISV и базе данных ISV, это не должным образом многопользовательское решение, а, скорее, решение B2B с одним клиентом, и логин должен оставаться https://login.microsoftonline.com/026eae68-____-____-____-cf31af66b9e4
Если это не так и пользователю требуется мультитенантное приложение, встраиваемый токен должен быть сгенерирован с действительным токеном доступа SQL в качестве идентификационного большого двоичного объекта (т. Е. Не токеном AAD пользователя, поскольку он является токеном только для клиента пользователя). Рассмотрите возможность использования аутентификации от имени, чтобы получить действительный токен доступа SQL:https://docs.microsoft.com/en-us/graph/auth-v2-user
Хотя мы видим, почему они говорят: "Все работает, как ожидалось" - это не решает проблему, описанную выше. Также мы не видим, как здесь может помочь подход аутентификации от имени.