Неинтерактивная аутентификация / авторизация для XML-RPC?

Question

Мы не совсем соблюдаем спецификацию XML-RPC, но концепции почти идентичны. Клиент приходит через HTTP / HTTPS с полезной нагрузкой XML. Мы отвечаем с помощью полезной нагрузки XML, отвечающей на запрос. Это в первую очередь машина к машине, поэтому не нужно вводить имя пользователя / пароль. Наша конструкция работает в Apache Tomcat. Мы хотели бы подтвердить подлинность запроса, и поскольку не каждый сервис доступен для каждого клиента, нам также необходимо авторизовать запрос. У нас есть как платные, так и платные модели, поэтому необходимо регистрировать все.

Что бы вы порекомендовали как для сервера, так и для клиента?

Answer 1

HTTP BASIC / DIGEST прекрасно работает для большинства задач, выполняемых с компьютера на компьютер, и обрабатывается сервером, поэтому ваш API не изменяется.

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

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

Или вы можете использовать классический «логин», установить cookie, сохранить технику сеанса.

Но, честно говоря, для машинной работы HTTP BASIC является самым простым.

редактировать, относительно комментариев.

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

КАК ЭТО ОСУЩЕСТВЛЯЕТСЯ, зависит от вас и вашего заявления. Используя Java, вы можете использовать контейнерную аутентификацию, которая обеспечит аутентификацию, а также сопоставление ролей. Отображение роли пользователя -> обрабатывается либо в файле данных, либо в базе данных. Защищенные URL-адреса и то, какие роли являются действительными для каждого URL-адреса, управляются файлом web.xml.

Если вы продолжите добавлять разные роли к разным URL-адресам, тогда да, вам нужно будет повторно развернуть это приложение.

Однако, если вы просто добавляете новых пользователей, вы просто обновляете свой файл или базу данных. И если вы добавляете новую логику и эти новые URL-адреса, то вам все равно придется повторно развертывать. Если у вас есть структура ROLE с достаточно тонкой гранулярностью, вам не придется возиться с web.xml, пока вы не добавите новые методы. Например, вы можете, в крайнем случае, создать роль для метода и назначить их индивидуально пользователям. Большинству не нужно заходить так далеко.

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

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

Answer 2

@ Будет

Я поддерживаю предложение HTTP Basic и могу засвидетельствовать, что он довольно хорошо интегрируется с Spring Security , который я реализовал поверх унаследованного приложения, которое развернуло свою собственную логику аутентификации / авторизации на основе БД.