3

我们有一个 Web 应用程序，它由两部分（除其他外）组成：一个用 Java 编写的“shell”，在 Jetty 中运行，通过 Waffle 使用 Windows 身份验证，它显示了一个用 ASP.NET 编写的“组件”，使用 Windows 身份验证在 IIS 中运行。这两个部分都来自同一主机，但（当然）来自不同的端口。

就目前而言，用户首先必须登录到 shell，然后当组件加载时，用户必须再次登录。 我们想摆脱第二个登录步骤。

从我所看到和阅读的内容来看，例如关于基于声明的身份验证和 OAuth，其标准模式如下：

  • 登录到 shell 后，shell 使用用户的 Windows 帐户名构造一个“令牌”，并将其发送回浏览器。
  • 该组件不使用 Windows 身份验证，而是由浏览器向其发送令牌。
  • 该组件验证它是否信任令牌，并使用来自该令牌的身份。

（在我们的例子中，最简单的技术是将令牌放在 cookie 中，因为 shell 和组件都运行在同一台服务器上，并且HTTP cookie 不是特定于端口的，所以浏览器会自动将 shell 的令牌发送给组件。）

现在我看到了几种构造和验证令牌的方法，例如：

  • (a) 令牌包含 Windows 帐户名称，使用硬编码到外壳和组件中的对称密钥加密，或者在安装时或启动时生成并同意。
  • (b) 令牌包含 Windows 帐户名称，使用私钥签名，并使用相应的公钥进行验证。此密钥对在安装时生成。
  • (c) 令牌包含一个 GUID，组件的服务器端调用 shell 的服务器端来验证其有效性并获取 Windows 帐户名。

我认为我更喜欢 (b)，因为 (a) 似乎过于“硬编码”，并且 (c) 更有可能产生缩放问题。此外，我们已经在 shell 中以 SSL 服务器证书的形式存在一个私钥/公钥对，该证书受组件信任。

我对 (b) 的主要担忧是令牌将包含 (X.509?) 签名，这意味着令牌可能会变得相当大。（会吗？）另外，我（还）不熟悉在 Java 中创建签名并在 .NET 中验证它的技术。

我的问题：这里使用的标准/推荐模式是什么？我忽略了哪些替代方案？有没有我们可以在这里使用的标准协议？

4

1 回答 1

1

你在正确的轨道上。

是的，这个想法是让外壳生成一个无法伪造的令牌（由除外壳之外的任何人/任何人生成），该令牌可以由组件验证。

你是对的，令牌可以变得非常大。它不会变得太大而无法使用（即大于浏览器可以处理的大小），但它可能会成为性能问题。

通常，任何接受具有任何类型缓存身份验证的 HTTP 流量的组件都将具有该缓存身份验证的首选格式。在您当前的实现中，在用户登录组件后（第二个登录步骤），组件将发出某种包含身份凭证的 cookie，它将接受后续请求。所以最好的办法是让 shell 准确地创建这些凭据。

如果做不到这一点，您可以使用选项 (b) 创建一个签名的证书表单，该组件可以验证该外壳，然后用其首选的身份验证证书形式替换。

于 2013-06-09T01:34:52.010 回答