【问题标题】:ASP.NET MVC 2 and authentication using WIF (Windows Identity Foundation)ASP.NET MVC 2 和使用 WIF (Windows Identity Foundation) 的身份验证
【发布时间】:2011-02-06 23:13:57
【问题描述】:

是否有以下可用的体面示例:

查看 the WIF SDK,有一些将 WIF 与 ASP.NET 结合使用的示例,使用 WSFederationAuthenticationModule (FAM) 重定向到 ASP.NET 站点瘦身在用户用来进行身份验证的安全令牌服务 (STS) 之上(通过提供用户名和密码)。

如果我正确理解 WIF 和基于声明的访问,我希望我的应用程序提供自己的登录屏幕,用户在其中提供用户名和密码,并让此委托给 STS 进行身份验证,通过以下方式将登录详细信息发送到端点安全标准 (WS-*),并期望返回 SAML 令牌。理想情况下,SessionAuthenticationModule 将按照使用FAMSessionAuthenticationModule 的示例工作,即负责从会话安全分块cookie 重建IClaimsPrincipal,并在安全会话到期时重定向到我的应用程序登录页面。

我所描述的是否可以使用 FAMSessionAuthenticationModule 以及适当的 web.config 设置,还是我需要考虑自己编写一个 HttpModule 来处理这个问题?或者,是在被动请求者场景中重定向到用户登录事实上的方法的瘦网站 STS?

