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

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

1 голос
/ 17 мая 2019

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

В 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 для allowedMemberTypes Application на backend-api, а затем предоставить frontend-app эту роль, но это не накладывает никаких ограничений на another-app.Точно так же я подумал, что, возможно, backend-api нужно, чтобы его опция «Требовать входа пользователя» была отмечена в разделе «Приложения для предприятий», но я не смог найти способ добавить frontend-app в качестве «пользователя» - возможно, в любом случае это неправильное направление.

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

1 Ответ

2 голосов
/ 17 мая 2019

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

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

Далее я расскажу о двух конкретных подходах.Оба подхода описаны здесь в Документах 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 и ссылки

...