Реализация RBAC с использованием okta

В настоящее время наше приложение для весенней загрузки использует okta для входа в систему. Для приложения необходимо реализовать RBAC, поэтому я пытался понять, смогу ли я использовать саму okta для сопоставления пользователей с конкретными ролями.

Я хотел бы реализовать стандартную модель RBAC, в которой я бы сопоставил несколько разрешений в рамках роли, а роли были бы связаны с пользователями. В основном это включает 3 уровня разрешений ›роли› пользователи.

Но в okta я не вижу стандартного способа сопоставления ролей и разрешений. RBAC достигается путем создания групп и привязки групп к пользователям, что является двухуровневым. И группы должны быть добавлены в качестве настраиваемого утверждения.

Как мне достичь стандартного сопоставления RBAC (разрешения ›роли› пользователи) в okta или что-то, что нужно обрабатывать вне провайдера IDP.

Заранее спасибо.


spring-boot rbac openid-connect okta idp
person Sunny    schedule 23.09.2020    source источник
comment
Okta позволяет объединять пользователей в группы и фильтровать по ним, используя что-то вроде @PreAuthorize (в Spring: developer.okta.com/blog/2019/06/20/spring-preauthorize). Я не думаю, что есть способ структурировать вложенные группы, как вы просите. Для этого вам, возможно, придется написать собственный код.   -  person Matt Raible    schedule 23.09.2020

Ответы (2)


arrow_upward
0
arrow_downward

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

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

Если вы заинтересованы в этом шаблоне, посмотрите эти мои ресурсы:

person Gary Archer    schedule 26.09.2020

arrow_upward
0
arrow_downward

Возможное решение:

Вы можете сделать области (scp в токене доступа) вашими разрешениями. Ниже приведены шаги:

  1. На своем сервере авторизации создайте свои настраиваемые области (разрешения) и установите их как области по умолчанию (это необходимо). Например, создайте 2 области действия по умолчанию:
books.read (default=true)
books.write (default=true)

  1. Перейдите к политикам доступа на вашем сервере авторизации, создайте одну, если она не определена.

  2. Создайте правила политики доступа на странице политик доступа, правила будут вашим сопоставлением между группами и областями.

  3. Проверьте, что на вкладке предварительного просмотра токена хитрость заключается в том, чтобы оставить поле scopes пустым, чтобы сервер авторизации мог возвращать области по умолчанию, которые установлены для пользователя, как объяснил Okta:

Область по умолчанию будет возвращена в токене доступа, когда клиент опускает параметр области в запросе токена, при условии, что эта область разрешена как часть правила политики доступа.

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

  2. В зависимости от библиотеки, которую вы используете, вы можете столкнуться с некоторыми проблемами, если по умолчанию они ожидают, что id_token всегда будет возвращаться, но вы, вероятно, сможете его настроить. Например: https://github.com/okta/okta-auth-js/issues/827

Ограничения решения:

Как упоминалось в шагах 4 и 5, мы опускаем параметр запроса области, это означает, что будут возвращены только наши настраиваемые области, назначенные для пользователя или его групп, поскольку базовые области, которые предопределены Okta, такие как profile, openid, email. .. не возвращается. Это также означает, что мы пропускаем OIDC, которому нужна область openid, поэтому id_token не будет возвращен, а вернется только access_token. Таким образом, это решение предполагает, что вам не нужны никакие базовые области, предопределенные Okta.

Если вам нужен какой-либо из базовых прицелов

Как описано в ограничениях, решение предполагает, что вам не нужны никакие базовые области действия, предопределенные Okta. Но если вы это сделаете, то ниже представлено решение, которое работает в этом случае, но не так хорошо.

При запросе кода авторизации в потоке oauth нужно отправить запрос дважды

первый: опустить параметр запроса области, поэтому возвращаются области по умолчанию.

второй: добавьте области, возвращенные из первого запроса, в список необходимых вам базовых областей, например openid, profile, 'email'. Итак, вы бы отправили что-то вроде (уже закодировано)

?scope=books.read%20books.write%20openid%20profile%20email

Заявление об ограничении ответственности:
Приведенное выше решение не рекомендуется, но оно работает. Если кто-то может найти какие-либо проблемы с безопасностью с помощью вышеуказанного решения, оставьте это в комментариях.

person Said Saifi    schedule 20.06.2021