- Calling Parent -> GetChild, возвращает «401 - У вас нет прав для просмотра этого каталога или страницы»
Без использования идентификаторов клиентов / секретов / ключей / и т. Д., Как я думал, идея
за управляемой идентичностью было выбрасывать все это в окно, учитывая
все вышеперечисленное, должен ли родитель иметь возможность звонить ребенку? И если да, то что
я неправильно настроил?
При текущей настройке я замечаю две вещи.
1. Получите токен, используя управляемую идентификацию, для вызова конечной точки службы «Дочерний» из «Родителя»
Управляемая идентификация только предоставляет службе вашего приложения идентификационную информацию (без необходимости управлять / поддерживать секреты или ключи приложения). Затем этот идентификатор можно использовать для получения токенов для различных ресурсов Azure.
Но ваше приложение по-прежнему несет ответственность за использование этой идентичности и получение токена для соответствующего ресурса. В этом случае соответствующим ресурсом будет ваш «дочерний» API. Я думаю, что это, вероятно, та часть, которую вы сейчас упускаете.
Соответствующая документация по документам Microsoft - Как использовать управляемые удостоверения для функций службы приложений и 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. В вашем случае вы замените https://vault.azure.net идентификатором Uri для вашей «детской» услуги. Обычно по умолчанию он установлен на https://<yourappservicename>.azurewebsites.net, но вы можете найти его значение, перейдя в приложения Azure AD и затем найдя соответствующий регистрационный номер приложения> манифест. Вы также можете использовать applicationId для целевого приложения (то есть «дочерний») для получения токена.
В случае, если вы не используете C # /. NET , та же ссылка Microsoft Docs выше также содержит руководство по получению токена с использованием Managed Identity и вызовов REST с любой платформы. , Использование протокола REST
Вот сообщение в блоге, в котором также подробно рассказывается - Позвоните на защищенный веб-сайт Azure AD с использованием идентификатора управляемой службы (MSI)
2. Назначения ролей Azure RBAC отличаются от ролей Azure AD, которые вы, возможно, захотите использовать
Я вижу, что вы назначили роль участника для идентификации службы родительских приложений из IAM. Это назначение ролей работает для Azure RBAC и помогает в предоставлении разрешений для управления ресурсами, но утверждения роли Azure AD работают по-другому.
Если вы хотели назначить роль родительскому приложению, которую можно проверить в дочернем приложении, и только после этого разрешить вызовы, то это можно настроить по-другому.
Прежде всего я должен упомянуть, что эта установка на основе ролей предназначена для небольшого продвинутого сценария и не является обязательной. Вы должны иметь возможность позвонить в службу «Ребенок» из «Родителя», как только вы выполните шаги, описанные в пункте 1, описанном выше.
Теперь, когда работает звонок от Родителя к Ребенку, вы можете ограничить доступ к службе дочерних приложений только «Родителем» или несколькими действительными приложениями. Вот два подхода к достижению этого.
Оба подхода описаны здесь в Документах Microsoft - Платформа идентификации Microsoft и поток учетных данных клиента OAuth 2.0
Связи SO сообщений и блога
Подход 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», в противном случае вы можете отклонить вызов с неавторизованным исключением.