У меня есть работающее приложение демона Azure AD / Azure, использующее adal4j, которое использует аутентификацию пользователя / пароля. Из-за проблем с ADFS я также хочу иметь возможность аутентифицироваться с использованием принципала службы (идентификатор / секрет клиента). Кажется, это нормально работает для части приложения Azure (не AD), поскольку роли SP могут быть определены для рассматриваемых подписок, однако для части Azure AD я получаю:
response code 403, error: Authorization_RequestDenied: Insufficient privileges to complete the operation.
... это происходит при первом вызове Graph API - я получаю действительные токены из AuthenticationContext.acquireToken (), используя https://graph.windows.net.
Моя учетная запись является владельцем каталога. Я пробовал использовать кнопку «Предоставить разрешения» в приложении, а также попытался сфабриковать URL-адрес согласия (который работает) и использовать его, чтобы разрешить приложению необходимые привилегии в каталоге. Ни то, ни другое, похоже, на это не влияет.
Это собственное приложение, так как это приложение-демон / служба, поэтому оно не может участвовать в согласии OAuth2.
Как получить доступ к API Graph Azure AD с помощью SP для аутентификации? Напоминаем, что без изменений приложение работает с пользователем / паролем (не ADFS), а SP работает с API Azure, а не с API Graph Azure AD.
Спасибо...
P.S. Я также пробовал это с помощью Azure Graph API, который Microsoft теперь рекомендует вместо Azure AD Graph API. Тот же результат и аналогично работает с кредитами пользователя / пароля.
Внесение поправок в это, чтобы убрать adal4j с поля зрения - это скорее общая проблема Azure AD. Вот пример проблемы с использованием curl:
Запрос токена учетных данных клиента:
curl --request POST "https://login.windows.net/367cxxxx41e5/oauth2/token" --data-urlencode "resource=https://graph.windows.net" --data-urlencode "client_id=9d83yyyy08cd" --data-urlencode "grant_type=client_credentials" --data-urlencode "client_secret=secret"
Ответ токена учетных данных клиента:
{"token_type":"Bearer","expires_in":"3599","ext_expires_in":"0","expires_on":"1491486990","not_before":"1491483090","resource":"https://graph.windows.net","access_token":"eyJ0zzzz2zVA"}
Запрос REST Azure AD с использованием токена учетных данных клиента:
curl "https://graph.windows.net/367cxxxx41e5/tenantDetails" --header "Authorization: eyJ0xxxx2zVA" --header "Accept: application/json;odata=minimalmetadata" --header "api-version: 1.6"
Ответ REST Azure AD с использованием токена учетных данных клиента:
{"odata.error":{"code":"Authorization_RequestDenied","message":{"lang":"en","value":"Insufficient privileges to complete the operation."}}}
Теперь сравните это с (обратите внимание на тот же идентификатор клиента / идентификатор приложения):
Запрос токена учетных данных пароля:
curl --request POST "https://login.windows.net/367cxxxx41e5/oauth2/token" --data-urlencode "resource=https://graph.windows.net" --data-urlencode "client_id=9d83yyyy08cd" --data-urlencode "grant_type=password" --data-urlencode "[email protected]" --data-urlencode "password=password"
Ответ токена учетных данных пароля:
{"token_type":"Bearer","scope":"Directory.AccessAsUser.All Directory.Read.All Group.Read.All Member.Read.Hidden User.Read User.Read.All User.ReadBasic.All","expires_in":"3599","ext_expires_in":"0","expires_on":"1491489157","not_before":"1491485257","resource":"https://graph.windows.net","access_token":"eyJ0zzzz0EXQ","refresh_token":"AQABzzzzAgAA"}
Запрос REST Azure AD с использованием токена учетных данных пароля:
curl "https://graph.windows.net/367cxxxx41e5/tenantDetails" --header "Authorization: eyJ0xxxx0EXQ" --header "Accept: application/json;odata=minimalmetadata" --header "api-version: 1.6"
Ответ REST Azure AD с использованием токена учетных данных пароля:
{"odata.metadata":"https://graph.windows.net/367cxxxx41e5/$metadata#directoryObjects/Microsoft.DirectoryServices.TenantDetail","value":[{"odata.type":"Microsoft.DirectoryServices.TenantDetail","objectType":"Company","objectId":"367cxxxx41e5","deletionTimestamp":null,"assignedPlans":[{"assignedTimestamp":"2017-02-24T03:25:33Z","capabilityStatus":"Enabled","service":"SharePoint","servicePlanId":"e95byyyyc014"},...
На данный момент я подозреваю, что SP, созданный по умолчанию Azure AD при создании приложения, не включает необходимые разрешения. Попробую создать новый ИП с указанными правами. Примеров этого предостаточно, но все они сосредоточены на том, что целевое приложение является мифическим бизнес-приложением, а не Azure AD. И, как это обычно бывает с недоработанным порталом, для этого необходимо использовать интерфейс командной строки.
</snark>
Кроме того, я убедился, что любой человек с ролью Читателя должен иметь возможность выполнить этот запрос. Я добавил и Contributer, и Owner в SP, но безрезультатно.
Также, FWIW, я подтвердил, что SP теоретически имеет разрешения Azure AD (и другие), которые я ввел на портале. Думаю.
PS C:\> Get-AzureADServicePrincipalOAuth2PermissionGrant -objectid 'a9f9xxxx5377'|format-list -property consenttype,resourceid,scope
ConsentType : AllPrincipals
ResourceId : c569xxxxe7f0
Scope : Member.Read.Hidden User.Read User.ReadBasic.All User.Read.All Group.Read.All Directory.Read.All
Directory.AccessAsUser.All
ConsentType : AllPrincipals
ResourceId : 3318xxxx66a5
Scope : user_impersonation
ConsentType : AllPrincipals
ResourceId : 8c0fxxxx4198
Scope : User.Read.All User.ReadBasic.All Group.Read.All Directory.Read.All Directory.AccessAsUser.All User.Read
PS C:\> get-azureadobjectbyobjectid -objectids 'c569xxxxe7f0','3318xxxx66a5','8c0fxxxx4198'
ObjectId AppId DisplayName
-------- ----- -----------
8c0fxxxx4198 00000003-0000-0000-c000-000000000000 Microsoft Graph
3318xxxx66a5 797f4846-ba00-4fd7-ba43-dac1f8f63013 Windows Azure Service Management API
c569xxxxe7f0 00000002-0000-0000-c000-000000000000 Microsoft.Azure.ActiveDirectory
