1
19
“索赔身份指南”本章提供了WIF+MVC的一个示例: http://msdn.microsoft.com/en-us/library/ff359105.aspx 我建议阅读前几章来理解所有的基本原则。这篇博文涵盖了MVC+WIF的具体内容: http://blogs.msdn.com/b/eugeniop/archive/2010/04/03/wif-and-mvc-how-it-works.aspx 控制登录体验是非常好的。您应该部署自己的sts(在您的域中,使用您的外观等)。你的应用程序只需要依赖它进行身份验证(这就是为什么应用程序通常被称为“依赖方”)。 架构的优点是authn被委托给一个组件(sts),而不是分布在许多应用程序中。但另一个(巨大的)优势是,您可以非常容易地启用更复杂的场景。例如,您现在可以与其他组织的身份提供程序联合。 希望有帮助 欧亨尼奥 @ RisingStar: 令牌(包含声明)可以选择性地加密(否则将以明文形式)。这就是为什么ssl总是被推荐用于浏览器和sts之间的交互。 注意,即使它们是明文的,也不可能进行篡改,因为令牌是数字签名的。 |
2
13
你问的问题很有趣。我知道不管出于什么原因,微软推出了这个“Windows身份基础”框架,没有太多的文档。我之所以知道这一点,是因为我的任务是找出如何在新项目中使用它,并将它与现有的基础设施集成。我已经在网上搜索了几个月,寻找好的信息。 我从一个不同的角度来解决你所描述的问题。 我使用了一个现有的登录应用程序,并将微软的wif管道集成到其中。我的意思是,我有一个用户登录的应用程序。登录应用程序将用户提供的凭据提交到另一个服务器,该服务器返回用户标识(或指示登录失败)。
看看微软的一些例子,我发现它们可以做到以下几点:
构建一个
我的一些代码与代码示例非常相似。你对实现自己的逻辑感兴趣的地方是
现在,这是我认为你真正感兴趣的。这是微软在他们的文档中没有告诉你的,afaik。 用户登录后,将重定向回依赖方应用程序。无论登录应用程序如何工作,wif类都将向用户浏览器发送一个响应,其中包含一个“隐藏”的html输入,该输入包含令牌签名证书和用户声明。(索赔将以明文形式提出)。在这个答复的最后是一个重定向到您的依赖方网站。我只知道这个动作是因为我用“小提琴手”拍到的 回到依赖方网站后,wif类将处理响应(在运行任何代码之前)。证书将被验证。默认情况下,如果已使用fedutil.exe设置依赖方网站(通过单击“从Visual Studio在依赖方应用程序中添加STS引用”),则Microsoft的类将验证证书指纹。 最后,wif框架在包含用户声明的用户浏览器中设置cookie(根据我的经验,cookie名称以“fedauth”开头)。这些曲奇不是人类可读的。
一旦发生这种情况,您可以选择使用
我知道这和你描述的不一样,但我有这个装置。我希望这有帮助! 请查看我问过的关于Windows身份基础的其他问题。 更新:回答以下评论中的问题:
我遗漏的一件事是,重定向到sts登录应用程序是通过一个包含用户登录的应用程序url的查询字符串进行重定向的。当用户第一次尝试访问需要身份验证的页面时,会自动执行此重定向。或者,我相信您可以使用
我从未尝试过这样做,但是如果您想在应用程序本身中使用登录页,我相信框架应该允许您使用以下内容:
1)将sts代码封装在库中。
2)从应用程序中引用库。
3)在应用程序中创建登录页。确保此类页不需要身份验证。
4)设置
|
3
4
你想做的是一个活跃的签名。WIF包括 WSTrustChannel(Factory) 它允许您直接与sts通信并获取安全令牌。如果您希望您的登录表单以这种方式工作,您可以遵循wif 4.0sdk中的“wstrustchannel”示例。获得令牌后,以下代码将获取该令牌并调用WIF处理程序以创建会话令牌并设置适当的cookie:
一旦你这样做了,你的网站应该表现得像被动签名一样。 |
4
1
您可以使用FederatedPassiveSignin控件。 |
5
0
像这样设置cookie: FederatedAuthentication.SessionAuthenticationModule.WriteSessionToCookie(SessionToken); 不适用于其他域的SSO。 to cookie应该由sts而不是rp设置。 |
drewrockshard · 将密码与本地文件名匹配 6 年前 |
Bassie · 我的凭据存储在哪里? 6 年前 |
Marc · getAuthEntity失败“无法匹配预期类型” 6 年前 |