RBAC - это не RBAC, это не RBAC, а RBAC на бумаге сложно, но практически невозможно реализовать в реальной жизни.
У каждого есть своя «идея» RBAC, и большинство использует разные термины для каждой вещи, связанной с RBAC. Как правило, с точки зрения реализации LDAP у вас редко есть все «части частей» для правильной реализации в LDAP.
"Части частей" в простых терминах:
S = Тема = Человек или автоматизированный агент или Пользователи
P = Разрешения = Утверждение режима доступа к целевому ресурсу
T = Target Resources = Объект, которому вы хотите назначить разрешения
Роль, как минимум, должна связывать разрешение и пользователя.
Целевой ресурс может полностью находиться за пределами LDAP. Таким образом, это может быть приложение на сервере Tomcat или просто право читать «другие» записи на сервере LDAP.
Поэтому, как правило, лучшее, что вы будете делать в LDAP, - это настроить объект со списком пользователей, и, если в LDAP есть какие-то ресурсы, назначьте соответствующие разрешения для каталогов для этих целевых ресурсов.
Тогда есть небольшая проблема реализации.
Теперь нам нужна Политика для реализации нашей роли. Поэтому наша роль, которую мы будем называть «только для чтения», бесполезна без политики ее использования.
В нашем случае мы могли бы просто сказать, что Роль ТОЛЬКО ДЛЯ ПОЛЬЗОВАТЕЛЯ может читать что угодно в нашей Организации.
Итак, теперь у нас есть Политика. Где хранится эта политика? Цифровое представление Политики хранится в «Точке информации о Политике» или PIP.
Как мы интерпретируем Политику, предоставляемую из ПГИ? Политики интерпретируются точкой принятия решения о политике (PDP).
Кто решает, может ли субъект (пользователь) получить доступ к ресурсу? Точки исполнения политики (PEP).
Собрав все эти элементы политики вместе, мы получаем цифровое представление Политики, которое предоставляется Информационной точкой политики в Точку принятия решения политики, которая затем передает решение в Точку применения политики, где доступ разрешен или запрещен.
Итак, в нашей истории RBAC, где PIP, PDP и PEP?
Хорошо, если целевой ресурс находится в каталоге LDAP, то именно каталог LDAP является PIP (который мы, вероятно, жестко закодировали и не абстрагировали, PIP также и PEP тоже, и это было легко.
Но если это наше приложение Tomcat, это ДОЛЖЕН быть метод в приложении Tomcat, который может прерывать, знает, должен использовать метод, чтобы сказать: «У меня есть этот субъект (пользователь), и он хочет получить доступ к этому целевому ресурсу (инвентаризации) для выполнить это разрешение (ТОЛЬКО ДЛЯ ЧТЕНИЯ) ".
Конечно, есть некоторые стандарты для всего этого. (Google XAML, RFC3198, ISO10181-3, NIST), но они являются стандартами с большими пробелами для практической реализации.
Так что имейте в виду, РЕАЛЬНЫЕ реализации RBAC трудны.
Конечно, ИМХО, мы должны знать о RBAC, изучить документы и сделать это стратегическим направлением, но реальная реализация для широкого круга поставщиков и приложений, ну, мы просто еще не там.
-Джит