ASP.NET - система ручной проверки подлинности

Question

Мы разрабатываем приложение ASP.NET C#, которое будет содержать систему аутентификации, которая проверяет подлинность пользователей на нескольких уровнях (пользователь, администратор, супер-админ и т. Д.).

Наша идея НЕ использовать встроенную функцию аутентификации форм ASP.NET. Наш план состоит в том, чтобы создать для него целую «новую» систему - на основе объекта Session, а база данных SQL содержит информацию о пользователях, такую ​​как имя пользователя &.

Есть ли СЕРЬЕЗНАЯ разница между нашей идеей и функцией проверки форм?

Какие риски безопасности мы принимаем? Как мы их решаем?

Является ли это хорошей альтернативой функции аутентификации форм?

Answer 1

Мне было бы интересно узнать причину вашего отвращения к встроенным провайдерам членства.

Взгляните на эту ссылку. http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx В нем объясняется, как реализовать пользовательский MemberhipProvider, который вы можете использовать для аутентификации против любой существующей/запланированной базы данных/хранилища, независимо от того, является ли она сеансовой (не уверен, как это будет сохраняться) или в реляционной базе данных.

Ваше требование для суперпользователей и пользователей Admin и т. Д. Прекрасно вписывается в систему поставщиков ролей. Это очень легко использовать, и команда ASP.NET в Microsoft уже рассмотрела риски безопасности и способы их решения.

Есть чтение этих двух записей Blogg Скоттом Гатри:

http://weblogs.asp.net/scottgu/archive/2006/02/24/ASP.NET-2.0-Membership_2C00_-Roles_2C00_-Forms-Authentication_2C00_-and-Security-Resources-.aspx

http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx

Answer 2

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

Answer 3

Вы все еще можете иметь ASP.NET обрабатывать куки аутентификации и т.п. для вас. Если вы хотите использовать свой собственный db-материал, тогда все в порядке. Некоторые утверждают, что если он может вписаться в систему членства из ASP.NET, тогда сделайте это (через структуру провайдеров).

Если это не подходит, вы можете создать свои собственные формы входа, но я настоятельно рекомендую вам использовать cookie FormsAuthentication и управление сеансами как минимум. Его уже сделано, протестировано и у него есть собственный конфиг в файле web.config. Так зачем это делать снова?