0

我正在尝试允许用户使用他们的 Google、Facebook 和 Windows Live 帐户登录到 ASP.NET MVC 网站。我目前正在使用 Azure App Fabric ACS，这让它变得非常简单。问题是我需要电子邮件地址。Google 和 Facebook 提供电子邮件作为声明，但 Windows Live 没有。从 LiveConnect 站点看来，使用 wl.basic（获取用户名）和 wl.emails（获取用户的电子邮件地址）范围似乎很容易，但我无法按顺序影响 ACS获取此信息。我还尝试实现 OAuth2 Web 服务器流程，以便在用户登录后从我的站点获取它。我能够获得所需的信息，但我陷入了无限的登录循环，因为 FedAuth cookie 被删除时我重定向到https://oauth.live.com/authorize开始流程。有没有人能够让它工作（在服务器端）？我是否应该完全废弃 ACS 并提供一个自定义页面，使用每个提供商的自定义代码来启用登录？

我用代码改造了以前的演示（博客引擎 ala smarx），这样我就不必暴露任何专有的东西。在我的 web.config FedUtil 中插入了以下内容：

<httpModules>
  <add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
  <add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</httpModules>

我删除了拒绝所有用户

但是我有一个特定的操作方法（新博客的帖子）强制用户获得授权

    [Authorize]
    public ActionResult New()
    {
        var principal = Thread.CurrentPrincipal as IClaimsPrincipal;
        if (principal == null)
            return new HttpStatusCodeResult(403);

        // if this is a Windows Live User we have more work to do 
        string redirectUrl = CheckForWindowsLiveUser(principal);
        if (redirectUrl != null)
        {
            return Redirect(redirectUrl);
        }

在第一次填充 cookie（FedAuth 和 FedAuth1）时的 New 请求中。重定向返回后，它们就消失了。我没有对会话提供者做任何事情（也许我应该）。

4

2 回答 2

1

就我而言，问题是由 ACS、Windows Live 应用程序和我用来访问该站点的 URL 之间的域名配置不正确引起的。在开发中，我对所有重定向都使用了一个主机名 localhost。但是，Windows Live 应用程序 API 设置不允许 localhost 域，因此我使用主机条目 myapp.localhost 来解决它。cookie 已在 ACS 登录重定向 (localhost) 上正确设置，并且由于域不同，因此未在授权重定向 (myapp.localhost) 上正确发送。

不正确

Development URI: http://localhost/app

ACS Redirect URI: http://localhost/app/sso

Windows Live Connect Authorization Redirect URI: http://myapp.localhost/app/sso/authorizations

正确的

Development URI: http://myapp.localhost/app

ACS Redirect URI: http://myapp.localhost/app/sso

Windows Live Connect Authorization Redirect URI: http://myapp.localhost/app/sso/authorizations
于 2014-06-30T19:05:58.717 回答
0

我认为您在 oauth2 和实时连接方面走在了正确的轨道上，应该可以解决您的无限循环问题。您在站点代码的哪个位置执行重定向到 oauth.live.com/authorize？我认为至少，它必须发生在用户通过 ACS 完成对 LiveID 的完整常规登录之后。

查看此博客文章以了解上下文

如果您的站点在第 5 步之前进行 oauth.live.com/authorize 调用，在 WIF 有机会建立会话之前，您将获得这个无限循环。

但是，如果您等到第 6 步，则应写入您的 FedAuth cookie 并且用户已建立会话。您应该能够进一步重定向到 oauth.live.com/authorize 以收集用户的电子邮件，而不会有无限循环的风险。实时连接将提示用户首次发布电子邮件，但这应该是无缝的。另一个优点是在第 6 步，您在 HttpContext.User.Current 中获得了 ACS 令牌，您可以使用 ACS 发出的 IdentityProvider 声明，因为您只需要在 IdentityProvider == LiveID 时进行进一步的 oauth 重定向。

于 2012-03-18T23:59:44.593 回答