Что в действительности делают параметры в «Действиях» при создании настраиваемой роли в Azure AD?

Question

Я изучаю возможность создания пользовательской роли Azure AD для использования в качестве части [Авторизация] в службе веб-приложений Azure. Когда вы включаете список «Действия», вы также создаете разрешения для этой роли?

Может ли "Действия" быть пустыми? Допустим, я просто хочу проверить роль в контроллере, а затем контролировать доступ к данным оттуда? Нужно ли что-нибудь в разделе «Действия»?

Answer 1

Существуют две совершенно разные концепции:

1. Пользовательские роли в Azure (для управления доступом на основе ролей ресурсов Azure)
2. Роли приложения в Azure AD (для авторизации в приложениикоторый использует Azure AD)

Исходя из вашего вопроса, вам необходимо внимательно изучить второй вопрос, то есть роли приложений.У них нет списка «Действия» как часть их определения.Я постараюсь дать немного больше подробностей относительно 1 и 2 ниже, чтобы прояснить ситуацию.

Пользовательские роли в Azure (у них есть список «Действия», но он не поможет в реализации логики авторизации ввеб-приложение)

Документация Microsoft - Пользовательские роли в Azure

Назначение - Azure уже предоставляет встроенные роли как часть портала Azure для управления доступом к вашим ресурсам в портале Azure на основе назначенных ролей.Если у вас есть сценарий, в котором ни одна из встроенных ролей не соответствует вашему требованию, вы можете создать настраиваемую роль, но цель по-прежнему заключается в том, чтобы назначить эту настраиваемую роль кому-либо, чтобы они могли управлять / работать с подготовленными.ресурсы в Azure.Например, владелец или читатель для сервера базы данных SQL Azure или одной или нескольких виртуальных машин.Эти роли будут использоваться на портале Azure / PowerShell / CLI и т. Д.

Эти роли очень полезны в большой организации, где каждый не может быть владельцем / администратором на уровне подписки Azure, но ему по-прежнему может быть предоставлен доступ.на детальном уровне только для некоторых из ресурсов подписки Azure (таких как базы данных, vms, логические приложения, учетные записи хранения или все, что доступно в подписке Azure по этому вопросу).Это выполняется через Управление доступом на основе ролей через портал / PowerShell / CLI.

Пример

{
  "Name":  "Virtual Machine Operator",
  "Id":  "88888888-8888-8888-8888-888888888888",
  "IsCustom":  true,
  "Description":  "Can monitor and restart virtual machines.",
  "Actions":  [
                  "Microsoft.Storage/*/read",
                  "Microsoft.Network/*/read",
                  "Microsoft.Compute/*/read",
                  "Microsoft.Compute/virtualMachines/start/action",
                  "Microsoft.Compute/virtualMachines/restart/action",
                  "Microsoft.Authorization/*/read",
                  "Microsoft.Resources/subscriptions/resourceGroups/read",
                  "Microsoft.Insights/alertRules/*",
                  "Microsoft.Insights/diagnosticSettings/*",
                  "Microsoft.Support/*"
  ],
  "NotActions":  [

                 ],
  "DataActions":  [

                  ],
  "NotDataActions":  [

                     ],
  "AssignableScopes":  [
                           "/subscriptions/{subscriptionId1}",
                           "/subscriptions/{subscriptionId2}",
                           "/subscriptions/{subscriptionId3}"
                       ]
}

Роли приложений в Azure AD (у них нет списка «Действия», но они предназначены для логики авторизации в вашем приложении)

Документация Microsoft - Роли приложений

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

С помощью «allowMemberTypes» вы можете контролировать, кому могут быть назначены эти роли (пользователям, группам или даже приложениям).

Затем вы можете назначать роли из портала Azure или программно.Один простой способ будет выглядеть так, как показано на скриншоте ниже -

При попытке реализовать логику авторизации эти роли будут доступны как «утверждения» роли,Таким образом, вы сможете проверять роли с помощью приведенного ниже кода:

if (context.User.HasClaim(ClaimTypes.Role, "Admin")) { ... }

Образец приложения, которое создает роли приложения и затем использует их для авторизации Авторизация в веб-приложении с использованием AzureРоли приложений AD и заявки о ролях

Пример Это JSON, который будет использоваться как часть вашего манифеста приложения.

"appRoles": [
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Creators can create Surveys",
    "displayName": "SurveyCreator",
    "id": "1b4f816e-5eaf-48b9-8613-7923830595ad",
    "isEnabled": true,
    "value": "SurveyCreator"
  },
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Administrators can manage the Surveys in their tenant",
    "displayName": "SurveyAdmin",
    "id": "c20e145e-5459-4a6c-a074-b942bbd4cfe1",
    "isEnabled": true,
    "value": "SurveyAdmin"
  }
]