2

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

应用程序会将其发送APPLICATION_KEY到集中式应用程序进行身份验证。然后，集中式应用程序验证APPLICATION_KEY转发的主机/引用者；如果经过验证，则转发请求以进行进一步处理。

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

有没有更好更可靠的方法来实现相同的过程，而不是使用请求对象中的转发主机或引用者？任何建议或指示都会非常有帮助。

4

1 回答 1

0

依赖容易伪造的标头并不是加强安全性的好方法。

通常，当您拥有中央身份验证服务时，用户会被重定向到带有标识应用程序的令牌的 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之类的东西。

于 2015-01-27T04:56:44.180 回答