Какую политику (поток пользователей) должен ожидать мой API-сервер, защищенный Azure AD B2C, в качестве органа? - PullRequest
0 голосов
/ 28 ноября 2018

Я впервые использую Azure AD B2C в качестве сервера аутентификации пользователей в любом из моих проектов.Я новичок в этих концепциях и пытаюсь собрать воедино свое понимание их.

Я использую службу Azure AD B2C.Я разрабатываю набор приложений, которые в конечном итоге будут использовать B2C в качестве механизма аутентификации пользователей.Например, у меня есть сервер ASP.NET Core API, который предоставляет мои внутренние данные SQL конечным пользователям.У меня есть приложение JavaScript React, которое использует неявный рабочий процесс B2C для аутентификации и получения токенов.Наконец, у меня есть настольное приложение C #, которое использует поток учетных данных владельца ресурса для получения моих токенов B2C.

Итак, как вы можете видеть, у меня есть несколько разных приложений B2C разных типов.,У меня есть веб-приложение, которое может использовать неявный интерактивный рабочий процесс.У меня есть настольное приложение, которое может использовать рабочий процесс ROPC для получения токенов.У меня есть веб-сервер, который мне нужен для проверки токенов.

Моя путаница связана с моим внутренним API-сервером и его собственной проверкой предоставленных токенов носителя B2C от пользователей.

Это моепонимая, что мне нужно настроить свой сервер API так, чтобы для выдачи токена ему требовалась определенная политика (полномочия).Это достаточно просто - в настоящее время я ожидаю, что интерактивная политика входа по умолчанию, предоставляемая B2C, предоставляется по умолчанию.

Мое веб-приложение, основанное на браузере приложение React, может просто использовать этот же знак в пользовательском потоке политики и предоставлятьтокен доступа к серверу API и все работает, потому что оба используют ту же политику, что и издатель / орган.

Мое приложение с графическим интерфейсом, хотя и не использует ту же политику входа в систему, оно использует политику ROPC, которая не проходитпроверка полномочий сервера API, поскольку сервер ожидает, что политика входа предоставила токен.

У меня вопрос ...

Как согласовать все эти политики?Правильно ли я считаю, что мои различные «клиентские приложения» должны быть свободны для генерирования токенов с помощью какой-либо политики (пользовательского потока) для них?Но тогда какую политику должен использовать мой API-сервер в качестве органа, поскольку для него требуется одна-единственная политика?

Ответы [ 2 ]

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

URL-адрес эмитента должен быть одинаковым для всех политик одного и того же арендатора.

https://{tenant-name}.b2clogin.com/{tenant-id}/v2.0/

Пример:

https://fabrikamb2c.b2clogin.com/775527ff-9a37-4307-8b3d-cc311f58d925/v2.0/

Этоозначает, что вы можете настроить любые полномочия на сервере API, и он должен проверять токены, выданные для любой политики.

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

@ Райан, ваш веб-API ASP.NET Core 2.1 может решить, как проверять токены с помощью TokenValidationParameters.Например, я не проверял конкретный случай B2C, но подозреваю, что разница будет исходить от эмитентов.

В этом примере показано, как переопределить проверку эмитентов по умолчанию: active-directory-aspnetcore-webapp-openidconnect-v2, ветвь aspnetcore2-2-signInAndCallGraph, в строке Startup.cs 61

options.TokenValidationParameters.IssuerValidator = AadIssuerValidator.ValidateAadIssuer;

, а затем метод AadIssuerValidator.ValidateAadIssuer можно найти здесь в AadIssidal.cs

Этот принимает все организации AAD, если токен поступает из Azure AD (конечная точка v1.0 или v2.0).Я думаю, что вы могли бы адаптировать его к случаю B2C, принимая ваш хост (something.b2clogin.com?)?

Более подробную информацию вы также найдете в статье TokenValidation Microsoft.Идентификационные расширения для .NET wiki

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...