Windows Live with Azureアクセスコントロールサービス

Question

ユーザーは、自分のGoogleアカウント、Facebookアカウント、およびWindows LiveアカウントでASP.NET MVC Webサイトにサインインできるようにしようとしています。私は現在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); 
     } 

クッキー（FedAuthとFedAuth1）が初めて入力されたときに、新しいリクエストの内部にリダイレクトが戻った後、それらは消えています。私はセッションプロバイダに何もしていない（多分私はすべきである）。

Answer 1

私はあなたが正しいトラックにoauth2と接続していると思うし、あなたの無限ループの問題を解決することができるはずです。あなたのサイトのコードでoauth.live.com/authorizeへのリダイレクトをどこで実行していますか？少なくとも、ユーザーがACS経由でLiveIDへの完全な従来のサインインを完了した後でなければならないと思います。

あなたのサイトには、ステップ5の前にoauth.live.com/authorize呼び出しを行っている場合WIFがセッションを確立する機会を得る前に、あなたは、これが無限得るでしょう、コンテキスト

ためthis blog postを見てみましょうループ。

ただし、手順6まで待つと、FedAuth Cookieが書き込まれ、ユーザーにセッションが確立されます。あなたは無限ループの危険なしにユーザーの電子メールを収集するためにoauth.live.com/authorizeにさらにリダイレクトする必要があります。ユーザーには初めて電子メールを公開するライブ接続が表示されますが、これはシームレスに行う必要があります。もう1つの利点は、HttpContext.User.CurrentでACSトークンを利用できるようにするステップ6で、IdentityProvider == LiveIDのときにこのoauthリダイレクトをさらに行う必要があるため、ACSが発行するIdentityProviderクレームを利用できることです。

Answer 2

私の場合、この問題は、ACS、Windows Liveアプリケーション、およびサイトにアクセスするために使用していたURL間のドメイン名の設定が間違っているために発生しました。開発時には、すべてのリダイレクトに単一のホスト名localhostを使用していました。ただし、Windows LiveアプリケーションAPI設定ではlocalhostドメインが許可されていないため、myapp.localhostを回避するためにホストエントリを使用しました。クッキーはACSログオンリダイレクト（localhost）で正しく設定されていたし、ドメインが異なっていたため、許可リダイレクト（myapp.localhost）で正しく送信されなかった。

誤った私は戻って、認証の結果からクッキーを取得していますので、それは過去のステップ6を得ている

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