Как получить токены доступа Azure Access Directory из неинтерактивного процесса, выполняемого локально, без обмена секретами?

Question

Стандартный шаблон для проверки подлинности неинтерактивного процесса в Azure Active Directory:

1. Использование управляемых удостоверений , когда служба работает в Azure.
2. Используйте поток учетных данных клиента OAuth 2.0 всякий раз, когда управляемые удостоверения недоступны.

Однако # 1 недоступен для служб, работающих локально, а для # 2 требуется совместное использование секретов, что значительно увеличивает операционную сложность - хранение ключей, защиту и ротацию.

Вопрос:

Для установки, в которой Azure Active Directory объединена с Active Directory (см. Диаграмму). Существует ли способ для неинтерактивных служб, работающих локально, получать токены доступа из Azure Active Directory без обмена секретами ? Кажется, все необходимые доверительные отношения существуют, но есть ли способ сделать это?

Answer 1

Краткий ответ: да .

Компоненты

1. Azure Клиент Active Directory, интегрированный в Active Directory, возможность единого входа с использованием Windows Аутентификация .
2. Регистрация приложения с предоставленными разрешениями user_impersonation .
3. A конкретная c конфигурация для вашего запроса MSAL.

детали

Для этого вам необходимо использовать OAuth 2.0 от имени-от-потока, и для этого вам необходимо создать регистрацию приложения в AAD. Убедитесь, что вы «предоставили согласие администратора» для области «user_impersonation» каждого API, к которому у ваших локальных приложений должна быть возможность доступа. Типичные примеры:

• Azure Key Vault.user_impersonation
• Azure SQL Database.user_impersonation
• Azure Storage.user_impersonation
• Microsoft Graph.user_impersonation

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

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

const string ApplicationRegistrationId = "the id";
const string Tenant = "YourDomain.com";

// Any user name will do as long as it's in your domain. This is because AAD will redirect the request to the federated Identity Provider, which will then use Kerberos, which will the real user.
const fakeUsername = "anything@YourDomain.com";

// The user_impersonation scopes you want to access. They need to have been granted on the Application Registration. The example below is for Azure Storage:
var scopes = new string[] { "https://storage.azure.com/user_impersonation" };

var app = PublicClientApplicationBuilder.Create(ApplicationRegistrationId).WithAuthority(Tenant).Build();
var authenticationResult = await app.AcquireTokenByIntegratedWindowsAuth(scopes).WithUsername(fakeUsername).ExecuteAsync();
// Go ahead and use the AccessToken from authenticationResult.AccessToken

Диаграмма

Примечания

Я не нашел Подход, описанный выше, документирован где-либо еще, но он доказал свою работоспособность, и, учитывая, что он устраняет необходимость делиться какими-либо секретами - без управления, ротации и т. д. c - было бы здорово увидеть документацию Microsoft.

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