0

ユーザーが 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);
        }

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 への従来の完全なサインインを完了した後に発生する必要があると思います。

コンテキストについては、このブログ投稿をご覧ください

WIF がセッションを確立する前に、ステップ 5 の前にサイトが oauth.live.com/authorize 呼び出しを行っている場合、この無限ループが発生します。

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

于 2012-03-18T23:59:44.593 に答える