Лучшие практики для заполнения токена доступа внешними утверждениями

Question

Мы реализовали IdSrv4 поверх AspNetCore Identity и используем ADFS в качестве внешнего IdP. От ADFS мы не хотим получать пользователям AD-группы, upn и некоторые другие претензии. Заявки будут использоваться как внутри нашей реализации IdSrv4, так и будут отправлены нашим API-ресурсам как часть токена доступа.

Текущая ситуация в нашей реализации IdSrv4:

• ADFS настроен таким образом, что он отправляет требуемые утверждения, и в нашей реализации IdSrv4 эти утверждения принимаются, как и ожидалось, в методе "ExternalLoginCallback" AccountController.
• IProfileService был реализован для заполнения Список «IssuedClaims» с претензиями.

НО, мне не удалось построить связь между этими шагами. Каков предпочтительный способ сохранить заявки, полученные в «ExternalLoginCallback», и поместить их в сгенерированный access_token в классе IProfileService?

Сейчас мне удалось получить , работающий , сохранив токен с помощью метода «UpdateExternalAuthenticationTokensAsyn c», который сохранит токен в базе данных. Затем в службе профилей я извлекаю токен и считываю утверждения в выданный токен.

Но это не так, и при поиске правильного способа я видел примеры, использующие класс IdentityServerUser, который имеет " "AdditionalClaims", но я не могу найти способ подключить этот тип к потоку событий. Кроме того, при настройке внешнего IdP у вас есть эти «ClaimActions», которые можно сопоставить, но я не понимаю, что это такое. Наконец, я предполагаю, что таблицы базы данных «IdentityClaims» и «ClientClaims» с соответствующими сущностями должны использоваться для этой цели, но я не могу понять, как. Или они должны быть сохранены в таблице «AspNetUserClaims», чтобы сохранить фактический тип / значения заявки, а не только сопоставления заявки?

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

Answer 1

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

Возвращаясь к этому после недели или около того Я сделаю еще один выстрел. Оказывается, что введенный DI «_userManager» не был «подключен» к текущему вводимому DI «_signInManager». Если у кого-то есть объяснение этому, пожалуйста, поделитесь!

Что сработало, так это использование "_signInManager.UserManager" для обновления утверждений пользователя. Это правильно сохраняет утверждения в таблице «AspNetUserClaims», а затем может быть получено в службе профилей.

ОБНОВЛЕНИЕ 1: Конечно, на это тоже был логичный ответ. Диспетчер пользователей создается по умолчанию, даже если вы не вызываете «AddUserManager» в настройках вашей личности во время запуска. НО, в моем случае я расширил класс IdentityUser, и теперь, делая это так, все работает как положено (где «UserIdentity» - мой производный класс):

.AddIdentity<TUserIdentity, TUserIdentityRole>(options =>
            {
                options.User.RequireUniqueEmail = true;
            })
            .AddEntityFrameworkStores<TIdentityDbContext>()
            .AddSignInManager<SignInManager<UserIdentity>>()
            .AddUserManager<UserManager<UserIdentity>>()
            .AddDefaultTokenProviders();