Как разработать аутентификацию в толстом клиенте, чтобы быть в безопасности?
вот пример:
У меня есть настольное приложение (построенное с использованием Eclipse RCP), которое при запуске открывает диалоговое окно с полями "имя пользователя" и "пароль". Как только конечный пользователь вводит свое имя пользователя и пароль, связывается с сервером (spring remote-servlet, причем клиентская сторона является spring httpclient: аналогично подходы здесь.), и аутентификация выполняется на стороне сервера.
несколько вопросов к вышеупомянутому сценарию:
- если бы сказал, что эта служба аутентификации должна была пойти вниз, каков был бы лучший способ справиться с дальнейшими разбирательствами? Аутентификация-это то, с чем я не могу покончить. Будет ли запуск настольного клиента в "ограниченном" режиме хорошей идеей? Например, важные функции / меню / представления будут отключены, остальная часть приложения будет доступна?
- должен ли я иметь резервную службу аутентификации, работающую на другом машина, работающая в качестве резервной копии?
- каковы общие рекомендации в этом сценарии? Я помню, как читал о Google gears и как это позволит вам редактировать и делать вещи в автономном режиме - должно ли что-то подобное быть разработано?
пожалуйста, дайте мне знать ваш дизайн/архитектурная комментарии/предложения. Спасибо за помощь.
4 ответов
простой ответ: Не позволяйте службе аутентификации идти вниз!
убедитесь, что служба аутентификации работает в кластеризованной среде с балансировкой нагрузки за виртуальным IP-адресом. Таким образом, вы можете избежать простоя в случае, если один из отдельных серверов идет вниз. Это касается не только самой службы, но и любых источников данных, на которые она полагается.
очевидно, что ни одна система не является полностью отказоустойчивой, но вы должны быть в состоянии получить свой uptime закрыть достаточно 100%, что нет необходимости создавать "ограниченный" режим для настольного клиента.
должен ли я иметь резервную службу аутентификации, работающую на другой машине, работающую в качестве резервной копии?
да! Это было бы лучшим решением. Этот вопрос должен решаться ИМО на уровне сети / инфраструктуры, а не на уровне клиента.
если есть полезные части приложения, которые все еще могут функционировать без доступа к сети (например, маршрутизатор вниз, NIC идет pop), Вариант 1 может быть рассмотрен. Зачет объема работы необходимо против того, насколько это вероятно и насколько критично ваше приложение.
Если сказано, что эта служба аутентификации если бы мы спустились, что бы это было? лучший способ справиться дальше разбирательство? Проверка подлинности что-то, с чем я не могу покончить. Запуск настольного клиента в "ограниченный" режим-хорошая идея? Для пример, важный функции / меню/представления будут отключены, остальная часть приложения будет доступный?
запуск настольного клиента ограниченным способом-очень хорошая идея. Представьте, если бы Вы были невозможно написать электронное письмо, вложения perpare или сделать что-либо в почтовом клиенте, если вы не вошли в систему. Хороший пользовательский опыт требует способности работать в автономном режиме.
должен ли я иметь резервную аутентификацию служба работает на другом машина, работающая в качестве резервной копии?
Это были ответы очень хорошо другими, хотя я не полностью согласен с dbyrne. Несмотря на то, что все ваши сети и серверы могут работать нормально, время простоя неизбежна и связь между настольным клиентом и сервером не всегда будет идеальной.
- Если бы сказал, что эта служба аутентификации должна была пойти вниз, что было бы лучший способ справиться дальше разбирательство? Проверка подлинности что-то, с чем я не могу покончить. Запуск настольного клиента в "ограниченный" режим-хорошая идея? Для пример, важный функции / меню/представления будут отключены, остальная часть приложения будет доступный?
полезен ли клиент без сервера? Есть ли вещи, которые пользователь могу сделать? Если да, то вы хотите, чтобы пользователь мог делать эти вещи без аутентификации? Это ответ на твой вопрос.
неясно, что вы имеете в виду, когда говорите: "аутентификация-это то, с чем я не могу покончить.- что ты имеешь в виду? Вы имеете в виду, что есть некоторые функции, которые требуют аутентификации пользователя, или что это требование, наложенное кем-то другим, или ? (Почему ты не можешь покончить с этим?)
- должен ли я иметь резервную копию служба проверки подлинности, работающая на разные машины, работать резервного копирования?
насколько полезен ваш клиент в ситуации выше? Если это очень полезно, то вы можете основывать это решение и сколько потратить на обслуживание резервного сервера на том, насколько ценны только аутентифицированные функции.
если ваше приложение бесполезно без аутентификации, то основывайте свое решение о том, сколько инвестировать в резервный сервер аутентификации на том, сколько он стоит вам, когда ваши пользователи не могут аутентифицироваться.
- каковы общие рекомендации в этом сценарии? Я помните, читая о Google gears и как это позволит вам редактировать и делать материал в автономном режиме - должно что-то вроде это было спроектировано?
если есть способ сохранить полезные данные в автономном режиме, я думаю, что это хорошая идея, но я предубежден против сохранения моей информации в облаке, где я не могу ее контролировать или создавать резервные копии. Оно будет затраты времени и неявно денег на развитие способности делать как онлайн, так и офлайн по сравнению с одним из двух. Это суждение о том, насколько ценно приложение для ваших пользователей в автономном режиме.