我们计划开发一个 REST 服务层来公开遗留系统上托管的服务。这些服务将由经典网络应用程序和 native 手机应用程序使用。
此遗留系统的安全方式要求初始用户名 + 密码身份验证(此过程可能需要 5 到 10 秒)。初始身份验证后，返回一个有时间限制的 token 。此 token 必须包含在所有进一步的请求中，否则请求将被拒绝。
由于安全要求，遗留安全 token 不能在 REST 服务层之外返回。这意味着 REST 服务层需要在某种形式的用户 session 中保留此 token ，否则每次调用遗留系统都需要重复昂贵的用户名 + 密码身份验证过程。
REST 服务层将使用 Java 6 + Spring 3 + Spring Security 3 堆栈实现。乍一看，此设置似乎运行良好:基于 Spring 的 REST 服务将使用相当标准的 Spring Security 配置进行保护，遗留安全 token 将存储在用户的 HTTP session 中，并且每次调用都将使用用户的 session 并将其发送到遗留系统。
但存在一个问题:REST 客户端将如何发送必要的数据以便正确检索用户的 HTTP session ？这通常由 Web 浏览器使用 JSESSIONID cookie 透明地完成，但没有浏览器参与此过程。当然，REST 客户端可以将 cookie 管理添加到他们的代码中，但这对所有 Spring RestTemplate、iPhone、BlackBerry 和 Android 客户端来说都是一项简单的任务吗？
另一种方法是绕过 REST 服务层的 HTTP session 并使用某种其他形式的用户 session ，可能使用数据库，这将使用 REST 客户端通过 HTTP header 或简单的请求查询。那么问题就变成了，如何将 Spring Security 配置为使用这种替代 session 机制而不是标准的 Servlet HttpSession？
当然，我不是第一个处理这种情况的人。我错过了什么？
谢谢!
最佳答案
cookie 没有什么神奇之处。他们只是strings in HTTP headers .任何体面的客户端 API 都可以处理它们，尽管许多需要显式配置才能启用 cookie 处理。
使用 cookie 的替代方法是将 JSESSIONID 放入 URL 中。我对 spring-security 一无所知，但似乎这实际上是至少某些类型的 URL 请求的默认设置，除非 disable-url-rewriting明确设置为 true 。这可以被认为是一个 s ecurity weakness , 不过。
关于java - 保护有状态的 Web 服务，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4911723/