2016-10-21 2 views
0

Мне нужно подключиться к внешнему API для проверки учетных данных пользователя и получить заявки для пользователя из моего пользовательского UserService в IdSrvr, но с использованием учетных данных клиента, как если бы IdentityServer был клиентом для подключения к другой службе ,Учетные данные клиента из UserService на IdentityServer3

Какой должен быть подход?

Первое, что мне кажется, это просто сделать экземпляр HttpClient в UserService для подключения к самому IdentityServer и сделать запрос ... Но я не знаю, есть ли лучший способ.

ответ

2

Способы расширения OwinEnviroment позволяют выдавать токены.

public MyCustomUserService(OwinEnvironmentService owin) 
    { 
     _owin = owin; 
    } 

    public async Task AuthenticateLocalAsync(LocalAuthenticationContext context) 
    { 

     var token = await _owin.Environment.IssueClientToken(
      clientId: "Banana", 
      scope: "resource1", 
      lifetime: 3600); 

     // call protected API with token 
    } 

Link to GitHub issue with same question

+0

Спасибо большое! Это работало как шарм! – CesarD

0

Существует грант для этого, называемый грантом ResourceOwner. Пожалуйста, прочтите соответственно spec.

Полномочия должны использоваться только тогда, когда существует высокая степень доверия между владельцем ресурса и клиентом (например, клиент является частью операционной системы устройства или высокопривилегированное
приложение)

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

+0

Может быть, я не объяснить себя достаточно хорошо: у меня есть сервис для аутентификации пользователей для моей организации и в основном RESTful API. Теперь изнутри UserService of IdentityServer мне нужно вызвать его для проверки пользователя в IdSrvr во время AuthenticateLocalAsync. Теперь мне нужно, чтобы IdSrvr выдавал себе токен для отправки вызова API аутентификации, а _that_ - это часть, которую я пытаюсь выяснить, что должно быть лучшим/чистым. Предоставление полномочий учетных записей ресурса подавляется, когда пользователь регистрируется в приложении, но это между службами (IdSrvr для auth api) – CesarD

+2

Этот вид напоминает мне об этом сообщении в IDS4. Честно говоря, я не знаю погоды, как это должно быть сделано. http://stackoverflow.com/questions/39981755/is-there-a-way-to-generate-an-access-token-from-within-identity-server-without-u Похоже, ваши пользователи доступны в другой веб-api, но это приложение является полагающейся стороной для поставщика удостоверений, требующих пользовательской информации. в основном вам нужен действительный токен из UserService. Честно говоря, я бы не был так уверен, что это чисто, но вы должны делать то, что должны делать. Я думаю, ваше решение будет в порядке. – Lutando

+0

Да, это очень похоже на вопрос, который вы опубликовали, и то, как вы объяснили. И да, это своего рода завихрение, но это auth api есть, потому что он должен захватывать пользователей из AD, а также из другой системы персонала и проверять пользователя как целого из обеих частей ... Только тогда учетные данные пользователя правильны подтвержденные и возвращенные претензии вместе с результатом проверки (если все в порядке) ... И не имеет смысла приводить всю эту логику в IdSrvr тоже. Я оставлю вопрос открытым для дальнейших отзывов. Спасибо за ваше. – CesarD

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