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