Авторизация области действия WebAPI посредством регистрации приложений Azure - PullRequest
0 голосов
/ 01 мая 2018

Я пытаюсь контролировать авторизацию через регистрации приложений в Azure.

Сейчас у меня настроены две регистрации приложений.

  • ApiApp
  • ClientApp

ApiApp настроен с настройками по умолчанию, но я добавил это в манифест:

"oauth2Permissions": [
    {
      "adminConsentDescription": "Allow admin access to ApiApp",
      "adminConsentDisplayName": "Admin",
      "id": "<guid>",
      "isEnabled": true,
      "type": "User",
      "userConsentDescription": "Allow admin access to ApiApp",
      "userConsentDisplayName": "Admin",
      "value": "Admin"
    },
...
]

В регистрации клиентского приложения у меня есть все настройки по умолчанию, но я добавил:

  1. В ключах пароль для аутентификации приложения по AD
  2. В необходимых разрешениях я добавил ApiApp и потребовал делегированного разрешения «Администратор». Я сохранил это, нажал «Готово», затем нажал «Предоставить разрешения», чтобы убедиться, что разрешения были принудительно обновлены.

В моем клиентском приложении он использует этот код для аутентификации:

...
var context = new AuthenticationContext(authority);
var clientCredentials = new ClientCredential(<clientId>, <clientSecret>);
var result = await context.AcquireTokenAsync(<apiAppUri>, clientCredentials);
var client = new HttpClient();
client.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", result.AccessToken);
var webResult = await client.GetAsync(<api uri>);

My ApiApp просто использует встроенную авторизацию, если вы выбираете рабочие или школьные учетные записи при создании проекта Web API:

public void ConfigureAuth(IAppBuilder app)
{
    app.UseWindowsAzureActiveDirectoryBearerAuthentication(
        new WindowsAzureActiveDirectoryBearerAuthenticationOptions
        {
            Tenant = ConfigurationManager.AppSettings["ida:Tenant"],
            TokenValidationParameters = new TokenValidationParameters {
                 ValidAudience = ConfigurationManager.AppSettings["ida:Audience"]
            },
        });
}

Это работает:

[Authorize]
public class ValuesController : ApiController

Эти не работают :

[Authorize(Users = "Admin")]
public class ValuesController : ApiController

или

[Authorize(Roles= "Admin")]
public class ValuesController : ApiController

Судя по тому, что я читаю, я считаю, что все настроено должным образом, кроме самого проекта ApiApp. Я думаю, что мне нужно настроить авторизацию по-другому или с дополнительной информацией, чтобы позволить областям oauth2Permission правильно использоваться для WebAPI.

Какие шаги я пропускаю, чтобы разрешить определенные области в WebAPI вместо только атрибута [Authorize]?

Я использовал Интеграция приложений с Azure Active Directory , чтобы помочь мне настроить регистрацию приложений, наряду с Служба для обслуживания вызовов с использованием учетных данных клиента , но я не могу найти именно то, что мне нужно для реализации кода в части веб-API.

UPDATE

Я нашел этот ресурс: Начало работы Azure AD .NET Web API *

Это показывает, что вы можете использовать этот код для проверки утверждений о объеме:

public IEnumerable<TodoItem> Get()
{
// user_impersonation is the default permission exposed by applications in Azure AD
if (ClaimsPrincipal.Current.FindFirst("http://schemas.microsoft.com/identity/claims/scope")
                                     .Value != "user_impersonation")
    {
        throw new HttpResponseException(new HttpResponseMessage {
              StatusCode = HttpStatusCode.Unauthorized,
              ReasonPhrase = "The Scope claim does not contain 'user_impersonation' or scope claim not found"
        });
    }
    ...
}

Однако претензии, которые я получаю, не включают претензии по объему.

1 Ответ

0 голосов
/ 03 мая 2018

Вы должны использовать appRoles для приложений и области действия для приложений, действующих от имени пользователей.

Согласно Джанлуке Бертелли в комментариях Azure AD, авторизация на основе области действия :

... в сценарии службы 2, используя поток учетных данных клиента, вы не получите поле SCP. Поскольку вы не выдаете себя за какого-либо пользователя, а вызываете приложение (вы предоставляете фиксированный набор учетных данных). В этом случае вам нужно использовать AppRoles (то есть разрешения приложения, не делегированные), что приводит к другому утверждению. Проверьте отличные инструкции и объяснения здесь: https://joonasw.net/view/defining-permissions-and-roles-in-aad.

В ссылке, которую он предоставляет, обсуждаются appRoles в манифесте приложения.

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

Для этого вам нужно использовать appRoles, которые выглядят так в манифесте приложения:

{
  "appRoles": [
  {
     "allowedMemberTypes": [
        "Application"
      ],
      "displayName": "Read all todo items",
      "id": "f8d39977-e31e-460b-b92c-9bef51d14f98",
      "isEnabled": true,
      "description": "Allow the application to read all todo items as itself.",
      "value": "Todo.Read.All"
    }
  ]
}

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

После получения разрешений обязательно нажмите кнопку «Предоставить разрешения». Для предоставления разрешений приложениям требуется администратор Azure Active Directory.

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

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