Я хотел написать это, чтобы помочь другим, которые могли застрять в той же колее, в которой пытался найти основное направление / понимание. По сути, я придерживался рабочего процесса, описанного @Chris Pradget. Однако мое первоначальное восприятие проблемы было неправильным, и я поясню, в чем заключалась моя ошибка, и дам небольшой контекст.
Моя первоначальная цель состояла в том, чтобы подавать заявки на роли и / или группы пользователей, когда пользователь входит в мое приложение Azure / Angular. В Azure нет простого способа сделать это, когда вы входите в систему с помощью Azure B2C для получения политик. (В некотором смысле кажется, что Firebase упрощает эту задачу).
После кучи исследований и не совсем понимания общей картины я увидел то, что казалось противоречивой информацией, которую потребовалось некоторое время, чтобы разобраться. В конце концов я нашел информацию, которую искал, которая заключалась в том, что у меня не может быть только один логин.
(Просто напомню, что я называю свое классическое зарегистрированное приложение в Azure AD "регистрацией приложения", чтобы провести различие от реализации кода и конфигурации, установленной на портале Azure)
Потребовалось много экспериментов, но я придумал кое-что, что, кажется, работает. По сути, я получаю 3 токена: 2 в Angular с использованием MSAL.js и один в .NET с использованием ADAL для Microsoft Graph. Один в Angular предназначен для первоначального входа в систему (вызов loginRedirect клиента MSAL) для получения id_token, а другой, который я получил, используя этот токен вместе с функцией aquireTokenSlient, для получения access_token. Я отправил это на свой сервер .NET Core, где использовал идентификатор пользователя из входящего токена в качестве идентификатора ресурса в запросить Microsoft Graph, чтобы получить заявку на мои группы, а затем я создал мой собственный токен JWT с заявками, которые нужно отправить обратно в Angular для моих охранников маршрута.
В моем исследовании следует отметить следующие моменты:
Azure AD Graph против Microsoft Graph для получения групп пользователей: существует противоречивая информация о том, что использовать, некоторые говорят, что Microsoft Graph, потому что Azure Graph устарел, но другие говорят, что Azure Graph, потому что MS Graph еще не охватывает все основы. После экспериментов я обнаружил, что могу извлекать группы пользователей из MS Graph. Учитывая это и тот факт, что MS Graph новее, я выбрал MS Graph. Для экспериментов с графиками я использовал как Azure Graph Explorer, так и MS Graph Explorer.
Мне потребовалось некоторое время, чтобы успешно запросить Microsoft Graph, но когда я это сделал, я использовал MS Graph Explorer, как указано выше. Основная проблема, с которой я впервые столкнулся, заключалась в том, что я запрашивал свое приложение с помощью своей учетной записи. Только некоторые запросы работали, и даже те возвращали очень ограниченную информацию. Только когда я перечитал в этой статье об API-интерфейсе Azure AD Graph, заметил ли я, что для запроса Graphs вам нужно использовать идентификатор пользователя, который является локальным для домена вашего клиента и является администратором. Когда я создал и использовал администратора своего клиента (из этого домена), все запросы работали. Итак, что касается моих вопросов выше:
1) Как исправить эту ["code": "Authentication_MissingOrMalformed"] ошибку? Используйте учетную запись локального администратора
2) Обязательно ли иметь учетную запись локального администратора? Да
3) Есть ли какие-то особые области, которые мне нужно установить в моем приложении B2C, чтобы предоставлять авторизацию для моих запросов? Если да, то какие именно? Чтобы запросить MS Graph с помощью ADAL, используйте Directory.Read Access
4) Это приложение должно быть мультитенантным? Нет
Кроме того, в своем исследовании я обнаружил, что вместо использования групп B2C вы можете использовать роли Azure AD. В частности, роли приложения можно добавить в манифест классического приложения Azure AD на портале Azure. Это был другой маршрут, который казался мне многообещающим. Я нашел эту статью, в которой описывается, как чтобы отредактировать манифест, чтобы добавить роли приложения. Сначала вы добавляете роли в манифест, затем назначаете пользователям роли на портале Azure, а затем запрашиваете информацию о пользователе (из Angular) с помощью библиотеки ADAL.js. Когда вы входите в систему с помощью библиотеки, роли приложения снижаются на полученном токене. Это, конечно, не использует политики B2C. Это также может быть само собой разумеющимся, но при входе в систему ни B2C id_token, ни access_token не могут быть использованы для получения учетных данных / токена Classic Azure AD. Я пытался придумать другие способы добиться того, чего хотел. Учитывая, что две регистрации находятся в одном клиенте, я подумал, что могу использовать единый вход для входа в один и оставаться в системе для другого. Я не ушел очень далеко. Еще один метод, который я рассмотрел, заключался в использовании настраиваемых политик для извлечения данных из моего классического приложения Azure AD, но и в этом далеко не ушел.
Также, когда @Chris Padgett упомянул о создании «пользовательского API», я неправильно его истолковал. Под "пользовательским API" я думал, что он имел в виду мою классическую регистрацию приложения Azure Ad, которая была настроена на портале Azure, хранит мою пользовательскую информацию и действует как API для получения моего токена. Я думал, что сначала мне нужно получить токен доступа от B2C в Angular, а затем использовать этот токен (все еще в Angular) для доступа к моей классической регистрации в Azure AD. Оттуда я мог бы вытащить информацию о моих пользователях, включая роли приложений (которые доступны при редактировании манифеста). Это не сработало бы, потому что, как я сказал выше, я хотел сделать это с одним входом, а вы не можете использовать токен B2C в классическом приложении Azure AD. Даже если бы это сработало, потребовалось бы установить роли для пользователей в моей классической регистрации приложения Azure AD за пределами моего приложения B2C, чего я не хотел делать. Регистрация одного приложения для политик и другого для управления ролями пользователей не очень элегантна. Также для его работы потребуется 2 входа в систему: один для B2C и один для Classic Azure AD. При таком подходе кажется, что эти 2 приложения - отдельные, и я не хочу разделять проблемы между двумя платформами. Итак, в конце концов, сценарий входа в систему с помощью B2C в Angular с последующим обращением к серверу для извлечения групп пользователей с помощью MS Graph является лучшим. Бэкэнд-приложение должно войти в систему только один раз, независимо от пользователей, обращающихся к нему, что означает, что пользователям не нужно входить дважды. Также он объединяет мою информацию с моей регистрацией в приложении B2C.
Я думаю, что в будущем Azure может в конечном итоге предоставить группы и / или роли в их id_tokens, но я подумал, что эта информация может быть полезна людям в то же время. Кроме того, вот ссылки на другие вопросы, которые я задал, которые помогли мне в моем исследовании:
Узнал, что мне нужно использовать MSAL.js вместо ADAL.js, чтобы использовать B2C Политики.
Я задал аналогичный вопрос о запросе MS Graph и получении ограниченного ответа
person
afriedman111
schedule
22.02.2018
