Авторизация и аутентификация для Azure AD в приложении .netcore - PullRequest
Новая
       12

Авторизация и аутентификация для Azure AD в приложении .netcore

0 голосов
/ 05 июля 2019

Я работаю над приложением API .netcore 2.1, которое пыталось получить доступ к API Graph с помощью функции «От имени потока».

У меня есть общее представление о приведенном ниже коде, как будто он используется для аутентификации пользователя. Но может ли кто-нибудь объяснить, что это означает, построчно или какую-либо документацию, которая поможет мне понять этот и другие варианты авторизации и аутентификации? 

    services.AddMvc(o =>
            {
                o.Filters.Add(new AuthorizeFilter("default"));
            });
            services.AddAuthorization(o =>
            {
                o.AddPolicy("default", builder =>
                {
                    builder
                        .RequireAuthenticatedUser()
                        .RequireClaim(AzureAdClaimTypes.Scope, 
    "user_impersonation");
                });
            });

            services
                .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
                .AddJwtBearer(o =>
                {
                    AuthenticationOptions authSettings = Configuration.GetSection("Authentication").Get<AuthenticationOptions>();

                    o.Authority = authSettings.Authority;

                    o.SaveToken = true;

                    o.TokenValidationParameters = new TokenValidationParameters
                    {
                        ValidAudiences = new List<string> { authSettings.ClientId, authSettings.AppIdUri }
                    };
                });

1 Ответ

0 голосов
/ 07 июля 2019 
services.AddMvc(o =>
{
        o.Filters.Add(new AuthorizeFilter("default"));
});

Добавляет глобальный фильтр, который применяется ко всем контроллерам MVC и действиям. В этом случае требуется авторизация с политикой «по умолчанию». 

services.AddAuthorization(o =>
{
     o.AddPolicy("default", builder =>
     {
            builder
                  .RequireAuthenticatedUser()
                  .RequireClaim(AzureAdClaimTypes.Scope, 
    "user_impersonation");
     });
});

Определяет политику авторизации по умолчанию. Требуется, чтобы аутентификация прошла успешно, и у вызывающей стороны есть область действия user_impersonation по умолчанию. Таким образом, эта область / делегированное разрешение должно быть обязательным и предоставлено вызывающему приложению. Очень важно проверить наличие делегированных / прикладных разрешений. И это так, хотя это не сработает, если у вас определено более 1 делегированного разрешения + предоставлено, потому что заявка будет содержать все из них в одной строке. Вы можете использовать преобразование требований, чтобы разделить их при необходимости. 

services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)

Добавляет службы аутентификации и определяет аутентификацию JWT по умолчанию. 

    .AddJwtBearer(o =>
    {
           AuthenticationOptions authSettings = Configuration.GetSection("Authentication").Get<AuthenticationOptions>();

Добавляет службы схемы аутентификации JWT и получает объект конфигурации. 

o.Authority = authSettings.Authority;

Устанавливает полномочия. Этот URL-адрес используется для получения документа JSON метаданных провайдера идентификации при запуске приложения. Этот документ имеет, например, действительный URI эмитента и ключи подписи. Так что в основном он используется для загрузки данных проверки токена. 

o.SaveToken = true;

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

o.TokenValidationParameters = new TokenValidationParameters
{
      ValidAudiences = new List<string> { authSettings.ClientId, authSettings.AppIdUri }
};

Определяет, что этот API принимает две разные аудитории. Это хорошая практика с AAD. Иногда я видел токены с идентификатором клиента в утверждении aud, а иногда это URI идентификатора приложения. Так что лучше разрешить и то и другое. Но их определение также означает, что API не будет принимать токены, предназначенные для другого API, что хорошо.

...