2016-10-27 8 views
0

Мне нужно добавить токен внутри токена для схемы «act-as» в пользовательском типе гранта в IdentityServer3. Я пробовал с PreserveAccessToken, но он просто добавляет токен в качестве претензии в текущем ClaimsPrincipal, но не может найти способ вложить его в качестве требования при получении другого токена для перехода к следующей службе/api в цепочке.IdentityServer3 - Добавить токен внутри токена для пользовательского типа гранта (act-as schema)

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

+0

Почему вы не создаете корреляциюId и вместо этого помещаете ее как часть некоторого заголовка? –

+0

Поскольку последнее звено в цепочке вызовов -an api, например, которое делает фактический вызов против БД и пытается записать аудит такой операции, должно затем иметь возможность извлечь стартер операции (например, конечный пользователь) и все сервисы/apis посередине, которые были частью операции. Если я могу заставить IdSrvr вставить токен внутри другого, тогда он должен разрешить все без дополнительной работы. – CesarD

ответ

1

Этого можно достичь с помощью специального гранта. Это позволяет расширить конечную точку маркера с помощью пользовательских «операций» - например, выдача маркера, который содержит делегированные заявки - например, токен.

документы здесь: https://identityserver.github.io/Documentation/docsv2/advanced/customGrantTypes.html

здесь также образец, который приближается к вашему сценарию: https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/Multi%20Hop%20Delegation%20(ActAsCustomGrant)

что сказал - это, пожалуй, самый дорогой способ передать идентификатор пользователя по нескольким хмелем.

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

+0

Да, я довольно долго экспериментировал с образцом Multi-hop. Моя проблема возникла при экспериментировании с 3-м API в цепочке вызовов, так как я проиграю первый, когда дойду до третьего, поскольку он отслеживает только предыдущего клиента. Моя забота о передаче данных о полезной нагрузке заключается в том, что я должен делегировать бизнес-логике Api ответственность, которая, как я полагаю, должна обрабатываться логикой авторизации/токена. – CesarD

+0

Возможно, то, что я пытаюсь достичь, связано с этим: https://tools.ietf.org/html/draft-hunt-oauth-chain-01 – CesarD

+0

Можно ли как-то использовать значения acr для достижения этого? – CesarD