Вопрос разработки: динамически изменяемый графический интерфейс -> отправка классов реализации в виде мыльных вложений - PullRequest
Новая
       3

Вопрос разработки: динамически изменяемый графический интерфейс -> отправка классов реализации в виде мыльных вложений

1 голос
/ 24 января 2010

Вот сценарий: У меня есть Java-приложение (RCP / SWT), которое в настоящее время не поддерживает аутентификацию. Однако я должен добавить защиту к этому приложению, чтобы оно было развернуто в различных корпоративных средах. У меня есть несколько подходов, которые я поделился со всеми вами здесь и принял ваш вклад. Обратите внимание, что строгих требований пока нет, поэтому ... Я хотел бы, чтобы вы рассмотрели типичные и нестандартные модели безопасности корпоративных сетей.

Подход 1

  • Создать веб-сервис «Безопасность», который толстый клиент будет вызывать при запуске.
  • Клиент запрашивает безопасность для текущего режима аутентификации и получает класс реализации аутентификации в качестве мыльного вложения. Полученный класс не будет иметь логику для аутентификации, скорее он будет просто описывать пользовательский интерфейс и события в пользовательском интерфейсе. (Клиент может использовать инструментарий GUI, такой как Thinlet?)
  • Как только класс загружен, конечному пользователю отображается пользовательский интерфейс, относящийся к текущему установленному методу аутентификации.

Преимущества:

  • Этот подход позволяет мне обрабатывать разные схемы аутентификации. Например, если приложение должно проходить аутентификацию на основе имен пользователей и паролей, хранящихся в базе данных, будет достаточно экрана с полями UserName и password. Однако, скажем, пользователь должен был выполнить сетевой вход в систему, что потребовало бы ввода имени сети, пользовательский интерфейс содержал бы три поля. Если модель безопасности в клиентской сети диктует аутентификацию на основе ntlm / SSO, пользователь не увидит пользовательский интерфейс. Это также оставит возможности для будущих методов аутентификации - например, поддержка экрана входа в систему с помощью капчи / биометрические данные / что угодно.

Подход 2

ПОЦЕЛУЙ (Продолжай в том же духе, просто)

  • Имя пользователя и пароль обычно являются единственными двумя учетными данными, которые требуются для всех известных механизмов аутентификации?
  • Пусть толстый клиент запросит веб-сервис и позволит веб-сервису обрабатывать весь процесс аутентификации.

Я не уверен, насколько реалистичны / осуществимы / обычно используются вышеупомянутые подходы. Ценю вашу помощь.

1 Ответ

2 голосов
/ 24 января 2010

Я бы определенно не рекомендовал передавать определения классов в виде вложений SOAP. Сетевой загрузчик классов мог бы иметь больше смысла, но он все еще не нужен в вашей ситуации.

Положите в клиенте то, что там есть - интерфейс. Подготовьте несколько типов экранов (т.е. определенных как классы) на клиенте и активируйте каждый из них в зависимости от одного значения, переданного сервером. Например, если передано AuthenticationType.CREDENTIALS, выберите имя пользователя / пароль. Если Authentication.SMART_CARD - перейти на смарт-карту.

Если вы хотите распространять приложение, а затем реализовывать различные экраны авторизации, используйте Java Web Start . Таким образом, всем клиентам будет гарантированно установлена ​​последняя версия.

Узнав, что ваши требования накладывают некоторые ограничения, взгляните на эту статью о загрузчиках сетевых классов .

...