Identity Server 4 и разрешения пользователя

Question

мы используем идентификационный сервер для предоставления доступа к apis.Все, что мы до сих пор использовали (или требовали), - это ClientCredentials (машина-машина), в которой пользователь не участвует.

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

Я много читал о типах грантов: неявном, коде авторизации, гибридном и т. Д., Но до сих пор не нашел четкого ответа о передовых методах.

Есть ли способ интеграции разрешений пользователей вaccess_token (это тоже хорошая идея?).AspNetIdentity уже интегрирован, и таблицы существуют в базе данных identityserver.

services.AddIdentity<User, IdentityRole>()
.AddEntityFrameworkStores<IdentityContext>()
.AddDefaultTokenProviders();

Как отправлять учетные данные клиента и учетные данные пользователя, чтобы наш сервер идентификации также мог собирать информацию о пользователе (разрешение, утверждения, роль и т. Д.)..)?

Любая помощь высоко ценится.

Спасибо

Answer 1

Вы путаете понятия здесь.Identity Server работает только с принципалами пользователя (в основном это просто набор утверждений, принадлежащих «пользователю»).Фактическое управление пользователями осуществляется из внешних источников, как правило, в Identity.Сама идентичность также основана на утверждениях, причем роли фактически являются просто типом утверждения.

Авторизация - это совсем другой зверь, и технически явно не включает в себя либо Identity, либо Identity Server, хотя они часто действуют какшлюз для указанного разрешения.Авторизация может быть основана на ролях, утверждениях или политиках в ASP.NET Core, а также существует технически независимая от инфраструктуры опция авторизации на уровне ресурсов.Однако в конечном итоге это все равно будет зависеть от одной из трех основных ролей: ролей, утверждений или политик.Он просто будет иметь дополнительный компонент специфичности для конкретного ресурса.Какой способ вы хотите авторизовать, зависит только от вас, и, конечно, вы можете смешивать и сопоставлять.

В конечном счете, вы просто будете устанавливать роли и / или утверждения для своего пользователя с помощью инструментов, предоставляемых Identity., который, конечно, будет сохранен для вас пользователь / хранилище ролей.Затем, когда аутентификация происходит через Identity Server или напрямую, будет создан ClaimsPrincipal и добавлен к HttpContext.Когда требуется авторизация, утверждения по этому принципу будут каким-то образом использоваться для определения, следует ли разрешить доступ или нет.Все просто.

Identity Server просто выступает в качестве поставщика централизованной аутентификации.Поскольку связь происходит по HTTP, на самом деле она будет возвращать JSON, в частности, JWT.Затем промежуточное программное обеспечение аутентификации ASP.NET Core, которое было бы настроено на использование Identity Server в качестве своего поставщика, просто расшифровывало JWT и создавало из него фактический ClaimsPrincipal экземпляр.Вам не нужно беспокоиться об этом, однако, после первоначальной реализации.После того, как все интегрировано, тот факт, что Identity Server был использован, практически не имеет значения.