2017-02-14 20 views
2

Существует два основных API-интерфейса ASP.NET, которые используют аутентификацию маркера на предъявителя. Сервисы также служат статическими файлами, которые используются для согласования API-интерфейсов в каталоге потребляющего приложения. Таким образом, оба API имеют скрытый поток в Azure AD.Проблема с предоставлением разрешения на использование jwt-носителя в Azure AD

API2 вызывает API1 от контроллера веб-API, используя грант jwt-bearer. API2 имеет разрешение на доступ к API1.

Пользователь из третьего каталога переходит в SPA, обслуживаемый API2. Пользователь перенаправляется на Azure AD, подписывает и соглашается с API. Пользователь перенаправляется обратно в приложение SPA, и AJAX-вызов выполняется в API API API2. С этого контроллера другой вызов выполняется в API1. Этот вызов аутентифицируется с использованием гранта jwt-bearer (urn:ietf:params:oauth:grant-type:jwt-bearer).

Когда вызов AcquireToken производятся с учетными данными клиента для API2 и маркера JWT используется для вызова в API2, Azure AD реагирует с ошибкой:

Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: 
AADSTS50027: Invalid JWT token. AADSTS50027: Invalid JWT token. Token format not valid. 
Trace ID: 4031717e-aa0c-4432-bbd1-b97a738d3e6f 
Correlation ID: 61ae6cd6-6df6-49ee-9145-c16570c28f7b 
Timestamp: 2017-02-13 22:44:01Z ---> System.Net.Http.HttpRequestException: Response status code does not indicate success: 400 (BadRequest). ---> System.Exception: {"error":"invalid_request","error_description":"AADSTS50027: Invalid JWT token. AADSTS50027: Invalid JWT token. Token format not valid.\r\nTrace ID: 4031717e-aa0c-4432-bbd1-b97a738d3e6f\r\nCorrelation ID: 61ae6cd6-6df6-49ee-9145-c16570c28f7b\r\nTimestamp: 2017-02-13 22:44:01Z","error_codes":[50027,50027],"timestamp":"2017-02-13 22:44:01Z","trace_id":"4031717e-aa0c-4432-bbd1-b97a738d3e6f","correlation_id":"61ae6cd6-6df6-49ee-9145-c16570c28f7b"} 

Может кто-нибудь сказать мне, что значит эта ошибка? Сам токен JWT является правильным, это должно быть одной из претензий внутри, что не нравится Azure AD.

У меня есть примеры приложений и шаги для воспроизведения в this github repo.

EDIT Диаграмма может уточнить, что я пытаюсь сделать. Это взаимодействие №3 дает мне ошибку. Он использует ClientCredential с ClientId API2 и ClientSecret (или ключ) и оранжевый токен JWT, выданный каталогом3, с аудиторией API2. enter image description here

Оранжевый JWT маркер выглядит следующим образом:

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Il9VZ3FYR190TUxkdVNKMVQ4Y2FIeFU3Y090YyIsImtpZCI6Il9VZ3FYR190TUxkdVNKMVQ4Y2FIeFU3Y090YyJ9.eyJhdWQiOiJmOTJjNGI5MS05NTY3LTRjYjgtOTI4MC0yYmFjNDUyYmZjZTEiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9iYWRiODcyNC1jODExLTRlYjEtOTcwZi04YmI4MzU0NTI0OTEvIiwiaWF0IjoxNDg3MDM1MDI5LCJuYmYiOjE0ODcwMzUwMjksImV4cCI6MTQ4NzAzODkyOSwiYW1yIjpbInB3ZCJdLCJmYW1pbHlfbmFtZSI6Im9uZSIsImdpdmVuX25hbWUiOiJ1c2VyIiwiaXBhZGRyIjoiNzMuMTU3LjExMC4xNjQiLCJuYW1lIjoidXNlciBvbmUiLCJub25jZSI6ImRjOTYwMjkzLWQ0MTItNDFmNy1iMGRhLWYzZWM2NTE1ZTM1YSIsIm9pZCI6IjUzMTE1OTY0LWQwOTMtNGM5NS05MDkzLTg0ZjliNzVmYzNlOSIsInBsYXRmIjoiMyIsInN1YiI6IlVjVFVleGJYd1BWYkZ4aGRDUW9MR25vTkdsZnVQWi1feGtaSndIdU9zM1EiLCJ0aWQiOiJiYWRiODcyNC1jODExLTRlYjEtOTcwZi04YmI4MzU0NTI0OTEiLCJ1bmlxdWVfbmFtZSI6InVzZXIxQHppZWtlbmh1aXNBLm9ubWljcm9zb2Z0LmNvbSIsInVwbiI6InVzZXIxQHppZWtlbmh1aXNBLm9ubWljcm9zb2Z0LmNvbSIsInZlciI6IjEuMCJ9.lhwEL3x3Cu66l-Dt-hWmH2DrmCCX2YORGhl4x4_13_lZuUVhMr1OFLUdJ4MZRWG5DJMc8F_SyC4XdDiStwFDaLSI_4L6noXNau3KF6Su3PnqD-FoXoQPtmPPmFrDRZ7nPEtSazEcd9HeSwgVvRZywJRBKQqQQtBGBpS7-Y9kxrO-moUhnBdJJ-gwhu_wxwdEZaOuLs68sZuFaONAunElMKO1iYlC9VHP5xrVzh3ErnRSIp3xmgJNmlbf-9AFUSrjN5UaFjfpGGGJIvoaKbL6rq-J1XNpvKZDFYvoC7RMkqS1KM-lu-EI7-QCksb3NKhTg6J_bz5uxmjYltjKanWbUg

