Question

我试图允许用户使用他们的Google，Facebook和Windows Live帐户登录ASP.NET MVC网站。我目前正在使用Azure App Fabric ACS，这使它变得非常简单。问题是我需要电子邮件地址。谷歌和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）。重定向回来后，它们就消失了。我没有对会话提供者做任何事情（也许我应该）。

Answer 1

在我的情况下，问题是由于ACS，Windows Live应用程序和我用于访问该站点的URL之间的域名配置不正确引起的。在开发中，我使用单个主机名localhost来进行所有重定向。但是，Windows Live应用程序API设置不允许localhost域，因此我使用主机条目来解决它，myapp.localhost。正确地在ACS登录重定向（localhost）上设置了cookie，并且正确地，没有在授权重定向（myapp.localhost）上发送cookie，因为域名不同。

<强>不正确

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

Answer 2

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

查看this blog post上下文

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

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

Windows Live通过Azure Access Control Service发送电子邮件

2 个答案: