2

Azure アカウントがあり、現在、Windows ストア アプリがデータベースと通信できるように、SQL データベースを使用してモバイル サービスをセットアップしています。

ASP.NET WebPages 認証を使用してサイトを開発しました。また、Windows ストア アプリにも同様のものが必要です。

Windows Azure Web サイトのドキュメントとチュートリアルを読み、ACS (Windows Live ID、Google、Yahoo!、および Facebook) を実装しましたが、問題は、Google、Yahoo!、Facebook、さらには Windows も必要ないということです。 Live ID または Microsoft アカウント) ログイン - 自分のログインが必要ですが、このオプションが提供されていないようです (間違っている場合は訂正してください)。

ユーザーがアプリケーション内からサインアップできるようにする必要があります (つまり、名前、生年月日、電子メール、電話番号、住所などを提供することを意味します)、すべてをデータベースに押し込みます。

現在、Azure サービスで Microsoft アカウント ログインを実装した後、アプリケーションにログインしたユーザーに関する最も基本的な情報 (電子メール アドレスでさえも) を取得できないことがわかりました。

役立つ可能性のあるものをオンラインで検索するのに何時間も費やしましたが、キーワードが不足しており、関連する結果はまだ 1 つもヒットしていません。

これが可能かどうか誰にもわかりますか？ログインとサインアップを、Windows Azure サービスとの間でこのデータを設定/取得する Windows ストア アプリと統合するにはどうすればよいでしょうか?

コード、サンプル、リンク、チュートリアル、ドキュメントなどは大歓迎です。

4

3 に答える 3

4

あなたは、外部 ID 認証を接続する道をたどりました。私の意見では、外部向けの Web アプリケーションでは、これがより良いアプローチです。利点は次のとおりです。

  • アプリケーションは、認証ではなく承認のみを担当します。認証には多くの作業が必要であり、多数のベスト プラクティスがあります。よく知っている人にこの負担を負わせてください。とはいえ、理解しようとしてはいけないというわけではありません。
  • あなたのサイトがハッキングされた場合、ユーザー名/電子メールとパスワードの組み合わせが侵害されたことを伝える必要はなく、おそらく他のサイトのパスワードを変更する必要があります.
  • また、ユーザーが別のユーザー名とメールアドレスのパスワードの組み合わせを覚えたり管理したりする必要がないようにします。

本当に認証を行いたい場合は問題ありませんが、自分で行う必要があります。Asp.Net Membershipの例をご覧ください。これが唯一の方法ではなく、最善の方法でもありませんが、多くの例があります。

外部認証を使用することに決めた場合は、現在の実装に役立ついくつかの指針を提供できます。

  • 最初に、Live、Google、Facebook から返される Id は、そのプロバイダーに対して一意であるとのみ想定できることに注意してください。したがって、その ID のプロファイルをシステムに保持し、複数のプロバイダーを使用する場合は、ID をシステム内で一意に保ち、それを特定の ID に関連付けられるように実装する必要があります。プロバイダー。

ソーシャル ID プロバイダーおよび ACS による Web サイト認証パート 2 – ACS とユニバーサル プロファイル プロバイダーの統合

  • お気づきのように、すべての認証プロバイダーが同じ「クレーム」を返すわけではありません。クレームとは、電子メール アドレス、名前、生年月日など、ユーザーが所有していると主張するものです。デフォルトで ACS を介して使用できるものはすべて Uid を返し、名前と電子メール アドレスを返すものもあります。あなたがしなければならないことは、ギャップを埋めることです。誰かが登録したら、関連するクレームを引き出して、不足しているクレームを埋めるよう依頼する必要があります。1 つのプロバイダーがわずかに異なる名前を使用する場合があるため、ACS のさまざまなクレームをアプリで使用できる共通の名前にマップすることもできます。

Windows Azure アクセス コントロール サービスを使用したフェデレーション ID

  • 認証を処理しないという理由だけで、アプリケーションを安全に保つ責任を負う必要があります。作業の半分が完了したので、コードはかなり軽くなりますが、ロールを使用する必要があります。

Windows Azure ロール ベース認証 (ACS)

  • このアプローチの本当に優れた点は、SO が ID モデルで行ったのと同じようにアプリケーションを実装できることです。ユーザーが自分のプロファイルに対して複数の ID を関連付けることを許可できます。つまり、ユーザーは好きな方法でログインできます。
于 2013-04-09T13:19:15.190 に答える
2

組み込みプロバイダーを使用しないことを選択した場合は、ACSSAML、OpenId などを使用して独自の ID プロバイダーを実装する必要があります...

またはWindows Identity Foundationを実装するために (WIF) を調べることができます。WS-TrustWS-Federation

またADFS、同じサポート セットを備えていますが、Active Directory と WIF を使用しており、Azure には使用できる独自のバージョンの AD があります。

thinktecture identityserverIdP ランドへのベンチャーをジャンプスタートできるものもありますが、私自身はまだ使用していません。

OpenId ルートに行きたい場合は、 がありDotNetOpenAuthます。

于 2013-04-09T13:18:25.167 に答える
2

カスタム ID をモバイル サービス アプリに追加することを検討している場合は、カスタム認証に関する Josh の投稿 ( http://www.thejoyofcode.com/Exploring_custom_identity_in_Mobile_Services_Day_12_.aspx ) を確認してください。

于 2013-04-09T18:09:50.567 に答える