【问题讨论】:

    标签: asp.net-mvc authentication claims-based-identity wif


    【解决方案1】:

    这是您提出的一个有趣的问题。我知道无论出于何种原因,微软在没有太多文档的情况下推出了这个“Windows Identity Foundation”框架。我知道这一点是因为我的任务是弄清楚如何将它用于新项目并将其与现有基础架构集成。几个月来我一直在网上搜索,寻找好的信息。

    我对解决您描述的问题采取了不同的角度。

    我采用了一个现有的登录应用程序并将 Microsoft 的 WIF 管道集成到其中。我的意思是我有一个用户登录的应用程序。登录应用程序将用户提供的凭据提交到另一个服务器,该服务器返回用户身份(或指示登录失败)。

    查看 Microsoft 的一些示例,我发现它们执行以下操作: 从查询字符串(由依赖方应用程序生成)构造SignInRequestMessage,从自定义类构造安全令牌服务,最后使用当前的 httpcontext.response 调用 FederatedSecurityTokenServiceOperations.ProcessSignInresponse。不幸的是,我不能在这里很好地解释它;您确实需要查看代码示例。

    我的一些代码与代码示例非常相似。在GetOutputClaimsIdentity 中,您将对实现很多自己的逻辑感兴趣。这是构造描述登录用户的声明身份的函数。

    现在,这就是我认为您真正有兴趣了解的内容。这是微软在他们的文档 AFAIK 中没有告诉你的。

    一旦用户登录,他们就会被重定向回依赖方应用程序。无论登录应用程序如何工作,WIF 类都会向用户的浏览器发送一个响应,其中包含一个“隐藏的”HTML 输入,其中包含令牌签名证书和用户的声明。 (声明将采用明文形式)。在此响应的末尾是重定向到您的依赖方网站。我只知道这个动作,因为我用“Fiddler”捕获它

    返回依赖方网站后,WIF 类将处理响应(在您的任何代码运行之前)。证书将被验证。默认情况下,如果您使用 FedUtil.exe 设置您的信赖方网站(通过在 Visual Studio 中单击“在您的信赖方应用程序中添加 STS 引用),Microsoft 的类将验证证书指纹。

    最后,WIF 框架在用户浏览器中设置包含用户声明的 cookie(根据我的经验,cookie 名称以“FedAuth”开头)。 Cookie 不是人类可读的。

    一旦发生这种情况,您可以选择使用ClaimsAuthenticationClass 在依赖方网站内对用户的声明执行操作。这是您的代码再次运行的地方。

    我知道这与您所描述的不同,但我可以使用此设置。我希望这会有所帮助!

    ps。请查看我就 Windows Identity Foundation 提出的其他问题。

    更新:在下面的评论中回答问题:

    我遗漏的一件事是重定向到 STS 登录应用程序是通过使用包含用户正在登录的应用程序 URL 的查询字符串的重定向发生的。当用户第一次尝试访问需要身份验证的页面时,此重定向会自动发生。或者,我相信您可以使用 WSFederationAuthentication 模块手动进行重定向。

    我从未尝试过这样做,但如果您想在应用程序本身中使用登录页面,我相信框架应该允许您使用以下内容:

    1) 将您的 STS 代码封装在一个库中。 2) 从您的应用程序中引用该库。 3) 在您的应用程序中创建一个登录页面。确保此类页面不需要身份验证。 4) 将 web.config 的 Microsoft.IdentityModel 部分中的 wsFederation 元素的 issuer 属性设置为登录页面。

    【讨论】:

    • 感谢您抽出宝贵时间回答我的问题。我浏览了 WIF SDK 附带的已编译的 html 帮助文件,还浏览了所有示例。我已经用 Reflector 分离了 FAMSessionAuthenticationModule 并认为我对它的工作方式有很好的了解,但我很想看看是否有使用 FAM 或自定义 HttpModule 的示例使用SessionAuthenticationModule 表示基于声明的身份。 FAM 似乎很容易使用,但没有提供太大的灵活性......
    • 也许整个想法是登录应该在 Web 应用程序 STS 上进行,因为这意味着您不必担心在每个 Web 应用程序中构建登录屏幕。但是,我希望能够为每个应用程序的登录屏幕保持特定的外观和感觉,最好将其保持在同一个域中,以免混淆用户(这可能会发生,因为可能有很多非精通技术的用户)。我只想获取输入的凭据,将它们包装在对 STS 的 WS-Federated 调用中以进行身份​​验证。我的想法是否与想法不一致?
    • 你的想法不一定是错位的。我一开始已经有一个单独的登录应用程序用于其他应用程序;我只是将 STS 添加到登录应用程序中。我相信你想做的事情是可能的,但需要一些实验才能让它运行起来。我已经更新了我的答案,并了解了您如何完成这项工作。
    • 您似乎在将 WIF 与 ASP.NET MVC 结合使用方面经验丰富。我正在研究使用 WIF 与 MVC 应用程序和 WebForms 应用程序集成。我下载了 SDK,但不知道从哪里开始。这些应用程序中的每一个都有自己的登录页面,我想对其进行设置,以便任何进入第一个应用程序登录页面的请求都将传递给 STS 进行身份验证和授权。登录到第一个应用程序后,用户可以跳过登录页面到第二个应用程序。鉴于这种情况,您建议我查看哪些示例?
    • @DotnetDude,查看身份“开发人员培训工具包”,如果您在使用它时遇到问题,请务必查看此讨论:stackoverflow.com/questions/2052386/…。有一个示例展示了如何使用 WIF 将用户登录到多个网页。
    【解决方案2】:

    “Claims Identity Guide”的本章提供了 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(这就是为什么应用通常被称为“依赖方”)。

    该架构的优势在于 authN 被委托给 1 个组件(STS),而不是分散在许多应用程序中。但另一个(巨大的)优势是您可以非常轻松地启用更复杂的场景。例如,您现在可以与其他组织的身份提供者联合。

    希望对你有帮助 尤金尼奥

    @RisingStar:

    令牌(包含声明)可以选择加密(否则它们将是明文)。这就是为什么始终建议将 SSL 用于浏览器和 STS 之间的交互。

    请注意,即使它们是明文形式,也无法篡改,因为令牌是经过数字签名的。

    【讨论】:

    • 感谢 Eugenio,我认为我已经阅读了声明身份指南,显然不是因为我错过了 Fabrikam 是一个 MVC 应用程序。我一定会再看看它。我还查看了 Dominick Baier 的博客,并认为在登录页面上从网络服务器调用活动 sts 最终是我所追求的。
    • 我看不出在 ASP.net MVC 中使用 WIF 与使用 ASP.net 表单有什么不同。
    • 原理完全一样。只有一些实现细节。最常见的区别是: - 在 webforms 应用程序中,您通常依赖 WIF 进行所有协议交换 (passiveRedirectEnable=true)。在 MVC 应用程序中,您将关闭它并按照我的博客文章中的说明以编程方式处理它。 - 在 MVC 应用程序中,您通常实现 IAuthorizationFilter 属性。在 Web 表单中,这并不存在,您只需依赖现有的 ASP.NET 授权机制(或调用 IsInRole 等)
    【解决方案3】:

    您要做的是主动登录。 WIF 包括WSTrustChannel(Factory),它允许您直接与 STS 通信并获取安全令牌。如果您希望您的登录表单以这种方式工作,您可以遵循 WIF 4.0 SDK 中的“WSTrustChannel”示例。获得令牌后,以下代码将获取该令牌并调用 WIF 处理程序以创建会话令牌并设置适当的 cookie:

    public void EstablishAuthSession(GenericXmlSecurityToken genericToken)
    {
        var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;            
        var token = handlers.ReadToken(new XmlTextReader(
                                            new StringReader(genericToken.TokenXml.OuterXml)));
    
        var identity = handlers.ValidateToken(token).First();
        // create session token
        var sessionToken = new SessionSecurityToken(
            ClaimsPrincipal.CreateFromIdentity(identity));
        FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
    }
    

    完成此操作后,您的网站的行为应该与发生被动签名时相同。

    【讨论】:

      【解决方案4】:

      您可以使用 FederatedPassiveSignIn 控件。

      【讨论】:

      • 这是一个服务器端控件,适用于 webforms,但自然不适合 MVC 应用程序(因为它是一个带有 runat="server" 的服务器端控件)。对此有何建议?
      【解决方案5】:

      像这样设置你的cookie: FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken); 不适用于 SSO 到其他域。

      To cookie 应该由 STS 而非 RP 设置。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2012-12-26
        • 1970-01-01
        • 2011-02-27
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2023-04-08
        相关资源
        最近更新 更多