Назначение ролей пользователям приложений

как и во всех бизнес-приложениях, приложение может иметь несколько Users с Roles возложены на них. Недавно мы перешли на архитектуру WPF MVVM и ищем лучший способ назначить роль каждому зарегистрированному пользователю. Есть много терминов, плавающих по интернету, таких как аутентификация, RoleManager, LoginService и т. д., Но я не уверен, с чем работать.

вот что мы имеем:

приложение для малого бизнеса (с 20 форм), разработанных в рамках одного проекта. Мы используем MVVM архитектура LINQ-to-SQL как DataAccess и Model С Repository pattern и Unit Of Work.

что мы хотим:

существуют различные формы, и каждая форма имеет вставить, обновление, удалить, печати etc операции. Мы хотим ограничить пользователя в соответствии с его ролью - задачи он может выполнять. я.е, например, админ волен делать "что-нибудь " С приложением, в то время как некоторые другие пользователи не могут быть разрешены для просмотра некоторых форм или выполнения некоторых операций (а именно. обновить или удалить).

Итак, как мы можем этого достичь; какой сервис может быть использован для выполнения этого полного механизма с использованием архитектуры MVVM в настольном приложении LOB. Технический термин или учебник ссылка будет полезна.

Я надеюсь, что я понятно и большое спасибо в продвижение.

Edit: Я прошел через множество форумов и статей, но все они сосредоточены на ASP.NET - ... По-прежнему не удается найти конкретную реализацию для назначения ролей в WPF. И источники на ASP.NET не соответствует WPF.

7
c# mvvm user-roles wcf wpf

5 ответов

Я бы предложил построить решение вокруг ASP.NET членство & Управление Ролями поставщики (несмотря на редактирование исходного вопроса). Они хорошо документированы на MSDN и очень гибкие.

вот несколько ссылок, которые, надеюсь, помогут вам с интеграцией WPF:

кроме того, вы упомянули, что используете MVVM; я бы предложил иметь статический класс или иное глобально доступное свойство (см.:приложение WPF с использованием глобальной переменной) экземпляра класса централизованной авторизации. Методы этого класса могут быть вызваны из любой точки приложения (т. е. в ViewModels), чтобы включить / отключить или показать/скрыть соответствующие функции, основанные на любых разрешениях, которые были предоставлены пользователь.

4

посмотрите на блок приложений безопасности Microsoft. Я применил его к приложению, которое звучит несколько похоже на ваше. Разрешения могут храниться в Active Directory, SQL или даже в плоском файле.

http://msdn.microsoft.com/en-us/library/ff664771 (v=pandp.50).aspx

http://msdn.microsoft.com/en-us/library/ff664559 (v=pandp.50).aspx

3

Я бы создал статический класс на клиентском уровне, содержащий информацию о текущем пользователе (роли, разрешения и т. д.). Эти разрешения могут быть смоделированы, например, перечислением или чем-то подобным, затем в каждой ViewModel вы можете определить, какое из этих значений перечисления требуется, например, для выполнения запросов (просмотра записей) или выполнения команд сохранения или редактирования.

0

Я бы просто поместил свойство RequiredRole в каждую команду и добавил переопределение CanExecute, которое проверяет, что текущий пользователь имеет право это сделать. Этого достаточно для команд.

с другой стороны, права на отображение формы должны быть проверены в вашем проводнике экрана/вкладке host/...

извлеките роли и каждую роль suer с Linq to Sql, и все кончено. Я бы не стал утруждать себя интеграцией внешнего кода для такой простой задачи.

Если вы хотите сделать это более общий, храните в своей БД таблицу, связывающую команды / формы и роли, и используйте отражение для авторизации пользователей.

Я надеюсь, вы найдете это полезным

0

мы используем AD для определения ролей, к которым принадлежит пользователь. Затем проверьте, что любая из ролей имеет правильное разрешение. Однако вы можете использовать roles и userroles таблица чтобы сделать это частью себя.

используя любой из этих двух подходов пользователь будет в набор ролей. Это первый шаг.

затем вам нужно проверить в момент действия, что у пользователя есть разрешение. Наша структура меню создается динамически из базы данных, поэтому у меня есть таблица из MenuItems а затем таблица, определяющая RoleMenuAvailability.

первый элемент Id, an order на Title, Image source и navigation target, вместе с несколькими другими полями.

второй элемент RoleId и menuId и является ли он редактируемым. Таким образом, наличие строки означает ее читаемость (если навигационная целевая форма ie) Затем пункты меню считываются из базы данных:

var usersItems =
    items.Where(i => i.RoleMenuAvailabilities
                    .Any(r => domainUser.IsInDomainRole(r.UserRole.Description)))
         .OrderBy(m => m.MenuOrder);

UserRole.Description в нашем случае-это имя роли AD и IsInDomainRole является вспомогательной функцией:

public bool IsInDomainRole(string role)
{
    var regex = new Regex("[^\\]+$");
    string name = this.Name ?? string.Empty;
    string domainRole = regex.Replace(name, role);
    return this.IsInRole(domainRole);
}

на rolemenuavailability таблица может быть расширена, чтобы иметь дополнительные флаги на нем для удаления, обновления, добавления и т. д., Если требуется.

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

0