ASP.NET和MVC.NET解决方案之间的单点登录选项？

我有一个ASP.NET解决方案，充当我的客户的主要客户门户。在这个网站上，用户可以登录访问他们重要的财务信息等等。该网站使用自定义身份验证方案，该方案针对本地数据库中的Users表检查用户的用户名（他们的电子邮件）和密码（salt-hash）。ASP.NET和MVC.NET解决方案之间的单点登录选项？

我正在构建一个新的MVC.NET解决方案，它更多地是由这些相同的客户用于订购的Web应用程序工具。我想重新使用ASP.NET门户的登录机制来验证用户身份。目标是保存用户免于记住两次登录，甚至不得不提供两次相同的登录。

允许登录ASP.NET解决方案的用户自动通过MVC.NET解决方案进行身份验证的选项是什么？我在下面列出了一些想法，但这些“不好”还是有更优雅的解决方案？我很喜欢你的意见。

常见的Cookie我可以创建的ASP.NET站点创建和MVC.NET网站寻找一个共同的cookie。但是这足够安全吗？
查询字符串中的令牌我可以在ASP.NET网站上创建一个存储在本地数据库中的令牌id，然后将其传递到链接的查询字符串中，该链接指向采用令牌id的MVC.NET网站并根据相同的数据库进行验证。
混合有点两者？
其他？有更好的主意吗？

来源

2013-03-15 jmrnet

我建议你看看Windows Identity Foundation。 – 2013-03-15 15:31:42

[ASP.Net MVC Single-Sign On]的可能重复（http://stackoverflow.com/questions/6176426/asp-net-mvc-single-sign-on） – Peter 2013-03-15 15:33:31

有关[Stack Exchanges Global Network Auto-登录]（http://blog.stackoverflow.com/2010/09/global-network-auto-login/）。 – 2013-03-15 15:38:59

我最近使用OpenId做了一些非常相似的事情（主要区别在于它是公司内部而不是外部客户）。

OpenId for .NET的实现被称为DotNetOpenAuth，它应该适合您的目的。

它确实花了我一段时间来实施;但它工作得很好，非常灵活，而且非常安全。关于OpenID

的更多信息（来自Wikipedia）：

OpenID是一种开放标准，它允许用户通过某些共同工作的网站进行认证（称为信任方或RP）使用第三方服务，消除了网站管理员提供自己的临时系统并允许用户整合他们的数字身份的需要。

用户可以使用他们的首选OpenID身份提供商创建帐户，然后使用这些帐户作为登录任何接受OpenID身份验证的网站的基础。 OpenID标准为身份提供者和OpenID接受者（“依赖方”）之间必须进行的通信提供了一个框架。 2标准扩展（OpenID属性交换）有助于将用户属性（如姓名和性别）从OpenID身份提供者转移到依赖方（每个依赖方可根据其要求请求一组不同的属性）。

OpenID协议不依赖中央机构来认证用户的身份。此外，无论是服务还是OpenID标准都可以要求用户认证用户的特定手段，从而允许从常见（例如密码）到小说（诸如智能卡或生物测定学）范围内的方法。

哦，如果你想进一步鼓励，Stack Exchange使用它！

@Jmrnet：针对你最后的评论：

也许我还不清楚。 OpenId本身仅用于验证从一个位置到另一个位置的证书（或多或少）。完全可以实现为SSO模式，用户不需要做任何不同的事情 - 他们不必选择提供者，注册或类似的东西。例如，在我的设置中，用户在Web门户中输入用户名和密码，然后单击按钮启动由OpenId自动登录的另一个站点。根本没有什么不同！ OpenId可以用于任何您可以想到的初始身份验证模型（请注意维基百科中摘录的粗体部分）。

来源

2013-03-15 15:32:49 Mansfield

可以解释和展示例子 – IamStalker 2013-03-15 15:45:53

我喜欢这个想法。我本身不能使用OpenId，但可以将它与本地的某种类型的认证一起使用吗？ – jmrnet 2013-03-15 16:14:19

@jmrnet为什么你不能使用OpenId？你可以推出你自己的版本，是的......但为了使它足够安全，你几乎可以重写openid标准......在这种情况下，你应该只使用openId :) – Mansfield 2013-03-15 16:41:53

我目前正在为同一个项目实施两个SSO解决方案。

其中，我们正在与外部合作伙伴进行交互，并使用SAML。

另一方面，我们允许登录用户访问我们的Sharepoint并使用“Token in Query String”方法，因为我们信任Sharepoint访问我们的会员表。这种方法比处理SAML令牌容易得多。

来源

2013-03-15 15:38:40

这是我最初的想法，但我担心在查询字符串中传递令牌不够安全。我过于担心吗？ – jmrnet 2013-03-15 16:08:49

您不应将其作为明文暴露。我们使用GUID作为记录标识符，然后对其进行加密，最后对base64进行编码，以便将其包含在QS中。 – 2013-03-15 16:42:02

看看SAML：

http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

它可以使用XML和支持加密。

来源

2013-03-15 15:47:00 RandomUs1r

有许多方法可以使用，Mansfied描述了OpenID和RandomUs1r描述的SAML。另外，您可以将相关信息存储在localStorage中或会话中。我相信你应该在会话中存储相关信息。

把它放在查询字符串中是不安全的，因为如果我注册并登录，我会在URL中看到类似UserID = 1234的内容。如果我将其更改为UserID = 1235并且该ID存在，那么我可以以其他用户的名义做一些事情。这被称为身份盗窃，应通过任何可能的方式予以阻止。所以你不应该在你的网址中有这种信息。另外，如果你存储用户的ID，你应该以某种方式混淆它。例如，如果将值存储在本地存储中，而不是1234，则存储加密（1234，salt），则用户操作的一致性将保持不变。

来源

2013-03-15 16:38:02

ASP.NET和MVC.NET解决方案之间的单点登录选项？

回答

相关问题