我们不完全符合XML-RPC规范，但是概念几乎相同。客户端通过具有XML有效负载的HTTP / HTTPS进入。我们以XML有效负载响应请求。这主要是机器对机器，因此无需人工输入用户名/密码。我们的构造在apache tomcat中运行。我们希望对请求进行身份验证，并且由于并非每个客户都可以使用每项服务，因此我们还需要对请求进行授权。我们有订阅和按次计费模式，因此有必要记录所有内容。

我们对服务器和客户端有什么建议？

解决方案

HTTP BASIC / DIGEST适用于大多数机器到机器的任务，并且由服务器处理，因此API不受影响。

它不适用于交互式用途，因为在不关闭浏览器的情况下很难"注销"用户。

否则，我们很可能需要更改API以包括身份验证信息，并让方法在代码中对其进行身份验证。

或者，我们可以使用经典的"登录"，设置cookie，保留会话技术。

但是，坦率地说，对于机器对机器的工作，HTTP BASIC是最简单的。

编辑，关于评论。

HTTP BASIC只是一种协议，用于呈现身份验证所需的工件，并且对于机器对机器的Web服务非常有效。

如何实现取决于我们和应用程序。使用Java，我们可以使用容器身份验证，它将提供身份验证以及角色映射。用户->角色映射在数据文件或者数据库中处理。受保护的URL，以及每个URL的有效角色由web.xml管理。

如果我们继续向不同的URL添加不同的角色，那么，是的，我们需要重新部署该应用程序。

但是，如果我们只是添加新用户，则只需更新文件或者数据库。而且，如果我们要添加新的逻辑和新的URL，则无论如何都必须重新部署。如果我们有一个具有足够精细的ROLE结构，那么在实际添加新方法之前，我们不必弄乱web.xml。例如，我们可以在极端情况下为每个方法创建一个角色，并将其分别分配给用户。大多数不需要走那么远。

如果我们不想使用容器身份验证，请编写一个Servlet过滤器以实现将用户和角色映射到URL的愿景。即使我们实现自己的设施，我们仍然可以对客户端使用HTTP BASIC协议。

如果我们正在寻找一个整体的通用Java安全框架，我请google-有几个，我没有使用过它们中的任何一个。我在容器身份验证和编写自己的容器方面万事如意。

@将要

我赞同HTTP Basic的建议，并可以证明它与Spring Security集成得很好，我在一个继承了自己的基于DB的身份验证/授权逻辑的旧版应用程序之上实现了该功能。