我们并不完全符合 XML-RPC 规范，但概念几乎相同。客户端通过带有 XML 有效负载的 HTTP/HTTPS 进入。我们以响应请求的 XML 有效负载进行响应。这主要是机器对机器，所以没有人输入用户名/密码。我们的构造在 apache tomcat 中运行。我们想对请求进行身份验证，由于并非每个客户端都可以使用每个服务，因此我们还需要对请求进行授权。我们有订阅和按使用收费模式，因此有必要记录所有内容。
你会为服务器和客户端推荐什么？
【问题讨论】：
标签： web-services authentication authorization xml-rpc
HTTP BASIC/DIGEST 适用于大多数机器到机器的任务，它由服务器处理，因此您的 API 不受影响。
它不适用于交互式使用，因为在不关闭浏览器的情况下很难“注销”用户。
否则，您很可能需要更改您的 API 以包含身份验证信息，并让您的方法在您的代码中对其进行身份验证。
或者您可以使用经典的“登录”，设置 cookie，保持会话技术。
但是，坦率地说，对于机器对机器的工作，HTTP BASIC 是最简单的。
编辑，关于 cmets。
HTTP BASIC 是一种简单的协议，用于呈现身份验证所需的工件，它适用于机器对机器的 Web 服务。
如何实施取决于您和您的应用程序。使用 Java，您可以使用容器身份验证，这将提供身份验证以及角色映射。用户 -> 角色映射在数据文件或数据库中处理。受保护的 URL 以及对每个 URL 有效的角色由 web.xml 管理。
如果您继续向不同的 URL 添加不同的角色，那么，是的，您需要重新部署该应用程序。
但是，如果您只是添加新用户，那么您只需更新您的文件或数据库。如果您要添加新逻辑和新 URL，那么无论如何您都必须重新部署。如果你有一个粒度足够细的 ROLE 结构，那么在你真正添加新方法之前，你就不必弄乱 web.xml。例如，您可以在极端情况下为每个方法创建一个角色，并将它们单独分配给用户。大多数人不需要走那么远。
如果您不想使用容器身份验证，请编写一个 Servlet 过滤器来实现您将用户和角色映射到 URL 的愿景。即使您实现了自己的设施，您仍然可以为您的客户端使用 HTTP BASIC 协议。
如果您正在寻找一个整体通用的 Java 安全框架，我会参考 google —— 有几个，我没有使用过任何一个。我在容器身份验证和编写我们自己的身份验证方面很幸运。
【讨论】：
@威尔
我支持 HTTP Basic 建议，并且可以证明它与 Spring Security 的集成相当好，这是我在一个遗留应用程序之上实现的，该应用程序采用了自己的基于 DB 的身份验证/授权逻辑。
【讨论】：