JAX-WS, аутентификация и авторизация - как?

Каков наилучший способ проверки подлинности и авторизации в веб-службах?

Я разрабатываю набор веб-сервисов, требующих контроля доступа на основе ролей. Использование metro - SOAP, простая java без EJB.

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

До сих пор:

Прочитайте аутентификацию с использованием базы данных - но я хочу проверить уровень приложения;
Прочитайте аутентификацию приложения с помощью jax-ws - но я не хочу каждый раз выполнять механизм аутентификации;
Я думаю, что могу использовать обработчик SOAP, перехватывать все сообщения и выполнять управление авторизацией в hander, используя токен идентификатора сеанса, который поставляется вместе с сообщением, которое может быть сопоставлено с сохраненным идентификатором в базе данных, в веб-методе входа в систему.

EDIT:

У меня есть еще вопросы:

Как узнать имя вызываемого веб-метода?
Какой токен я должен использовать?
Как передать этот токен между вызовами?

РЕДАКТИРОВАТЬ 2

Из-за ответа @ag112:

Я использую Glassfish.

Я использую WS-Policy и WS-Security для шифрования и подписания сообщений. Использование взаимной проверки подлинности сертификата. Я хотел бы дополнить эту безопасность уровня сообщений между приложениями, аутентификацию и авторизацию для пользователей также на уровне сообщений.

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

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

Ответ 1

После всей помощи я создаю этот ответ для упрощения и суммирую все идеи, которые обсуждались.

У вопросов есть 2 реквизита:

Безопасность уровня сообщений;
Однократная аутентификация.

С помощью справки ag112 это сложно сделать или элегантно. Итак, вот выводы:

Для защиты уровня сообщений отправьте пользователя учетные данные каждый раз (поместите его в заголовок SOAP);
Для аутентификации в одно время используется безопасность транспортного уровня и управления сеансами.

Я предпочитаю первый, потому что уровень сообщений был самым большим.

Ответ 2

@Luis: Вот мои входы.

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

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

Конечно, решение транспортного уровня намного проще и стандартно в отрасли, если транспортным уровнем является HTTP. Для уровня сообщений можно использовать спецификации ws, такие как ws-security. Каждый запрос веб-службы представляет собой простой HTTP GET/POST, идентифицированный уникальным HTTP-URI. Как правило, в среде jax-ws metro WSServlet - это тот, который вводит сервлет для любого вызова веб-службы и который в конечном итоге делегирует вызов правильному классу реализации поставщика услуг. Поскольку приложение будет развернуто на веб-сервере, вы можете использовать все возможности сеанса и проверки подлинности, предоставляемые веб-контейнером J2ee.

Поскольку вы ищете контроль доступа на основе ролей, я бы использовал стандартный <web-resource-collection> в web.xml, чтобы указать, какую роль вы хотели бы иметь в случае конкретного HTTP-URI. Вы можете использовать стандартный модуль входа JAAS, который может выполнять аутентификацию и заполняет тему JAAS. Если имя пользователя/пароль предоставлены в SOAP XML, модуль регистрации JAAS также может искать/анализировать SOAP XML для извлечения этой информации. Сервер JAAS/app автоматически создаст токен аутентификации и сохранит его как файл cookie, чтобы каждый последующий запрос не нуждался в повторном процессе проверки подлинности. Это все стандарт J2ee. Вы можете найти много помощи в Интернете по этому поводу. Пожалуйста, дайте мне знать ваш сервер приложений, чтобы я мог предоставить вам дополнительные сведения.

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

EDIT1: Хорошо, исходя из ваших дальнейших вкладов, вот мои мысли: Безопасность сообщений, а именно шифрование и подпись, должно происходить, каждое сообщение перемещается между сервером и клиентом. где в качестве аутентификации сообщений вы собираетесь сделать один раз и предоставить токен токена/аутентификатора для клиента для последующих вызовов.

Вопрос остается: если вы поместили уникальный идентификатор сеанса в ответ SOAP для проверки подлинности в первый раз, ожидаете ли вы, что клиент будет анализировать XML-ответ SOAP и обеспечить, чтобы клиент каждый раз отправлял вам идентификатор сеанса в последующих SOAP-запросах. ИЛИ Вы хотите, чтобы управление сеансом было прозрачным для клиента, а для клиента ему нужно сначала отправить токен имени пользователя/пароля, а для последующих вызовов не требуется никакой токен имени пользователя/пароля. В этом случае вам нужно будет полагаться на управление сеансами на основе транспорта, например. HTTP файлы cookie

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

PS: Сервер Glassfish предоставляет способ настройки поставщика проверки подлинности сообщений, который автоматически включает/отключает аутентификацию уровня сообщения.

EDIT2: Я понимаю, что вы не хотите хранить учетные данные пользователя в клиентском приложении, а серверу веб-сервисов нужны эти учетные данные пользователя. OAuth - это открытый стандартный протокол, который позволяет сайту A получать доступ к личным данным пользователя на сайте B. Конечная идея - это сайт A получает токен аутентификации, который имеет определенное время истечения срока действия. Таким образом, токен, содержащий зашифрованные учетные данные пользователя или идентификатор jsession, помогает избежать повторной аутентификации. Вам нужно только решить, где вы хотите сохранить токен на стороне клиентского приложения Вы можете хранить токен как cookie, если транспорт является протоколом HTTP.

Сказав, что, конечно, передача учетных данных пользователя каждый раз кажется более простой и простой.

Ответ 3

Вы также можете перейти OpenEJB.

Он использовал JAAS с WS-Security.

Я надеюсь, что ссылка полезна.

Ответ 4

Как не было ответов, следуя совету @unhillbilly, я отвечаю на свой вопрос, с прогрессом до сих пор:

Как узнать имя веб-метода называемый;

Использование обработчика SOAP, нахождение имени первого элемента в теле.

Какой токен я должен использовать,

Я решил использовать 128-разрядный токен, представляющий каждый сеанс. Веб-службы продолжают оставаться без сеанса, ключ предназначен только для целей авторизации.

Как передать этот токен между вызовами.

Для веб-метода входа в систему результат имеет токен, в каждом последующем вызове токен является параметром.

есть ли лучший ответ?