С учетом ASP. NET Core 3.1 проекта webapi, в котором размещается IdentityServer, генерирующий токены; У нас также есть кластер серверных микросервисов со шлюзом впереди (Ocelot). Шлюз проверяет токен. Это чисто аутентификация, а не авторизация.
Поскольку мы являемся мультитенантным приложением, в котором каждый арендатор может иметь несколько отделов и назначать пользователей отделам с определенными ролями / разрешениями и т. Д. c, оно может получить довольно сложный. Сначала мы попытались сохранить все разрешения / роли для пользователя в утверждениях. Но это требует от нас перечисления ВСЕХ разрешений для назначенной роли в утверждениях, что приводит к тому, что утверждения слишком велики.
Следовательно, мы думаем сделать внешнюю проверку запрошенного разрешения, где наш шлюз / microservice вызывает конечную точку на нашем сервере идентификации и проверяет, есть ли у данного пользователя необходимые разрешения. Есть два (или более) подхода к этому; - Во-первых, мы думаем о предоставлении конечной точки, которая предоставляет ВСЕ роли + разрешения + арендаторы + отделы, к которым у этого пользователя есть доступ. Если у арендатора есть свои роли с разрешениями, он также будет возвращен. Это будет кэшироваться в Redis на вызывающей стороне (шлюзе), чтобы не слишком часто вызывать эту внешнюю службу (ну, redis также является внешней ..) слишком много. Затем мы можем, используя наши существующие политики авторизации, легко проверить доступ, который имеет пользователь. Во-вторых, мы можем просто написать промежуточное программное обеспечение / новый обработчик аутентификации, который для данного разрешения, пользователь, отдел и арендатор, вызывает API сервера идентификации, который в основном возвращает хорошо или не хорошо Это также может быть кэшировано.
Единственное, чего я немного боюсь, это добавленной задержки при каждом HTTP-запросе, потому что вдруг вы вызываете внешнюю службу ... И затем, если это будет Лучше всего положить в промежуточное ПО, пользовательский обработчик аутентификации, ...
Спасибо!