Где хранить БД авторизации?

Что сейчас считается лучшим решением: отдельная БД для авторизации или создание ее структуры (при помощи утилиты) в той же БД, где предполагается хранить мои данные?

Да хоть xml файл, все зависит от конкретного случая.

Цитата Uncle_Bob @ 05.04.13, 11:49

Да хоть xml файл, все зависит от конкретного случая.

В том и суть вопроса. xml файл это и есть отдельное хранение аккаунтов от данных. Это несколько непривычно по архитектуре.
Вот, например, если я храню инфу о том, какой ползователь новую запись внес, то нормально ли хранить пользователей отдельно, данные отдельно?

Как оно, вообще, делается обычно?

Если данные завязаны на юзеров, логично в одной базе

ЗЫ. Собсно, причем тут аспнет?

Сообщение отредактировано: Uncle_Bob - 05.04.13, 14:46

Чисто архитектурный вопрос, но завязанный на моду аспнета. Лучше аспнетчиков никто на него не ответит

В принципе совершенно необязательно таскать за собой эту авторизационную байду с SqlMembershipProvider во главе

Цитата Uncle_Bob @ 05.04.13, 19:22

В принципе совершенно необязательно таскать за собой эту авторизационную байду с SqlMembershipProvider во главе

А как надо?

Как надо - это каждый решает сам... Аспнетовский sql провайдер имеет имхо только один плюс - он работает из коробки. Все остальное - его минусы. Плохо расширяется, все равно требует написания админки (если надо управлять юзерами из приложения). Имеет наимутнейший sql код. Так что все зависит опять же от задач. Написать собственную авторизацию - вопрос времени от нескольких часов. Но все зависит от функционала.

Цитата ttiger @ 05.04.13, 07:14

Что сейчас считается лучшим решением: отдельная БД для авторизации или создание ее структуры (при помощи утилиты) в той же БД, где предполагается хранить мои данные?

Зависит от программы. Точнее от сектора для которого она разработана.
Если только корпоративный сегмент, то использовать исключительно внешние средства авторизации, такие как AD, RADIUS и иже си ними.
Если программа нацелена на широкий сектор от малого бизнеса до большого корпоративного - разумно использовать смешанные модели авторизации, на выбор пользователя, либо интегрированная в программу авторизация (в этом случае в своей базюке все) или внешние сервисы те же самые. Тут с одной стороны пользователям которым не принципиальны вопросы безопасности, а принципиальны вопросы простоты и стоимости запуска программы в работу ты предложил вариант встроенной авторизации, а для тех, для кого вопросы безопасности приоритетны - ты предложил интеграцию с проверенными внешними решениями. + Нужно заметить что этот вариант еще и енд юзер френдли, не будет заставлять пользователей вводить пароль при запуске программы, а администраторам позволит управлять доступом централизованно.
Ну а если программа ориентирована на домашнего пользователя - храни в базюке и не заморачивайся, быстрее выпустишь - быстрее продукт начнет приносить деньги, увеличение сроков разработки из за вылизывания для этого сегмента негативно для проекта. Что не так - потом апдейтами поправишь. А "хитрые и правильные решения по безопасности" в этом сегменте никто не оценит.

Цитата Федор @ 13.04.13, 11:39

Зависит от программы. Точнее от сектора для которого она разработана.

Да, собственно, речь не шла о способе авторизации...

Сообщение отредактировано: ttiger - 13.04.13, 16:09

Вообще речь про аутентификацию или авторизацию?

Цитата

Аутентифика́ция (англ. Authentication) — процедура проверки подлинности, например: проверка подлинности пользователя путём сравнения введённого им пароля с паролем в базе данных пользователей

Авториза́ция (от англ. authorization — разрешение, уполномочивание) — предоставление определённому лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.[1][2][3] Часто можно услышать выражение, что какой-то человек «авторизован» для выполнения данной операции — это значит, что он имеет на неё право.

Я, разумеется, имел ввиду аутентификацию, т.е. распознавание пользователя по его логину и паролю. Вопрос был про то, что идет в ASP.NET из коробки.

Цитата ttiger @ 13.04.13, 19:54

Вопрос был про то, что идет в ASP.NET из коробки.

Ты как-то исключительно завуалировал свой вопрос Из коробки ты получаешь базу юзеров с профилями и ролями. Есть возможность администрирования части этого безобразия через подобие админки, которая работает из-под встроенного в студию веб-сервера. У меня не получилось в свое время поднять ее на IIS, правда это было еще во времена VS2005, что побудило тогда написать свою админку. Помимо прочего, нам требовалось расширение админной части для наших собственных нужд, для чего был сделан собственный провайдер над SqlMembershipProvider. И смотря сейчас на это все по прошествии 7 лет использования, я могу сказать, что для нас тогда это был правильный выбор, который позволял быстро внедрить аутентификационное решение. Но при наличии ресурсов, правильным я бы считал, создание собственного решения, ну или по крайней мере стал бы смотреть на какие-то альтернативные реализации. Причины я описал выше - при необходимости расширения коробочного функционала и необходимости наличия встроенной в приложение админной части, стандартный провайдер оказывается неудобен.

К слову сказать, сейчас у нас работает двойная аутентификация - локальные пользователи (коорпоративной сети) входят в систему прозрачно через Windows-аутентификацию, а внешние (интернет) пользователи входят через формовую. Тем не менее, и для тех и для других, в конечном итоге используется Forms аутентификация. Но для авторизации пользователя в приложении, пользователь, входящий через Windows аутентификацию, все равно должен иметь аккаунт в "коробочном" решении, чтобы оттуда цеплялись его роли. Может, звучит запутанно, но суть, думаю, понятна.

Сообщение отредактировано: Uncle_Bob - 14.04.13, 09:18