Управление специальными ролями в ldap - PullRequest
2 голосов
/ 07 сентября 2010

У меня есть веб-приложение, настроенное на Spring Security, которое получает пользователей и роли из дерева ldap.

У меня есть dn ou = Пользователь, dc = приложение для пользователей и, для роли, ou = Группы, dc = приложение.

Каждая роль является записью во втором поддереве, и связь создается элементом атрибута в записи роли.

На самом деле у меня есть 5 разных ролей доступа (ROLE_A, ROLE_B, ROLE_C, ROLE_D, ROLE_E): каждая роль дает право доступа к определенному URL. Каждая роль независима.

Схема поддерева ролей (очень простая и неполная)

ou = Группы, dc = приложение. --cn = А --cn = В --cn = С --cn = D --cn = Е

Теперь мне нужно удовлетворить запрос на добавление 3 новых ролей (ROLE_F, ROLE_G, ROLE_H), которые могут быть назначены по фиксированной схеме: - ROLE_F может быть назначен, только если пользователь играет роль ROLE_B, ROLE_D, - ROLE_G может быть назначен, только если пользователь находится в роли ROLE_C или ROLE_E - ROLE_H может быть назначен, только если пользователь находится в роли ROLE_A или ROLE_B

Какая самая лучшая практика для управления этими 3 новыми ролями? Должен ли я считать их независимой и управляемой зависимостью в приложении или что еще?

Спасибо

1 Ответ

0 голосов
/ 07 сентября 2010

Есть ли какая-либо причина, по которой новым ролям, возможно, придется управлять как отдельными элементами, в том числе сейчас или, возможно, когда-нибудь в будущем, например, разрешения, предоставленные ROLE_F, не будут применяться к 100% сотрудников ROLE_B?Если это так, то я бы сказал, что ими следует управлять отдельно, даже если вы подозреваете, что когда-нибудь они могут потребоваться отдельно ... в конце концов, вы могли бы также приложить немного дополнительных усилий сейчас, чтобы избежать проблем в будущем.

Но если все, что вам действительно нужно сделать, это добавить новые разрешения (например, предоставленные ROLE_F) к существующим группам (ROLE_B в этом примере), то новые роли не нужны.

...