У меня есть приложение, которое использует Identity Server 4 и open id connect для аутентификации и авторизации.Сейчас я обсуждаю с системным архитектором, который хочет внести несколько изменений, когда дело доходит до обработки прав пользователя.В этом приложении пользователь может быть частью одного или нескольких регионов, а в этом регионе пользователь может быть частью одного или нескольких клиентов.Эти пользователи имеют как региональные роли, так и роли клиентов.В каждом регионе пользователь может (в худшем случае, но очень вероятных сценариях) быть частью более 150 клиентов с разными ролями в каждом, что может привести к примерно 2500 разрешениям.
Когда пользователь просматривает приложение, он выбирает разные регионы и клиентов, которые пользователь просматривает в данный момент.Это означает, что пользователь имеет разные разрешения в пределах ресурса в зависимости от того, в каком регионе / клиенте он в данный момент работает.Мой системный архитектор предлагает, чтобы эти разрешения были сохранены в маркере доступа, отправляемом ресурсу, чтобы ресурс проверял, разрешено ли пользователю выполнять это действие для указанного региона / клиента, и что эти заявки на разрешения должны обновляться, когдапользователь меняет регион и / или клиента.Меня беспокоит то, что эти разрешения кажутся слишком динамичными, чтобы их можно было обрабатывать внутри токена доступа, так как они могут меняться несколько раз во время сеанса пользователя в приложении,
Прежде всего, возможно ли даже определить идентичностьна сервере, который «пользователь А только что выбрал этот регион / клиента, обновите все утверждения в токене, чтобы он соответствовал этому региону / клиенту», и если да, то как бы мне передать информацию о выбранном в данный момент регионе и клиенте службе профилей/ конечная точка информации пользователя (без необходимости моделировать каждый регион / клиента в качестве настраиваемой заявки)?
Во-вторых, меня беспокоит то, что это слишком динамично, чтобы хранить его в токене, поскольку это БУДЕТ изменяться многократнопользовательский сеанс.Поскольку пользователь входит в само приложение, а не в каждый регион и клиента, я предложил поместить эту логику в API / ресурс, чтобы при получении определенного запроса к API мы проверяли нашу базу данных разрешений или кэшТакже посмотрите, выполняется ли действие, которое пользователь выполняет для региона, а для клиента это действие.Насколько я понимаю, OpenID Connect и OAuth на самом деле не должны использоваться таким образом, что он предлагает, но я могу быть очень неправ?
Я прочитал эту статью по наименьшей привилегии ,которая, кажется, решает те же проблемы, о которых я говорил, но мой системный архитектор, похоже, не был в этом убежден ..