У меня есть вопрос, на который мне действительно кажется, что у меня должен быть простой ответ, но по той или иной причине я не смог полностью обдумать его.
Я приступаю к разработке приложения интрасети ASP.NET MVC3, и в настоящее время я работаю над проектированием аутентификации и авторизации. Мы вынуждены использовать базовую аутентификацию в нашей среде, и мы используем Active Directory, поэтому об авторизации обычно заботятся. К сожалению, наша иерархия ролей / пользователей в активном каталоге не отражает то, что мне нужно для ролей в приложении, поэтому мне придется определить свою собственную.
Я использую SQL Server, поэтому изначально я думал об использовании хранимых процедур для всех DML, а затем о создании ролей и добавлении пользователей в роли в SQL Server, а затем контролировал доступ к хранимым процедурам через эти роли. Я также думал, что могу запросить этих пользователей и роли уровня базы данных SQL Server, чтобы использовать их в качестве источника информации для авторизации в самом приложении. Первоначально это казалось отличной идеей, но она не кажется популярной (с одной стороны, кажется, что запросы на это немного длинные и беспорядочные для того, что они создают). В качестве альтернативы, было бы лучше, если бы веб-приложение олицетворяло пользователя для всех запросов к серверу, а затем реализовало базу данных пользователей / ролей с моей собственной схемой и авторизовывалось только на стороне приложения?
Первоначально казалось, что авторизация как на стороне приложения, так и на стороне базы данных будет хорошей вещью для безопасности, а использование объектов пользователя / роли SQL Server означает, что данные пользователя и роли не нужно хранить в двух местах.
Я действительно видел некоторые потенциально актуальные обсуждения на Лучшая практика для пользователей / ролей в SQL Server для веб-приложения, но я думаю, что в целом это другой вопрос.
Спасибо!
