Azure Active Directory - как ограничить регистрацию приложения Backend API определенным клиентом Регистрация приложения

Я мог бы быть совершенно не в курсе того, как это работает, но это то, чего я хочу достичь.

В AAD у меня есть

  • Регистрация приложения называется backend-api который представляет HTTP API
  • Регистрация приложения называется frontend-app который представляет некоторый клиент (скажем, консольное приложение)
  • Регистрация приложения называется another-app это не имеет ничего общего с моим решением

У меня есть консольное приложение, в которое я помещаю свой идентификатор клиента и секрет клиента для frontend-app и я могу запросить access_token с aud из backend-api, Это здорово, именно то, что я хочу. Тем не менее, я могу буквально сделать то же самое из another-app если у меня есть идентификатор клиента и секрет клиента для этого приложения. То, что я хотел бы сделать, это то, что только frontend-app разрешено получить access_token за backend-api ,

Я не совсем уверен, как настроить конкретное требование. Я подумал, может быть, мне нужно добавить appRoles вход для allowedMemberTypesApplication на backend-api а затем предоставить frontend-app эта роль, но это не накладывало никаких ограничений на another-app, Точно так же я думал, что может быть backend-api Мне нужно было включить опцию "Требовать входа пользователя" в разделе "Приложения для предприятий", но я не смог найти способ добавить frontend-app как "пользователь" - вероятно, неправильное направление в любом случае.

Какой способ сказать AAD только раздавать access_tokens за backend-api ( aud требование), если они запрашиваются через frontend-app только? Может быть, это глупый вопрос, и он просто так не работает?

Источник

2 ответа

Решение

Вы находитесь на правильном пути с вашими мыслями о добавлении appRoles вход в backend-api а затем назначая роль специально для frontend-app,

Кроме того, следует понимать, что обеспечение выполнения этого требования, при котором разрешено только приложения, поступающие с этим новым заявлением о роли, а другие нет, является ответственностью вашего кода API.

Я доберусь до 2 конкретных подходов дальше. Оба подхода описаны здесь в Документах Microsoft - платформа идентификации Microsoft и поток учетных данных клиента OAuth 2.0

Подход 1 - Использовать разрешения приложений или роли

Сконфигурируйте свое API-приложение для предоставления набора разрешений (или ролей) приложения.

Этот подход немного более декларативен, так как вы определяете разрешение приложения, которое должно быть назначено любому приложению, которое может вызвать ваш backend-api,

Перейдите в Azure Active Directory > Регистрация приложений> Регистрация приложения для вашего backend-api приложение> Манифест

Добавьте новую роль приложения.. используя json, например:

"appRoles": [
{
  "allowedMemberTypes": [
    "Application"
  ],
  "displayName": "Can invoke my API",
  "id": "fc803414-3c61-4ebc-a5e5-cd1675c14bbb",
  "isEnabled": true,
  "description": "Apps that have this role have the ability to invoke my backend API",
  "value": "MyAPIValidClient"
}]

Назначьте разрешение приложению вашему веб-приложению

New-AzureADServiceAppRoleAssignment -ObjectId <frontendapp.ObjectId> -PrincipalId <frontendapp.ObjectId> -Id "fc803414-3c61-4ebc-a5e5-cd1675c14bbb" -ResourceId <yourbackendapi.ObjectId>

Аутентифицируйте ваше веб-приложение, чтобы оно работало с API-интерфейсом клиента с помощью предоставления клиентских учетных данных, т.е. с помощью clientId и client secret... как вы, вероятно, уже делаете

Теперь в токене авторизации, полученном вашим API-интерфейсом сервера, вы можете проверить, что коллекция утверждений роли должна содержать роль с именем "MyAPIValidClient", в противном случае вы можете отклонить вызов с неавторизованным исключением.

Подход 2 - Использовать списки контроля доступа

Когда ваш бэкэнд-API получает токен, он может декодировать токен и извлечь идентификатор клиентского приложения из appid а также iss претензии. Затем он сравнивает приложение со списком контроля доступа (ACL), который он поддерживает.

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

Этот 2-й подход может показаться более простым в некоторых случаях, хотя мне больше нравится первый, так как он хорошо масштабируется, когда у вас есть несколько разрешений / ролей приложений и разный уровень функциональности для предоставления на основе этих ролей.

Связанные SO Post и ссылки

Источник

На backend-api можно создавать области действия с параметром согласия «Только администраторы».

любое приложение (например, другое приложение), которое запрашивает доступ к области, должно быть заблокировано, если разрешение не добавлено и администратор не предоставит разрешение.

Администратор может в любой момент отозвать разрешение, чтобы предотвратить доступ к области backend-api.

Источник
Другие вопросы по тегам