Пароли для приложений, использующих стороннюю аутентификацию?
У меня есть приложение ASP.NET MVC, в которое я только что интегрировал стороннюю систему федеративной идентификации RPX. Интеграция работает нормально, но у меня возникли некоторые трудности, связанные с тем, что с ней делать на уровне ASP.NET.
Поскольку идентификационные данные обрабатываются извне, мне не нужны пароли в моем приложении: я никогда не получаю пароль пользователя, только его личность. Однако для работы провайдера членства в ASP.NET требуются пароли, чтобы создать пользователя, войти в него и т. Д.
Я думал об использовании new Guid() во время создания, но это потребует вызова базы данных для получения пароля пользователя, прежде чем я смогу войти в систему через поставщика членства. Я мог бы использовать один и тот же пароль для каждого пользователя, чтобы он был известен заранее, но я обеспокоен тем, что это сделает данные моего пользователя незащищенными.
Мне было бы интересно услышать, как другие сайты решают эту проблему, например, Stackru.
[Пожалуйста, также посмотрите мой другой вопрос, касающийся поставщиков членства для такого приложения.]
2 ответа
но я обеспокоен тем, что это сделает данные моего пользователя незащищенными.
Начнем с того, что никто не сможет пройти аутентификацию непосредственно в вашей базе данных с использованием имени пользователя и пароля - я полагаю, что это уже так, поскольку вы используете RPX для реальной аутентификации, и вы вызываете провайдера ASP.NET только после того, как уже сделали это. установил личность пользователя.
Тогда пароль, хранящийся на вашей стороне, становится несущественным, потому что это не секрет - если я смогу определить, какой пароль у вас на стороне, это не может внезапно скомпрометировать его данные, потому что я все еще не могу войти, используя эту информацию. Секрет пользователя управляется сторонним поставщиком, а не вами.
Таким образом, вы могли бы также хранить то, что наиболее удобно (то есть общеизвестное фиктивное значение) - вы могли бы также отключить шифрование пароля и у поставщика членства, чтобы вернуть некоторые циклы на сервере. Нет смысла шифровать / хэшировать значения, которые не используются для проверки чьей-либо личности.
Зачем тогда использовать членство в asp.net? На самом деле это не вписывается в то, что вы делаете, это сторонняя аутентификация. Может быть, вы могли бы взглянуть на проект dotnetopenid и примеры, так как они имеют классический пример сайта asp.net, который вы можете изменить для mvc? У них есть вики здесь Может быть, Google dotnetopenid MVC?