RBAC не RBAC не RBAC и RBAC на бумаге трудно, но практически невозможно реализовать в реальной жизни.
У каждого есть своя «идея» RBAC, и большинство из них использует разные термины для каждой вещи, связанной с RBAC. Как правило, с точки зрения реализации LDAP у вас редко есть все «части частей» для правильной реализации в LDAP.
«кусочки частей» в простых условиях являются:
S = Subject = Человек или автоматизированный агент или пользователей
P = Права = Одобрение режима доступа к целевой ресурс
T = Целевые ресурсы = Объект, которому вы хотите назначить разрешения
Роль, как минимум, должна связывать разрешение и пользователя. Целевой ресурс может быть полностью за пределами LDAP. Таким образом, это может быть приложение на сервере Tomcat или просто право читать «другие» записи на сервере LDAP.
Как правило, самое лучшее, что вы будете делать в LDAP, - это настроить объект, который имеет список пользователей, и если есть какие-то ресурсы, находящиеся в LDAP, назначьте правильные разрешения для этих целевых ресурсов.
Тогда возникает небольшая проблема.
Теперь нам нужна Политика для реализации нашей Роли. Таким образом, наша роль, мы будем называть ее USER-READ-ONLY, не полезна без политики о том, как ее использовать.
В нашем случае мы могли бы просто сказать, что ТОЛЬКО ПОЛЬЗОВАТЕЛЬская роль может читать что-либо в нашей Организации.
Итак, теперь у нас есть политика. Где хранится эта политика? Цифровое представление политики хранится в «Информационной точке политики» или PIP.
Как мы интерпретируем Политику, поставляемую из PIP? Политики интерпретируются точкой принятия решений в отношении политики (PDP).
Кто решает, может ли субъект (пользователь) получить доступ к ресурсу? Очки соблюдения политики (PEP).
Объединение всех этих политик вместе в конечном итоге с цифровым представлением Политики обеспечивается Информационной точкой политики в точке принятия решения о политике, которая затем принимает решение в точке применения политики, где доступ разрешен или запрещен.
Итак, в нашей истории RBAC, где PIP, PDP и PEP? Ну, если целевой ресурс находится в каталоге LDAP, то это каталог LDAP, который является PIP (который мы, вероятно, жестко запрограммировали и не абстрагировали, PIP также и PEP тоже, и это было легко.
Но если это наше приложение Tomcat, оно ДОЛЖНО быть методом внутри приложения Tomcat, которое может прерывать, должно использовать метод, чтобы сказать «у меня есть этот вопрос (пользователь), и он хочет получить доступ к этому целевому ресурсу (инвентарю) для выполнения этого разрешения (READ-ONLY)».
Конечно, есть некоторые стандарты для всего этого материала. (Google XAML, RFC3198, ISO10181-3, NIST), но они являются стандарты с широкими зазорами для практической реализации.
Так что имейте в виду, что РЕАЛЬНЫЕ реализации RBAC сложны.
Уверенный ИМХО, мы должны знать о RBAC, изучать документы и делать это стратегическим направлением, но реальную реализацию жизни на широкой основе поставщиков и приложений, ну, мы просто пока не там.
-Джим
Любопытный - почему нисходящий звук без комментариев? Это, казалось, был актуальным вопросом, когда я спросил его три года назад ... Особенно для проекта, над которым я работал в то время. –
Как OP, я вижу, что это дубликат [Реализация безопасности на основе ролей в LDAP] (http://stackoverflow.com/questions/8020237/role-based-security-implementation-in-ldap), которая на самом деле имеет некоторые полезные рекомендации. –
И в последнем обновлении: я считаю, что управление доступом на основе утверждений на .Net является хорошим механизмом, и ADFS представляется разумно способным в качестве механизма маршалинга претензий из базы данных приложений в структуру аутентификации/авторизации. –