Получение действительного токена на предъявителя для приложения от углового клиента AD

Question

Я следовал этому руководству:

https://github.com/Azure-Samples/active-directory-angularjs-singlepageapp

, и я успешно подключился.Я хотел бы отправить токен-носитель на мой сервер C # и использовать его для вызова функций своего рабочего места (другого приложения AD).

Я пытаюсь использовать токен-носитель, полученный из angular при вызове почтальона, и онне авторизован.Важно отметить, что я дал своему угловому клиенту на AD разрешение на доступ к своему экземпляру рабочей среды, и он все еще не работает, что приводит меня к некоторым вопросам:

Я пытался использовать клиент .NET из этого руководства:

http://blog.pomiager.com/post/using-rest-api-in-azure-workbench-blockchain

и все работает.Здесь я замечаю, что в объекте AuthenticationContext он получает учетные данные, которые используют идентификатор клиента и секрет клиента.Я заметил, что в примере с угловым AD мы никогда не используем секрет.Но дело в том, что, глядя на руководство по созданию собственного пользовательского интерфейса рабочей среды в файле authService.js, он никогда не принимает секрет в качестве параметра.Как можно увидеть здесь:

https://github.com/Azure-Samples/blockchain/blob/master/blockchain-development-kit/connect/web/workbench/custom-ux-sample/src/services/authService.js

Я понимаю, что эти учетные данные должны быть установлены на сервере.В приведенном мною примере angular есть также сервер ASP.NET

Как я могу создать действительный токен-носитель для рабочего места из примера angularJS AD?Должен ли я заменить OWIN lib чем-то другим?

Спасибо

Answer 1

У вас есть два варианта:

1. OPTION1 - Вызов API Workbench напрямую из SPA на основе AngularJS

   В этом варианте вы работаете с Неявный поток предоставления и вызовите API-интерфейс Workbench только через Delegated Permissions, т. Е. В контексте зарегистрированного пользователя.

   Также следует знать, что сам AngularJS SPA не должен использовать какие-либо секреты клиента, поскольку это представляет угрозу безопасности, и любой, кто использует ваше приложение, может извлечь секрет из кода JavaScript.

   Вотпример кода из образцов Azure.В этом примере есть TodoSPA (ваше приложение AngularJS) и ToGoAPI (отдельный API, аналогичный API WorkBench).Поэтому вам не нужно размещать ToGoAPI самостоятельно, но предполагайте, что WorkBench API - это ваш ToGoAPI.Выполните те же действия, только имя разрешения «Access To Go API» будет другим, вместо этого вы будете использовать Access Work Bench API.

   Вызовите веб-API, защищенный Azure AD, в одностраничном приложении AngularJS

   

   Важные фрагменты кода -

   В App\Scripts\app.js замените имя свойства объекта конечных точек на новое местоположение вашегоTo Go API, который в вашем случае будет api url Workbench.В App \ Scripts \ toGoListSvc.js замените переменную apiEndpoint тем же значением.

2. OPTION2 - создайте внутренний API, который поддерживает SPA на основе AngularJS

   AngularJS SPA вызывает этот API на основе внутреннего сервера, который затем вызывает API Workbench.

   В этой опции вы можете использовать клиентские секреты и работать как с Delegated permissions, так и с Application Permissions.

   Эта опция нужна вам, только если вам нужно работать с разрешением Administrator, показанным на снимке экрана для API Workbench, показанного выше.

   С точки зрения потока вы можете напрямую использовать Client CredentialsПредоставьте поток из API бэкенда, если вам не нужно вызывать Workbench с контекстом пользователя.В случае, если вам нужно позвонить в контексте пользователя, используйте От имени потока .

---

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