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