Как я могу заставить приложение логики Azure использовать свой идентификатор управляемой службы для проверки подлинности с помощью соединителя? - PullRequest
Новая
       20

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

0 голосов
/ 11 января 2019

Мое приложение логики Azure работает как удостоверение управляемой службы, и я пытаюсь использовать соединитель Azure AD в качестве триггера для приложения. Для соединителя требуются разрешения для API-интерфейса Azure AD Graph, и я проверил правильность разрешений, выполнив аутентификацию MSI ServicePrincipal с использованием ClientCredentials с помощью PowerShell и вызвав необходимые API-интерфейсы Azure AD Graph.

Однако я не могу сказать, что Azure AD Connector моего приложения логики (в отличие от вызова REST, где я могу просто установить свойство аутентификации) для использования идентификатора управляемой службы.

Поскольку документация для коннекторов Logic Apps, предоставленных Microsoft, отсутствует, я не могу сказать, есть ли в Azure AD Connector хорошо известное свойство, которое я могу использовать, чтобы указать ему, как выполнять аутентификацию. У меня есть следующее в моем шаблоне ARM, и я думаю, что есть customParameterValue для установки, но я понятия не имею, что это такое. 

{
    "type": "Microsoft.Web/connections",
    "name": "[parameters('connections_azuread_name')]",
    "apiVersion": "2016-06-01",
    "location": "eastus",
    "scale": null,
    "properties": {
        "displayName": "Azure AD",
        "customParameterValues": {},
        "api": {
            "id": "[concat('/subscriptions####/providers/Microsoft.Web/locations/eastus/managedApis/', parameters('connections_azuread_name'))]"
        }
    },
    "dependsOn": []
}

1 Ответ

0 голосов
/ 04 апреля 2019

Я немного опоздал на вечеринку, я знаю, но я уже давно использую Managed Identities (MI) и в основном пришел к выводу, что они еще не готовы для массового использования. Они - отличная концепция, и я надеюсь, что они продолжают расти, но ограничения, такие как большинство коннекторов, которые еще не поддерживают их, и ограничение, что вы можете иметь только 10 логических приложений с идентификаторами на подписку, строго ограничивают их использование.

Я, по сути, прибег к использованию одного логического приложения с MI, которое создает соответствующий блок аутентификации для службы на основе некоторых переданных значений, и получения секретов из хранилища ключей. Любое другое приложение логики вызывает это приложение логики «аутентификации», чтобы получить детали, которые они должны затем передать вызовам API, функциям Azure и т. Д.

Мне также необходимо защитить все мои функции Azure AAD, поэтому опять-таки MI были бы фантастическими, если бы LA могли вызывать аутентифицированные функции, но, опять же, действие функции Azure еще не поддерживает MI (или какая-либо аутентификация действительно ). Поэтому мне приходится прибегать к вызову FA с использованием HTTP-коннектора (с аутентификацией).

Приложения логики настолько близки к удивительным, что разочаровывают, что их просто еще нет!

Чтобы ответить на ваш вопрос, я обнаружил, что некоторые разъемы допускают блокировку аутентификации, например ... 

{
  "audience": "XXXXXXXXXXXX",
  "type": "ManagedServiceIdentity"
}
...