+0

Можете ли вы поделиться своим токеном доступа с личной информацией, вымытой? Также в вашем сообщении вы говорите: «Когда вызов AcquireToken выполняется с учетными данными клиента для API2 и токена JWT, используемым для вызова API2». Это опечатка? Вы имеете в виду «вызов в API1»? –

+0

Вы проверили этот официальный пример: https://github.com/Azure-Samples/active-directory-dotnet-webapi-onbehalfof/blob/master/TodoListService/Controllers/TodoListController.cs#L137? – juunas

+0

@ShawnTabrizi Спасибо за ваш ответ. Нет, это не опечатка. Я добавил диаграмму, чтобы уточнить, что я пытаюсь сделать. Это взаимодействие №3 вызывает ошибку. – MvdD

ответ

1

Во-первых, для того, чтобы API2 мог onbehalfof пользователю приобрести маркер для API1, мы должны предоставить API1 в API2, когда мы регистрируем API2 в directory2, как показано ниже: enter image description here

Тогда, так как служба принцип API1 также не создан в directory3, мы должны подписать, в API1 первых, чтобы создать сервис принципала API1 на описание товара Directory3 арендатор.

Когда пользователи подписываются в СПА от directory3 и отправить запрос на API2, в коде вы получить маркер из directory2. Мы должны приобрести токен у арендатора пользователей (Directory3).

И в коде, вы приобретали маркер с помощью ClientId, в этом secnario, мы должны использовать ClientCredential, как показано ниже:

var result = await adal.AcquireTokenAsync(resource, clientCred, userAssertion); 

После изменения, код работает хорошо для меня. Пожалуйста, дайте мне знать, помогает ли это.

Кроме того, сценарий, который вы разрабатываете, подобен ниже, и вы можете сослаться на эту деталь из этого link. enter image description here

+0

Спасибо Фэй, отличный ответ. У меня есть несколько вещей. 'нам нужно предоставить API1 для API2, когда мы зарегистрируем API2 в каталоге2' Возможно, я изменил определение приложения после того, как он принял его в каталог2 изначально. 'нам нужно сначала войти в API1, чтобы создать принципал обслуживания API1 для арендатора Directory3.' Это проблема. Я думал, что смогу обойти это, указав свойство «knownClientApplications» в манифесте, но это не работает для приложений у разных арендаторов. Это эта функция, которая скоро будет выпущена? API2 использует API1 и отличается по-разному. – MvdD

+0

'в коде, который вы приобрели токен из Directory2. Мы должны приобрести токен у арендатора пользователей (Directory3). Конечно, это имеет смысл. 'вы приобретали токен, используя clientId, в этом secnario мы должны использовать ClientCredential' . Ах, это была ошибка. Выбрали неправильную перегрузку. – MvdD

+0

@MvdD Основываясь на моем понимании, эта функция, возможно, не будет выпущена. Поскольку, поскольку приложение принадлежит другому арендатору, обычно организация app1 не имеет доступа к обновлению 'knownClientApplications' app2. Конечно, если у вас есть идеи и отзывы о Azure AD, вы можете отправить их из [здесь] (https://feedback.azure.com/forums/34192--general-feedback). –

 Смежные вопросы

  • Нет связанных вопросов^_^