6

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

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

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

  • 所有产品的单一用户名和密码（或证书）。
  • 理想情况下是单点登录（如果我们从客户端应用程序启动网站，这很容易，如果用户先登录网站然后再启动客户端应用程序，则可能不太容易）。
  • 加上平时；健壮、可扩展...

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

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

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

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

4

4 回答 4

4

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

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

那说：

我觉得使用我们自己的身份验证服务可能会更好

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

于 2009-06-23T15:36:29.607 回答
3

你考虑过OpenID吗？

于 2009-05-09T13:38:44.577 回答
1

您的单个用户帐户的 OpenID 和授权应用程序访问另一个网站上的数据的 OAuth 是一个很好的分布式解决方案。是的，Active Directory 或其他纯单点登录解决方案在同构环境中运行良好，但在您的组织中听起来却大相径庭。

设置一个安全的 OpenID 提供程序实际上是一项重大责任，不应该只是通过将库与 Web 服务器一起拍打来完成的事情。您可以让您的用户使用他们自己的 OpenID，然后拥有一个数据库，您的用户在其中注册他们的 OpenID，以便他们在整个系统中被识别为员工/成员。系统的各个部分可以直接针对数据库检查 OpenID 的成员资格，或者您也可以使用 OAuth 来帮助验证成员资格。

您可以将这两种技术结合起来的方式非常有趣。

于 2009-05-09T19:48:05.980 回答
1

对于网站，您可以使用 SPNego/GSS-API/Kerberos。所有主流浏览器和网络服务器都支持 SP Nego。由于 LDAP、NFS 和 HAdoop 都支持 Kerberos，您应该看看这个解决方案。查看带有协商选项的 curl 命令。

于 2012-01-13T23:49:15.597 回答