Как я могу определить политики для своего API для двух типов токенов доступа, один с идентификатором (sub) и один без?

Я использую IdentityServer4 через ASPNET Core и хочу, чтобы пользователи обращались к моему API как через веб-браузер через свои идентификационные данные (неявные и гибридные), так и со стороны клиентов программно (учетные данные клиента). Я понимаю, все, что мне нужно сделать, это добавить AddIdentityServerAuthentication и я сделал. Однако это решает только проблему аутентификации, а не авторизацию.

Авторизация:

В ASPNET Core вы можете использовать только аутентификацию на основе ролей (или аналогичные разрешения PolicyServer), но только если у вас есть удостоверение с утверждениями о роли, которое не работает для учетных данных клиента. Так что это приводит нас к необходимости обеспечения безопасности по ролям или политикам И по областям. Как я могу это сделать?

  • Вы не можете иметь несколько политик, если вы делаете, они оба должны пройти.
  • Вы не можете иметь несколько схем аутентификации, потому что мой вызов AddIdentityServerAuthentication Придется использовать те же полномочия, поэтому как IdentityServer4.AccessTokenValidation/JwtBearer узнает, какую схему вы бросаете вызов, которую пытаетесь пройти?
  • Могут работать несколько требований, но вам нужно добавить дополнительные требования при условии, что вы имеете дело с токеном без идентификации. Как определить тип токена, с которым вы имеете дело? Безопасно ли просто сказать: "Если нет саба, то это кредиты клиентов".
  • Должен ли я отказаться от этого дизайна и заставить поток кода устройства на моих пользователей? смотреть на az cli он волшебным образом открывает браузер, и тогда вы можете начать писать сценарии для вашего сердца. IS4 поддерживает это с легкостью, особенно с verficationUrlComplete

Я думаю, что у меня есть работающий POC, но я далек от этого. https://gist.github.com/VictorioBerra/8c333a228c55d86a7c15f7f300284634

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

1 ответ

Решение

Есть по крайней мере несколько способов решить проблему реализации аутентификации на основе ролей:

  • Возможно, вы неправильно поняли тот факт, что клиент может иметь role претензии в client_credentials течь.
  • Вы могли бы даже иметь sub заявить, если вы реализовали client_credentials_custom поток и по существу привязать клиента к определенной учетной записи пользователя (думать об этом как служебную учетную запись)
Другие вопросы по тегам