Windows Live通過電子郵件通過Azure訪問控制服務

我試圖讓用戶使用他們的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，並提供一個自定義頁面，使用來自每個提供商的自定義代碼來啓用登錄？Windows Live通過電子郵件通過Azure訪問控制服務

我用代碼翻新了以前的演示（博客引擎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）。重定向回來後，它們消失了。我沒有做任何會議提供商（也許我應該）。

來源

2012-03-18 sreed

我認爲你在oauth2和live connect的正確軌道上，應該可以解決你的無限循環問題。您的網站代碼中的哪個位置正在執行重定向到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重定向。

來源

2012-03-18 23:59:44

它越來越近6步，因爲我得到了餅乾從認證結果反饋。我編輯了上面的帖子，以包含我正在做的更具體的描述。 – sreed 2012-03-19 16:53:45

嗯，我明白了。我認爲這將有助於看到一個提琴手跟蹤（fiddler2.com）這個來看看什麼時候該cookie正在寫入和何時消失。 – 2012-03-24 16:00:35

你是否設法解決這個問題，我剛剛遇到同樣的問題。 – RubbleFord 2012-11-11 08:44:20

在我的情況下，問題是由ACS，Windows Live應用程序和我用來訪問該網站的URL之間的域名配置不正確引起的。在開發中，我使用單個主機名localhost作爲我的所有重定向。但是，Windows Live應用程序API設置不允許localhost域，因此我使用主機條目解決它，myapp.localhost。在ACS登錄重定向（本地主機）上正確設置了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

來源

2014-06-30 19:05:58 Scott

Windows Live通過電子郵件通過Azure訪問控制服務

回答

相關問題