Доброго времени суток всем.

У меня возникла необходимость реализовать примерно такое: безопасный вызов методов в приложении в зависимости от того, как пользователь авторизовался.
То есть: есть БД, где хранятся данные о пользователях, ролях, разрешениях ().

Есть приложение, которое при старте вызывает форму авторизации — просит ввести логин и пароль. После ввода данных выполняется проверка и, если пользователь не найден в БД, выводится ошибка, в ином случае загружается приложение дальше.
Вот тут и начинается самый интерес. Приложение должно загрузить и отобразить нужные контролы, дать возможность вызывать методы, в зависимости от того какой пользователь вошел. То есть, как пример, если администратор, то должно быть доступно все, если пользователь, то частично.
Названия ролей берутся из БД, могут меняться, как и правила.
Также должна быть возможность из-под пользователей с ролью "администратора" редактировать список пользователей, добавляя, удаляя новых, создавая/удаляя правила и связывание правил с пользователями/ролями, указывая доступность функционала приложения конкретному пользователю или ролям.

Подскажите как можно реализовать данное, от чего отталкиваться, есть ли какие-то стандартные подходы.
Разработка приложения — на С#.

Здравствуйте, RW, Вы писали:

RW>Приложение должно загрузить и отобразить нужные контролы, дать возможность вызывать методы, в зависимости от того какой пользователь вошел

Результатом авторизации пользователя будет какой-то контекст, в котором будут хранится роли и разрешения текущего пользователя.

Для "отображения нужных контролов" нужно построить модель (представления) на основе контекста, применимую к конкретному представлению — т.е. какой-то класс вида:

public class OrderEditorSecurityViewModel
{
  property Boolean IsSaveCommandEnabled { /* ... */ }
  property Boolean IsCustomerSelectorEnabled {  /* ... */ }
  
  // ...
}

и затем связать экземпляр этого класса с нужными свойствами контролов. Конкретные детали реализации будут зависеть от GUI-фреймворка, которым вы воспользуетесь.

С "методами" сложнее.
Если у вас клиент-сервер, то управления доступностью/видимостью контролов будет достаточно — сделали кнопку disabled, и уже ее обработчик не сработает -> "метод" не выполнится.
Если у вас есть app server, то, по-хорошему, нужно обеспечить разграничение доступа на уровне вызова серверных методов, иначе любой клиент, написанный не вами, сможет делать все, что заблагорассудится. Т.е. в базе хранить разрешения на вызов методов, а при обращении к серверу передавать credentials пользователя, получать контекст с разрешениями и принимать решение — можно или нельзя.

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, RW, Вы писали:

RW>>Приложение должно загрузить и отобразить нужные контролы, дать возможность вызывать методы, в зависимости от того какой пользователь вошел

HL>Результатом авторизации пользователя будет какой-то контекст, в котором будут хранится роли и разрешения текущего пользователя.

HL>Для "отображения нужных контролов" нужно построить модель (представления) на основе контекста, применимую к конкретному представлению — т.е. какой-то класс вида:
HL>

HL>public class OrderEditorSecurityViewModel
HL>{
HL>  property Boolean IsSaveCommandEnabled { /* ... */ }
HL>  property Boolean IsCustomerSelectorEnabled {  /* ... */ }
  
HL>  // ...
HL>}
HL>

HL>и затем связать экземпляр этого класса с нужными свойствами контролов. Конкретные детали реализации будут зависеть от GUI-фреймворка, которым вы воспользуетесь.

HL>С "методами" сложнее.
HL>Если у вас клиент-сервер, то управления доступностью/видимостью контролов будет достаточно — сделали кнопку disabled, и уже ее обработчик не сработает -> "метод" не выполнится.
HL>Если у вас есть app server, то, по-хорошему, нужно обеспечить разграничение доступа на уровне вызова серверных методов, иначе любой клиент, написанный не вами, сможет делать все, что заблагорассудится. Т.е. в базе хранить разрешения на вызов методов, а при обращении к серверу передавать credentials пользователя, получать контекст с разрешениями и принимать решение — можно или нельзя.

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

да, у меня клиент-сервер, но я занимаюсь в данный момент клиентской стороной, но в итоге проверки будут и там, и там. Просто сейчас задача разобраться с клиентом)

а есть ли какой-то подход, для защиты именно методов. что-то подобное вот этому http://msdn.microsoft.com/en-US/library/dswfd229(v=VS.80).aspx
только с такими возможностями, чтобы из самого же приложения потом изменять, назначать разрешения, роли. и Роли, разрешения брать из своей базы.

Здравствуйте, RW, Вы писали:

RW>То есть имеется в виду, что после успешной авторизации клиенту будет отправлена модель представления, так?
После успешной авторизации у вас будет контекст c ролями текущего пользователя и действующими разрешения для этих ролей. Например:

User:
  Role: Sales manager
  Objects:
    Object: Order
      Permissions:
        Create: True
        View: True
        Edit: True
        Delete: False
...

Ваше клиентское приложение будет показывать какие-то представления. На представлениях размещаются контролы.
Разграничение доступа со стороны GUI — это enable/disable и visible/invisible для контролов.
Например, есть представление, в котором редактируется заказ ("Order"). В нем есть кнопка "Save".

Нужно взять контекст и применить его к конкретному представлению.
Т. е. в примере, перед тем, как показать редактор заказов, взять разрешение "Edit" для объектов типа "Order" и связать его со свойством "IsEnabled" у кнопки "Save".

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

RW>да, у меня клиент-сервер, но я занимаюсь в данный момент клиентской стороной, но в итоге проверки будут и там, и там
"И там, и там" — это где?
Под "клиент-сервером" я имел ввиду простой случай: толстый клиент со всей бизнес-логикой + СУБД.

RW>а есть ли какой-то подход, для защиты именно методов
Не совсем понятно, от чего вы защищаетесь.
Если у юзера нет возможности нажать на кнопку, как он выполнит "метод"?