从重定向的请求访问转发的主机

Question

我正在开发一个应用程序，它将作为多个其他应用程序的集中身份验证系统。每个应用程序都有一个APPLICATION_KEY与其域名相关联。

应用程序会将此APPLICATION_KEY发送到Centralized Application进行身份验证。然后，Centralized Application会验证APPLICATION_KEY和转发的主机/推荐人;如果验证转发了进一步处理的请求。

到目前为止，当我创建一个应用程序并将其与APPLICATION_KEY重定向到Centralized Application时，问题就出现了。在HTTP重定向（302或301）的情况下，转发的主机不会出现在请求对象中，因此应用程序身份验证失败。

是否有更好，更可靠的方法来实现相同的流程，而不是使用来自请求对象的Forwarded Host或Referrer？任何建议或指示都会非常有用。

Answer 1

依赖易被伪造的标头不是强制执行安全性的好方法。

通常，当您拥有中央身份验证服务时，会使用标识应用程序的令牌将用户重定向到CAS。

用户输入凭据。

如果验证成功，则CAS服务检查用户对该应用程序的授权;然后使用包含其授权的身份验证令牌将用户重定向回应用程序。

重定向的目的地作为请求的一部分传递给CAS服务：

http://mycas.service/auth?token=ABC123FDSR&back=/foo/bar.html

在某些实现中，重定向URL在POST请求的正文中发送。这种实现通常在受控系统上完成（即通常不在Internet上）。

防止令牌伪造;应用以下任意组合：

1. 登录受某些IP的限制（同样，在受控网络上也是如此）。
2. 使用PKI使用共享密钥生成令牌。
3. 仲裁服务用于验证CAS和应用程序。

对于面向公众的系统 - 实施是以相反的方式完成的;也就是说，用户验证应用程序：

1. 用户登录CAS服务。
2. 用户为在服务上注册的应用生成令牌。
3. 用户登录目标应用程序。
4. 目标应用程序将用户重定向到CAS服务。
5. 用户登录CAS服务。
6. 在步骤2中生成的凭据令牌将传递回应用程序。

当然还有其他方法可以实现相同的效果，但不要自己烹饪，而是使用shibboleth或crowd之类的东西。