Как мне выполнить аутентификацию на сайте ASP.Net MVC?

Question

У меня есть сайт, для которого требуется авторизация. Прямо сейчас я использую атрибут role на всех контроллерах в этой области и запускаю запрос для получения идентификатора пользователя и всех его настроек.

Мне кажется, что это запах кода или дизайна, что я получаю ИД пользователя и настройки каждый раз, когда загружается контроллер в этой области? Я не уверен, должен ли я использовать сессии или ASP.Net MVC 2.0 предоставляет какой-то уникальный способ справиться с этим. Другая проблема - это безопасность.

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

Answer 1

Одним из правил безопасности является то, что вы не должны пытаться делать это самостоятельно. Существует много ловушек в правильной работе системы аутентификации, не оставляя лазеек или бэкдоров. Таким образом, в этом отношении вы можете рассмотреть SqlMembershipProvider, который поставляется с .NET. Он может использоваться с MVC и предоставляет средства для получения ролей и текущего контекста безопасности, прост в установке и настройке и будет более безопасным, чем ваш собственный.

Если вы не используете SQL Server, у вас есть несколько вариантов. Одним из решений было бы использовать что-то вроде SQL Server Express или SQL Server Compact Edition для поддержки учетных данных. Другим решением было бы имитировать схему базы данных SqlMembrershipProvider, а затем написать пользовательский поставщик, который взаимодействует с этой схемой.

Последний вариант - написать собственный класс MembershipProvider. Хотя это все еще происходит самостоятельно, оно вынуждает вас войти в структуру MembershipProvider, чтобы позднее вы могли поменять его на другой (например, ActiveDirectoryMembershipProvider) и предоставляет общий интерфейс для взаимодействия с учетными данными и логинами, например, позволяет легко использовать встроенный контроль входа в систему.

Если вы уже используете MembershipProvider и хотите сохранить дополнительные пользовательские данные, я бы предложил SqlProfileProvider со всеми оговорками, которые я упомянул выше, о SqlMembershipProvider. ProfileProvider предоставляет структуру для поддержки пользовательских данных с текущим вошедшим пользователем.

Для получения дополнительной информации:

• Введение в членство
• Реализация членстваProvider
• Поставщики профилей ASP.NET

Answer 2

Вы также можете реализовать собственную идентификацию. Их очень легко реализовать, и они позволяют вам хранить любую информацию пользователя, которую вы хотите, в Identity, которая затем сохраняется в файлах cookie, которые Identity записывает, поэтому вы не обращаетесь к БД каждый раз, чтобы получить эту информацию.

Просто создайте новый класс, унаследованный от GenericIdentity, и вы уже в пути.

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

Мы используем пользовательский идентификатор для хранения нескольких битов информации о пользователе, и он работает довольно хорошо.

Answer 3

Кажется, что вы относительно довольны процессом аутентификации, но вы хотите изучить другие параметры для сеанса / настроек.

Мое предложение касается только настроек (ролей, предпочтений и т. Д.)

По моему мнению, необходимость проходить весь технологический стек от пользовательского интерфейса до бизнес-уровня к уровню БД к БД иногда бывает немного излишним. Для данных, которые вряд ли изменятся во время сеанса, это добавляет много накладных расходов ... Возможно, происходит несколько преобразований данных (БД (реляционный формат) -> ORM -> Сериализация XML веб-службы -> десериализация веб-уровня) .

Вы можете рассмотреть сессионную систему, которая не зависит от тяжелой системы СУБД или от модели кэширования / сеанса ASP.NET. Есть варианты, которые очень эффективны и хорошо масштабируются.

Вы можете использовать RavenDB от Ayende Rahien (Создано для .NET). Его главная цель - обеспечить высокопроизводительный доступ с минимальными задержками к документам JSON без схемы.

Используя это решение, вы настроите ravenDB на веб-уровне, чтобы доступ к данным был очень быстрым. При первой аутентификации и получении настроек вы сохраняете ID пользователя и информацию о настройках в этой сеансовой БД. Каждый раз, когда вы загружаете свой контроллер после этого, данные настроек доступны без необходимости возврата в СУБД. Эту БД также можно использовать для кэширования других данных, связанных с сетью.

Что касается безопасности , данные настроек попадают на веб-уровень независимо от используемого вами метода. Это решение будет не более или менее безопасным, чем другие варианты (более безопасным, чем незашифрованный файл cookie). Если вам нужно, вы можете зашифровать данные сеанса, но это снова увеличит ваши накладные расходы.

Просто еще один из миллиона вариантов для рассмотрения.

Удачи,

Дайте нам знать, что вы решите!

Patrick.

Answer 4

Мы делали это довольно много раз в прошлом. Подобно тому, что упоминает Томас, то, что мы обычно делали, - это реализованный новый поставщик членства, основанный на поставщике 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 текущего веб-контекста, чтобы получить к нему доступ из своего кода. Не расширенные свойства из базового базового пользовательского класса также доступны в потоке запросов, как обычно.

С выпуском Microsoft версии 2.0 исходного кода мы обнаружили, что это помогло нам решить некоторые проблемы, связанные с переизобретением. Еще одна вещь, которую следует учитывать для ваших реализаций, основана на вашем сценарии, вы можете обойти реализацию некоторого кода. Примером этого может быть код CreateUser, если вы работаете с серверной частью, в которой уже есть учетные данные.

Answer 5

Вы можете попробовать «Windows Identity Foundation». Я использовал его в одном из своих проектов некоторое время. Он допускает «проверку подлинности на основе утверждений», что в основном означает, что вы можете назначать «утверждения» - строки информации, которые описывают пользователя при входе в систему.

После входа в систему утверждения пользователя можно прочитать из поля HttpContext.Current.User. Вы также можете использовать утверждения «Роль», которые легко интегрируются со схемой аутентификации на основе ролей; Это означает, что вы можете предоставить пользователю утверждение о роли менеджера, а затем использовать `if (User.IsInRole (" manager ")).

В качестве дополнительного бонуса WIF упрощает повторное использование экрана входа в другие приложения.

В целом, это очень гибко, но документация очень плохая. Я задавал и отвечал на ряд вопросов о «Windows Identity Foundation» в StackOverflow.

Answer 6

Вы можете сохранить объект в сеансе, который содержит всю необходимую информацию о пользователе. Вам просто нужно добавить свойство в Controllers, Views или другие базовые классы, где вы хотите получить информацию о пользователе / ​​профиль. Это будет информация авторизации в отличие от любой информации аутентификации (например, аутентификация по формам)