Как реализовать разрешения пользователей для операций в Azure API Management? - PullRequest
Новая
       6

Как реализовать разрешения пользователей для операций в Azure API Management?

0 голосов
/ 12 сентября 2018

Я создал .NET Core 2.0 API и опубликовал его в Azure.У меня есть экземпляр API Management (APIM), стоящий перед этим API и делающий все замечательные вещи, которые он делает.Однако есть одна вещь, которую я не могу обернуть головой или найти какую-либо документацию.Авторизация по операциям.(Не путать с аутентификацией, которая у меня работает очень хорошо).

Мой API - это простая служба RESTful с действиями CRUD.Давайте возьмем операцию чтения, например: 

GET /api/owner/{ownerid}/thing/{thingid}

В этом случае я хочу предоставить пользователям разрешения на ЧТЕНИЕ ВЕЩЕЙ в конкретном ВЛАДЕЛЬЦЕ.Один и тот же пользователь не может иметь разрешения на чтение с другим владельцем.Если у пользователя есть разрешения, 200 OK;в противном случае, 403 Forbidden.

Оставляя это полностью carte blanche , каковы некоторые предложения для реализации этого?Я предполагаю, что входящая политика для каждой операции в APIM, где действие будет иметь место?Если да, то как?

Обновление 1

Мне сообщили о возможности использования одной и той же политики validate-jwt на отдельных уровнях операций для добавления к * 1019.* политика в корне.Идея состоит в том, что корневая политика проверяет, что пользователь прошел проверку подлинности, а политика операций проверяет наличие определенных утверждений.Кажется, это работает хорошо, но это правильный метод или просто взлом?

Обновление 2

Для работы опции validate-jwt модель разрешениянеобходимо будет хорошо согласовываться с ролями и группами;в противном случае это такая же работа, как и создание собственной пользовательской базы данных, в которой, по крайней мере, вы извлекаете выгоду из своих собственных правил.В конце я поместил разрешения в таблицу учетной записи хранения Azure (подойдет любая база данных) и использовал send-request (с соответствующим кэшированием) для сбора разрешений на основе текущей операции и пользователя.Это работает хорошо, но "чувствует себя неправильно".Я рад поделиться подробностями с любым, кто хочет.А пока я оставлю это открытым, если у кого-то есть идея получше.

Ответы [ 2 ]

0 голосов
/ 14 сентября 2018

В итоге оказывается, что встроенного решения нет.Прокатить собственную модель разрешений и затем проверить ее самостоятельно - вот путь.

Однако ...

Это все еще можно сделать в APIM.Как я уже упоминал во втором обновлении, я смог заставить работать индивидуальное решение.Это было сделано для использования входящей политики на уровне «все операции» для получения разрешений.(Механизм кэширования использовался для того, чтобы не получать разрешения для каждого отдельного вызова.) Затем каждая операция определяет, есть ли у пользователя разрешение на эту конкретную операцию, на основе параметров, которые были переданы. (Это также кэшируется.)

В результате у корневого API нет встроенной аутентификации или авторизации, но APIM делает это, и соответствующее поведение наблюдается.

Тем не менее предпочтение будет отдано подходу RBAC.Например, представьте, что отдельные операции рассматриваются как сервисы, как в этом определении роли: 

{
  "Name": "{rolename}",
  "Id": "{roleid}",
  "IsCustom": true,
  "Description": "{roledescription}",
  "Actions":  [
    "GET {myapi}/owner/{ownerid}/*",
    "POST {myapi}/owner/{ownerid}/*",
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscriptionid}"
  ]
}

Если бы это было возможно, мы могли бы создать роли, назначить их пользователям / группам на уровне подписки, а затем получитьпретензии автоматически передаются в APIM, где они могут оцениваться, как и любые другие претензии.

0 голосов
/ 14 сентября 2018

В конечном счете, единственный способ сделать это - использовать политики на уровне операций. вы можете использовать validate-jwt для проверки конкретных требований, вы можете проверить некоторые другие учетные данные, которые передаются вам как часть запроса. Или вы можете использовать send-request, чтобы позвонить в какой-либо другой сервис и запросить разрешения пользователя. В самом APIM нет места для хранения каких-либо данных, связанных с пользователем, кроме некоторой базовой информации, поэтому такая информация об авторизации требуется извне APIM.

...