我们目前拥有以下架构（适用于基于RoR的生产系统）
网关也充当auth（使用DoorKeeper实现的oauth功能）是来自前端的所有请求的起点。
系统运行良好。我们现在面临的任务涉及添加遗留应用程序（用多种语言编写，包括ASP.NET）。这个遗留应用程序目前可以作为独立系统使用。我们打算做的是
- 将遗留系统集成到我们的工作系统中（在我们自己的子网内）
- 对遗留系统进行最小（或可能为零）修改
- 继续使用我们的oauth层（网关）作为所有传入请求的第一联系人（包括对旧系统的请求）
我们控制前端请求和路由，因此CSRF不是问题
我们正在考虑的一个解决方案是auth层（网关）也充当反向代理。实质上，遗留环境（来自传统前端客户端）的任何请求都将由门卫进行身份验证，但现在它们将被重定向到旧服务器应用程序，然后将响应发送回客户端。
以上听起来像是一个nginx反向代理，但我想要一个我可以使用的RoR gem，因为我希望它能够灵活用于将来的修改。例如（但不限于）
- 我可以修改旧版客户端以开始使用多个身份验证机制（因此从客户端到身份验证层的请求将具有不同的标头，但我想在auth-legacy-backend的旅程中将此请求更改为其旧格式-server-application and back）[ easy ]
- 我想在客户端上添加加密（SSL）到auth（网关）请求。网关将解密请求并发送auth-legacy-backend-server-application和back journey的未加密请求）[ tougher ]
- 一些遗留系统请求是Legacy-FrontEnd（ LFE ） - ＆gt; Legacy-Backend（ LBE ）使用基于cookie的会话。我想使用网关来模拟这种行为。
- LFE - ＆gt;网关使用我的身份验证机制（比如加密令牌）
- 网关 - ＆gt; LBE模拟基于cookie的会话行为
- gateway保持令牌到会话cookie的映射
[上面的最后一点是我们可能会在以后遇到的用例过度简化]