Как крупные компании реализуют свои требования безопасности, которые централизованы и используются для управления тем, что люди могут делать (разрешено вызывать определенную веб-службу, отправлять заказ и т. Д.), А также для управления пользовательским интерфейсом (отключение кнопок, параметров меню, отдельных поля формы)?
Я рассматриваю архитектуру RBAC: Пользователи -> Роли, Роли -> Привилегии.
Сложные приложения с разрешениями, основанными на множестве отдельных field-account-user-role-amountThreshhold, будут иметь много-много «ролей», и управление этим усложняется по мере роста количества ролей.
Управление всеми этими возможными вариантами кажется сложной задачей, и мой предыдущий опыт заключался в том, чтобы жестко запрограммировать такую логику в приложении.
Ex: If (User.Roles("IsAccounting"))
{
btnEditOrder.enabled = false;
}
Мне поручено разработать / реализовать службу / архитектуру безопасности, которая будет использоваться в качестве общей точки аутентификации / авторизации для любых / всех приложений (все .NET, но некоторые графические интерфейсы и некоторые ориентированы на процессы).
Это невозможно по умолчанию из-за организации бизнеса вокруг клиентских учетных записей и уровней разрешений, основанных на финансовых суммах.
Пример: Джон является пользователем, и он может просматривать и отправлять запросы для учетных записей «Microsoft» и «Google». Майк может просматривать запросы Microsoft и Google, но может только отправлять запросы Google.
Количество учетных записей / пользователей большое и переменное.
Если я буду следовать RBAC, появятся сотни «ролей» для обеспечения всех необходимых прав (привилегий). Это не помогает, потому что конечная цель - предоставить простой в управлении инструмент с графическим интерфейсом, чтобы менеджеры могли назначать своих непосредственных подчиненных соответствующим ролям.
Я думал реализовать этот элемент безопасности с помощью следующего API (черновик в псевдокоде):
UserContext securityContext = Security.GetContext(userID, userPwd);
А использование в приложении будет таким: if (securityContext.RequestManager.CanSubmitRequest("Google")) {...}
Таким образом, были бы тысячи этих методов Can (params) для проверки разрешений, что затрудняет управление или использование этого шаблона.
Любые ссылки / идеи / указатели приветствуются.
Это магазин .NET, но ничто из того, что я видел в .NET (членство / AzMan), не даст нам требуемой детализации и требований к делегированию. Интеграция ActiveDirectory / Oracle LDAP была бы хороша, но не обязательна.
Старая (текущая) система использует LDAP для аутентификации пользователей, но вся авторизация выполняется внутри компании и хранится в классических таблицах «Пользователи, роли, права».
