Где в стеке вызовов ролевые проверки должны быть сделаны?

Я бы поместил проверки доступа к ролям в бизнес-объекты, фактически выполняющие потенциально опасные / чувствительные вещи.

Добавление проверки ролей к событиям загрузки страницы и нажатия кнопок было бы лишним, ИМХО . Кроме того, если вы собираетесь защищать страницу, защитите страницу с помощью директив декларативного расположения в вашем web.config ... например, поместите все ваши «админские» страницы в отдельную папку и защитите всю папку декларативно.

Но вы всегда должны проверять как минимум методы бизнес-объекта.

You need to put it at the method level. You cannot assume that you reach that method in any specific way. That method can be called by the button handler or it can be called in normal code as the result of any type of logic. How many times have you seen something like this calling a button handler ...

private void MyBypassingCall()
{
  if( myLogic )
  {
    AddAccount_OnClick();
  }
}

So putting it on Page_Load is not enough. You should also check out decorating the method with a PrincipalPermissionAttribute. That cuts down on a lot of code.

Деловые объекты.

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

Edit: Более лаконично.

Это просто анекдотический комментарий о том, насколько важной может быть проверка безопасности на коммерческой стороне. В нашем случае этого было недостаточно, чтобы с оптимизмом смотреть на низкие ожидания взлома запросов. У нас не было никакой проверки наших бизнес-объектов, и мы неожиданно сгорели. Клиент создал скрипт для автоматизации использования нашего сайта. В итоге он перешел по ожидаемым ссылкам в их сценарии, которые на самом деле не были отображены. Это привело к повреждению данных. Конечно, для нас это скорее проблема состояния системы и целостности данных, чем нарушение безопасности, но я полагаю, что и то, и другое действительно применимо.

В нашем случае это достаточно хорошо, чтобы с оптимизмом смотреть на низкие ожидания взлома запросов. У нас не было никакой проверки наших бизнес-объектов, и мы неожиданно сгорели. Клиент создал скрипт для автоматизации использования нашего сайта. В итоге он перешел по ожидаемым ссылкам в их сценарии, которые на самом деле не были отображены. Это привело к повреждению данных. Конечно, для нас это скорее проблема состояния системы и целостности данных, чем нарушение безопасности, но я полагаю, что и то, и другое действительно применимо.

В нашем случае это достаточно хорошо, чтобы с оптимизмом смотреть на низкие ожидания взлома запросов. У нас не было никакой проверки наших бизнес-объектов, и мы неожиданно сгорели. Клиент создал скрипт для автоматизации использования нашего сайта. В итоге он перешел по ожидаемым ссылкам в их сценарии, которые на самом деле не были отображены. Это привело к повреждению данных. Конечно, для нас это скорее проблема состояния системы и целостности данных, чем нарушение безопасности, но я полагаю, что и то, и другое действительно применимо.

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

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

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