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

@Luis: вот мои входные данные.

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

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

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

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

Если вы все еще хотите использовать SOAP message level session management, authentication & authorization process, чтобы предоставить вам более подробную информацию, могу ли я узнать больше о вашей стороне клиента.

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

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

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

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

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

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

вы также можете пойти на в большинстве случаев.

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

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

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

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

используя обработчик SOAP, найдите имя первого элемента в теле.

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

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

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

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

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