Служба приложений для проверки подлинности службы приложений в Azure с помощью управляемого удостоверения

• Calling Parent -> GetChild, returns "401 - You do not have permission to view this directory or page"

Without the use of Client ids/Secrets/Keys/etc, as I thought the idea behind Managed Identity was to throw that all out the window, given all the above, should Parent be able to call Child? And if so, what have I setup wrong?

Есть две вещи, которые я замечаю в текущей настройке.

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

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

Но ваше приложение по-прежнему несет ответственность за использование этого удостоверения и получение токена для соответствующего ресурса. В этом случае соответствующим ресурсом будет ваш «Дочерний» API. Я думаю, что это, вероятно, та часть, которую вам сейчас не хватает.

Соответствующая документация по Microsoft Docs — Как использовать управляемые удостоверения для службы приложений и функций Azure > Получить токены для ресурсов Azure

using Microsoft.Azure.Services.AppAuthentication;
using Microsoft.Azure.KeyVault;
// ...
var azureServiceTokenProvider = new AzureServiceTokenProvider();
string accessToken = await azureServiceTokenProvider.GetAccessTokenAsync("https://vault.azure.net");

// change this to use identifierUri for your child app service. 
// I have used the default value but in case you've used a different value, find it by going to Azure AD applications > your app registration > manifest
string accessToken = await azureServiceTokenProvider.GetAccessTokenAsync("https://<yourchildappservice>.azurewebsites.net");

Этот пример C#/.NET использует пакет nuget Microsoft.Azure.Services.AppAuthentication и получает токен для Azure Key Vault. В вашем случае вы замените https://vault.azure.net идентификатором Uri для вашего «дочернего» сервиса. Обычно по умолчанию установлено значение https://<yourappservicename>.azurewebsites.net, но вы можете узнать его значение, перейдя в приложения Azure AD и найдя регистрацию соответствующего приложения > манифест. Вы также можете использовать applicationId для целевого приложения (т.е. «дочернего») для получения токена.

Если вы не используете C#/.NET, по той же ссылке Microsoft Docs выше также есть руководство по получению токена с помощью управляемого удостоверения и Вызовы на основе REST с любой платформы. Использование протокола REST

Вот сообщение в блоге, которое также дает хороший обзор - Вызов веб-сайта, защищенного Azure AD, с помощью управляемого удостоверения службы (MSI).

2. Назначение ролей Azure RBAC отличается от ролей Azure AD, которые вы можете использовать.

Я вижу, что вы назначили роль участника удостоверению родительской службы приложений из IAM. Это назначение ролей работает для Azure RBAC и помогает в предоставлении разрешений на управление ресурсами, но утверждения роли Azure AD работают по-другому.

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

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

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

Оба подхода объясняются в Microsoft Docs здесь — Платформа Microsoft Identity и поток учетных данных клиента OAuth 2.0.

Связанные сообщения SO и блог

• Есть ли способ защитить функцию Azure, которая будет вызываться только из определенного приложения логики Azure?

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

• https://joonasw.net/view/calling-your-apis-with-aad-msi-using-app-permissions

Подход 1. Используйте списки контроля доступа

Когда ваш «дочерний» API получает токен, он может декодировать токен и извлекать идентификатор клиентского приложения из утверждений appid и iss. Затем он сравнивает приложение со списком управления доступом (ACL), который оно поддерживает.

В зависимости от ваших требований API может предоставить только часть полных разрешений или все разрешения конкретному клиенту.

Подход 2 — использование разрешений или ролей приложения

Настройте дочернее приложение API для предоставления набора разрешений (или ролей) приложения.

Этот подход немного более декларативен, так как вы определяете разрешение приложения, которое должно быть назначено любому приложению, которое может вызывать ваш child-api.

Перейдите в Azure Active Directory > Регистрация приложений > Регистрация приложения для вашего приложения child-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 child API",
  "value": "MyAPIValidClient"
}]

Назначьте разрешение приложения вашему внешнему приложению

New-AzureADServiceAppRoleAssignment -ObjectId <parentApp.ObjectId> -PrincipalId <parentApp.ObjectId> -Id "fc803414-3c61-4ebc-a5e5-cd1675c14bbb" -ResourceId <childApp.ObjectId>

Теперь в токене аутентификации, полученном вашим дочерним API, вы можете проверить, что коллекция утверждений ролей должна содержать роль с именем «MyAPIValidClient», в противном случае вы можете отклонить вызов с неавторизованным исключением.

Чтобы расширить принятый ответ.

1. Вам необходимо определить «Роль приложения» в манифесте регистрации целевого приложения. Это регистрация приложения, которая используется для представления ресурса (служба приложений API).

2. Затем вы используете Azure CLI, чтобы предоставить разрешение для этой «роли приложения» корпоративному приложению (которое создается при настройке управляемого удостоверения для клиентского приложения). Подробные инструкции см. в разделе «API и другие зарегистрированные приложения Azure AD» в этой статье https://blog.yannickreekmans.be/secretless-applications-add-permissions-to-a-managed-identity/.

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

public class AzureAdTokenRetriever : IAzureAdTokenRetriever
{
    private readonly ILogger<AzureAdTokenRetriever> logger;
    private readonly IMemoryCache inMemoryCache;

    public AzureAdTokenRetriever(
        ILogger<AzureAdTokenRetriever> logger,
        IMemoryCache inMemoryCache)
    {
        this.logger = logger;
        this.inMemoryCache = inMemoryCache;
    }

    public async Task<string> GetTokenAsync(string resourceId, string scope = "/.default")
    {
        var resourceIdentifier = resourceId + scope;
        if (inMemoryCache.TryGetValue(resourceIdentifier, out var token))
        {
            this.logger.LogDebug("Token for {ResourceId} and {Scope} were fetched from cache", resourceId, scope);
            return (string)token;
        }

        var tokenCredential = new DefaultAzureCredential();
        var accessToken = await tokenCredential.GetTokenAsync(
            new TokenRequestContext(new [] { resourceIdentifier }), CancellationToken.None)
            .ConfigureAwait(false);

        // Set cache options with expiration 5 minutes before the token expires
        var cacheEntryOptions = new MemoryCacheEntryOptions().SetAbsoluteExpiration(accessToken.ExpiresOn.AddMinutes(-5));
        inMemoryCache.Set(resourceIdentifier, accessToken.Token, cacheEntryOptions);
        this.logger.LogDebug("Token for {ResourceId} and {Scope} saved in cache with expiration of {TokenExpiry}",
            resourceId, scope, cacheEntryOptions.AbsoluteExpiration);

        return accessToken.Token;
    }
}