XML-RPC的非交互式认证/授权？

Question

我们不完全符合XML-RPC规范，但概念几乎完全相同。客户端通过HTTP/HTTPS与XML负载进入。我们用回应请求的XML有效负载进行响应。这主要是机器加工，所以没有人类输入用户名/密码。我们的构造在Apache Tomcat中运行。我们希望验证请求，并且由于并非每个客户都可以使用每个服务，所以我们还需要授权请求。我们有订阅和每次使用收费模式，所以有必要记录一切。

对于服务器和客户端，你会推荐什么？

Answer 1

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安全框架，我推迟到谷歌 - 有几个，我没有使用过它们中的任何一个。我对容器验证有很好的运气，并且写了我们自己的。

Answer 2

@Will

我第二HTTP基本的建议，并且可以证明它集成了相当不错与Spring Security，这是我上推出了自己的基于数据库的认证/授权逻辑的遗留应用的基础上实现的。