Как я должен сделать аутентификацию в сайте MVC ASP.NET?
У меня есть сайт, который имеет область, которая требует аутентификации. Прямо сейчас я использую ролевой атрибут на всех контроллерах в той области, и я выполняю запрос для получения того пользовательского идентификатора и всех их настроек.
На код или запах дизайна мне кажется, что я получаю идентификатор пользователя и настройки каждый раз контроллер в той области загрузки? Я не уверен, должен ли я использовать сессии, или если ASP.Net MVC 2.0 обеспечивает некоторый уникальный способ обработать это. Другое беспокойство является безопасностью.
В целом, я действительно не знаю который способ повернуться. Разработайте мудрый, я хотел бы идентификатор пользователя, и настройки получили только однажды, когда пользователь входит в область. Прямо сейчас я захватываю идентификатор пользователя каждый раз, когда контроллер загружается, и затем при необходимости, я запрашиваю базу данных для их настроек каждый раз также.
6 ответов
Одно из правил безопасности гласит: не пытайтесь сделать это самостоятельно. Есть много подводных камней в том, как правильно сделать систему аутентификации, не оставив лазеек или черных ходов. В связи с этим можно рассмотреть SqlMembershipProvider, который поставляется вместе с .NET. Он может использоваться в MVC и предоставляет средства для получения ролей и текущего контекста безопасности, прост в установке и настройке и будет более безопасным, чем создание собственной системы.
Если вы не используете SQL Server, у вас есть несколько вариантов. Одним из решений будет использование чего-то вроде SQL Server Express или SQL Server Compact Edition для поддержания учетных данных. Другим решением может быть имитация схемы базы данных SqlMembrershipProvider, а затем написание собственного провайдера, который взаимодействует с этой схемой.
Последним вариантом может быть написание собственного класса MembershipProvider. Несмотря на то, что это все равно будет ваш собственный провайдер, он заставляет вас вникнуть в структуру MembershipProvider, чтобы вы могли позже заменить его на другой (например, ActiveDirectoryMembershipProvider) и предоставляет общий интерфейс для взаимодействия с учетными данными и логинами, что, например, позволяет легко использовать встроенный элемент управления Login.
Если вы уже используете MembershipProvider и задаетесь вопросом о хранении дополнительных пользовательских данных, то я бы предложил SqlProfileProvider со всеми оговорками, которые я упомянул выше о SqlMembershipProvider. ProfileProvider обеспечивает структуру для хранения пользовательских данных с текущим вошедшим пользователем.
Дополнительная информация:
Вы также можете реализовать собственный идентификатор. Их очень легко реализовать, и они позволяют вам хранить любую информацию о пользователе, которую вы хотите, в Identity, которая затем сохраняется в файлах cookie, которые устанавливает Identity, поэтому вы не обращаетесь к БД каждый раз, чтобы получить эту информацию.
Просто создайте новый класс, унаследованный от GenericIdentity, и все будет в порядке.
Вы, конечно, должны быть осторожны с тем, сколько информации вы помещаете туда, поскольку она находится в файле cookie, но обычно информация, относящаяся к пользователю, в случае, о котором вы здесь говорите, не так уж и велика.
Мы используем индивидуальный идентификатор для хранения некоторой информации о пользователе, и это работает очень хорошо.
В сеансе можно сохранить объект, который содержит всю необходимую информацию о пользователе. Вам просто нужно будет добавить свойство в Controllers, Views или другие базовые классы, где вы хотите получить информацию / профиль пользователя. Это будет информация об авторизации, а не любая информация для проверки подлинности (например, проверка подлинности с помощью форм)
Вы можете попробовать "Windows Identity Foundation". Я использовал его в одном из своих проектов в течение некоторого времени. Она позволяет "аутентификацию на основе утверждений", что в основном означает, что вы можете назначать "утверждения", строки информации, которые описывают пользователя, когда он входит в систему.
После входа в систему утверждения пользователя могут быть считаны из поля HttpContext.Current.User. Вы также можете использовать утверждения "Role", которые легко интегрируются со схемой аутентификации на основе ролей; это означает, что вы можете дать пользователю утверждение роли "менеджер", а затем использовать `if (User.IsInRole("manager")).
В качестве дополнительного бонуса, WIF позволяет очень легко повторно использовать экран входа в систему в других приложениях.
В целом, это очень гибкий инструмент, но документация очень плохая. Я задал и ответил на ряд вопросов о "Windows Identity Foundation" на StackOverflow.
Мы делали это довольно много раз в прошлом. Подобно тому, о чем упоминает Томас, мы обычно реализовывали новый провайдер Membership на основе провайдера Microsoft SQL Memberhsip. Мы наследуем от базового класса MembershipUser и добавляем любые пользовательские свойства, которые мы хотели бы иметь у объекта пользователя. Вы должны реализовать чтение базы данных для провайдера Membership в реализации GetUser, поэтому вы можете консолидировать дополнительные свойства, которые вам нужны, в этом чтении базы данных.
Если вы используете SQL-сервер, Microsoft выпустила код 2.0 для него. Вы можете получить больше информации в блоге Скотта Гу.
http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx
Если вы хотите начать с нуля, у них также есть хорошие ресурсы на MSDN.
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
и
http://msdn.microsoft.com/en-us/library/6tc47t75.aspx
После того, как вы реализовали свой провайдер, вы можете добавить пользователя Membership в коллекцию Items текущего веб-контекста, чтобы получить к нему доступ из вашего кода. Нерасширенные свойства базового класса пользователя также доступны в потоке Request, как обычно.
С выпуском компанией Microsoft версии исходного кода 2.0 мы обнаружили, что это помогло нам снять некоторые опасения, связанные с повторным изобретением. Еще одна вещь, которую следует учитывать при реализации, - это то, что, исходя из вашего сценария, вы можете обойтись без реализации некоторого кода. Примером может быть код CreateUser, если вы обращаетесь к конечной системе, которая уже имеет информацию об учетных данных.
Похоже, что вы относительно довольны процессом аутентификации, но хотите изучить другие варианты сессий/настроек.
Мое предложение связано только с настройками (роли, предпочтения и т.д.)
На мой взгляд, необходимость преодолевать весь технологический стек от пользовательского интерфейса до бизнес-уровня до уровня БД иногда является излишеством. Для данных, которые вряд ли изменятся во время сеанса, это добавляет много накладных расходов... Потенциально происходит несколько преобразований данных (DB (Relational Format) -> ORM -> Web Service XML Serialization -> Web Tier deserialization).
Вы можете рассмотреть систему сессий, которая не полагается на тяжелую систему RDBMS или на модель ASP.NET Caching / Session. Есть варианты, которые очень производительны и хорошо масштабируются.
Вы можете использовать RavenDB от Ayende Rahien (Built for .NET). Его основная цель - обеспечить низкую задержку и высокую производительность доступа к документам JSON без схемы.
Используя это решение, вы настроите ravenDB на веб-уровне так, чтобы доступ к данным был очень быстрым. При первой аутентификации и получении настроек вы сохраняете идентификатор пользователя и информацию о настройках в этой сессионной БД. После этого при каждой загрузке контроллера данные настроек будут доступны без необходимости возвращаться к РСУБД. Эта БД также может быть использована для кэширования других данных, связанных с веб.
Что касается безопасности, данные настроек попадают на веб-уровень независимо от того, какой метод вы используете. Это решение будет не более и не менее безопасным, чем другие варианты (более безопасным, чем незашифрованный cookie). При необходимости вы можете зашифровать данные сессии - но это снова увеличит накладные расходы.
Просто еще один из миллиона вариантов, которые нужно рассмотреть.
Удачи,
Дайте нам знать, что вы решите!
Патрик.