Добавить авторизацию в начале или конце производства?

Question

В процессе производства веб-сайта ASP.NET/C# для внутреннего использования, есть ли какие-либо преимущества для начала с аутентификации / авторизации / входа в систему ПЕРВЫЙ и создания оттуда?Или лучше просто создать свой сайт именно так, как вы хотите, с неограниченными ограничениями и без входов в систему или чего-то еще, а затем сделать это в конце производства, перед выпуском?Это то, что я ХОЧУ сделать - просто работать над функциональностью сайта, без ограничений, имея одну вещь, о которой нужно беспокоиться.Но я хочу убедиться, что этот подход не вызовет проблем позже.

Когда приходит время для реализации аутентификации ASP.NET, нужно просто запустить скрипт для генерации необходимых таблиц изатем с помощью WSAT для управления пользователями и затем предоставления ограничений для уже существующего контента ... должно быть ...

Answer 1

Вы должны заранее рассмотреть вопрос о безопасности. Даже если вы не разрабатываете окончательные экраны входа и не ограничиваете доступ по мере разработки, IMO, вы должны убедиться, что можете аутентифицировать своих пользователей и ограничить доступ хотя бы на одном экране, прежде чем приступить к разработке «режима бога». Включает в себя:

• Аутентификация - Windows, Forms и т. Д.
• Авторизация / Контроль доступа - будет ли Роль делать или вам нужна проверка на уровне операций - например, AzMan
• Если вы будете использовать SiteMap, вам нужно взглянуть на усечение безопасности, чтобы скрыть функции, к которым у пользователя нет доступа (меню, хлебные крошки и т. Д.)
• Аудит - например, изменения важных данных

Несмотря на то, что сайт предназначен для внутреннего использования, пользователям нельзя доверять, и вам также необходимо убедиться, что вы защищены от SQL-инъекций, XSS и т. Д.

Answer 2

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

Answer 3

Ваш подход может звучать быстрее, но он имеет архитектурные недостатки в следующих областях:

1 - Отсутствие выравнивания безопасности с вызовом на уровне страницы / метода.

2- Не ясно. Вариант использования и рабочий процесс с точки зрения аутентификации / авторизации.

3- Полное отсутствие тестирования на основе безопасности при постепенной разработке и добавлении новых функций.

4- Отсутствие сквозной зависимости. Что делать, если безопасность должна рассматриваться на разных уровнях, вы упустите весь взгляд на модульную зависимость и сквозное тестирование.

В целом, если вы сделаете это 1-ым, то вы можете просто установить один пример пользователя / pwd / role и использовать его для всех безопасных областей сайта, этого будет достаточно для непрерывного тестирования и разработки приложения.

Позже, когда ваше приложение будет готово; хорошо работать с большим количеством user / pwd и связанных ролей для работы.

Надеюсь, это поможет.