.net - 使用 Kerberos 对网站和 Web 服务进行身份验证是个好主意吗？

Question

通过收购，我们有许多需要认证和授权的产品。产品包括网站和客户端应用程序，客户端应用程序使用一些网络服务。我们是一家.Net 商店，服务器将运行 Server 2008，客户端将运行 XP SP？然后。

产品的用户不属于我们的组织，从使用独立 PC 的单个用户到运行 Active Directory 等的组织中的用户运行。

目前没有通用的身份验证或身份存储，我们正在寻求补救。我们的目标是:

所有产品的单一用户名和密码(或证书)。

理想情况下是单点登录(如果我们从客户端应用程序启动网站，这很容易，如果用户先登录网站，然后再启动客户端应用程序，则可能不太容易)。

加上平时；稳健、可扩展...

像大多数公司一样，我们的资源有限，时间紧迫。

一种建议的身份验证路径是 Kerberos，这可能是客户端应用程序对 Web 服务进行身份验证的理想途径，但我不太乐意在用户提交用户名和密码的网站上使用它，而 Web 服务器将是负责票务(然后将票存储在 cookie 中？)。我觉得使用单一身份存储和我们自己的身份验证服务可能会更好，该服务接受用户名和密码，与排序的哈希值进行比较，然后发布一个自定义的、基于时间的安全 token 。也许使用 SqlMembershipProvider？

感谢读到这里的任何人。 Kerberos 是否最适合这种情况，还是我应该寻找其他地方？如果不合适，为什么不呢？

我们也在寻找 AD LDS 的授权，但我认为这篇文章已经足够长了......

Answer 1

除了 Kerberos 并不是真正为这种用例设计的，而且通常不能很好地与防火墙配合使用之外，它本身并没有什么问题。例如，您可能不想打开对您在内部使用的同一个 Kerberos KDC 的外部访问。

另外，如果您的意思是 MS Kerberos，并且您显然是这样做的，那么打开 Kerberos 会附带一个完整的其他 MS 协议(protocol)的老鼠巢，您迟早必须打开这些协议(protocol)，因为更高级别的东西与 AD 等以及 Kerberos 纠缠在一起.

那说:

I feel that we may be better off with a [...] our own authentication service

几乎可以肯定不是。你通常不想重新发明轮子，如果你必须那么不要那个轮子。身份验证协议(protocol)通常很难实现，对于 Web 访问来说甚至更难。坚持已经存在的东西 - 基本身份验证 + SSL 或客户端证书和 SSL，加上 session 跟踪(如果这些东西真的很重要，则再次通过 SSL)，或者与您的 AD 不同的 LDAP 服务。这些方法都有自己的问题，但没有你自己滚动的东西那么多。