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

Question

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

应用程序将把这个APPLICATION_KEY发送到集中式应用程序进行身份验证。然后，集中式应用程序验证APPLICATION_KEY和转发的主机/引用；如果验证，则转发请求以供进一步处理。你知道吗

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

有没有更好更可靠的方法来实现相同的进程，而不是使用来自请求对象的转发主机或引用程序？任何建议或指点都会很有帮助。你知道吗

Answer 1

依赖一个容易伪造的头文件并不是加强安全性的好方法。你知道吗

通常，当您有一个中央身份验证服务时，用户将被重定向到具有标识应用程序的令牌的CAS。你知道吗

用户输入其凭据。你知道吗

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

重定向的目标作为请求的一部分传入CAS服务：

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

在某些实现中，重定向URL在POST请求的主体中发送。这种实现通常是在受控系统上完成的（即，通常不在互联网上）。你知道吗

为防止伪造代币，可采用以下任意组合：

1. 从某些IP登录是受限的（同样，在受控网络上这是可能的）。你知道吗
2. 令牌是使用使用PKI的共享密钥生成的。你知道吗
3. 仲裁器服务用于对CA和应用程序进行身份验证。你知道吗

对于面向公众的系统-实现是以另一种方式进行的；即，用户验证应用程序：

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

当然，也有其他方法来实现相同的功能，但是不要自己动手，而是使用shibboleth或crowd之类的方法。你知道吗