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