4

別のドメインの JQuery アプリによって使用される MVC3 Web API アプリケーションの認証に使用できるオプションは何ですか?

これが私がこれまでに試した制約/事柄です:-

  • OAuth を使用したくありません。ユーザーベースが限られているプラ​​イベートアプリの場合、エンドユーザーが既存のプロバイダーにアカウントを持つことは期待できず、独自のプロバイダーを実装する余地はありません
  • ヘッダーで渡されたデータを使用して、完全に機能する HMAC-SHA256 実装が正常に機能しました。ただし、IE8/9 の CORS が壊れており、ヘッダーを送信できないため、これは IE では機能しません。
  • 消費するアプリが API とは別のドメインにあるため、クロスドメインが必要ですが、ヘッダーを使用できないため、jsonp を使用できません
  • トークン (のみ) ベースのアプローチは避けたいと思います。

この時点で、URL またはクエリ文字列/ポストを使用してハッシュやその他の変数を提供する HMAC-SHA256 アプローチを採用しています。

これらの変数を URL に入れるのは汚いように思えますし、それらをクエリ文字列/投稿に入れるのは面倒です。

JQuery $.ajaxSetup beforeSend オプションを使用してハッシュを生成し、それをヘッダーに添付することに成功しましたが、前述したように、IE8/9 ではヘッダーを使用できません。

$.ajaxPrefilter に頼る必要がありました。これは、beforeSend で ajax データを変更できず、ajax のタイプに基づいてハッシュの値を動的に計算する必要があるため、$.ajaxSetup でデータを拡張することもできないためです。クエリ。メソッドに依存しない方法で必要な変数を追加するためのクリーンでシンプルな方法がないため、 $.ajaxPrefilter も問題です...つまり、GETの場合はquerystring、POSTの場合はformdataである必要があります

次のソリューションが見つからないため、何かが欠けているに違いありません:- a) クロスドメインをサポート a) MVC と JQuery の両方の側で大規模なハックではない c) 実際に安全 d) IE8/9 で動作する

これをきちんとやっている人がいるに違いない...

編集

明確にするために、API側の認証メカニズムは問題ありません...どの方法でリクエストを検証しても、GenericPrincipalを生成してAPIで使用します(これのメリットは別の投稿用ですが、使用できますMVCの標準的な承認メカニズム。私は自分自身で展開することを好みます... API の他の開発者が学習して維持することはあまりありません)

問題は主に、クライアントから API への認証情報の転送にあります:- - サーバー/API の状態に依存できません。したがって、1回の呼び出しでユーザー名/パスワードを渡し、トークンを取得してから、そのトークンを使用し続けることはできません(リプレイ攻撃の可能性があります)-IEは残りのようにXHRの代わりにXDRを使用するため、リクエストヘッダーの使用を必要とするものはすべてアウトですカスタムヘッダーをサポートしていません(IE10がXHRをサポートしていることは知っていますが、実際にはIE8 +のサポートが必要です)-HMACを生成してURLのどこかに渡す(パスまたはクエリ文字列)が行き詰まっていると思いますが、これこれ用に設計されていないリクエストの一部を使用しているため、ハックのようです-パスを使用すると、少なくとも各リクエストでユーザー名、タイムスタンプ、およびハッシュを渡す必要があるため、多くの面倒な解析があります。

悪いことですが、クエリ文字列/フォームデータが最良の選択肢のようです。ただし、各リクエストでこれらをキャプチャする方法を考え出す必要があります。MessageHandler または Filter を使用できますが、どちらもフォームデータにアクセスするための便利な方法を提供しません。

私は自分ですべての解析と処理を書くことができることを知っています(そしてそうするように見えます)が、要点は、これに対する解決策がまだないとは信じられないということです. (1) IE のサポート、(2) セキュアなコード、(3) クリーンなコードがあり、2 つしか選べません。

4

2 に答える 2

3

あなたの要求は私には少し不当に思えます。すべてを同時に手に入れることはできません。何かを喜んで放棄する必要があります。いくつかのコメント:

  • OAuth は、少なくともいくつかの変更を加えて、ここで必要なもののようです。独自のトークン プロバイダーを実装する必要がないように、Azure の Access Control Service を使用できます。そうすれば、安全なトークン プロバイダーの実装を「外部委託」したことになります。最後に、Azure ACS がまだ無料であることを確認しました。Facebook や Google などの別のプロバイダーにプラグインするために ACS を使用することが多いため、ACS のドキュメントを探すと混乱が生じますが、独自のサービスの単なるトークン プロバイダーになるように調整することもできます。
  • あなたはリプレイ攻撃を心配しているようですね。ほとんどの場合、リプレイ攻撃が発生する可能性があります。SSL 経由であっても、ネットワークを通過するデータをリッスンしてサーバーに送信するだけです。リプレイ攻撃は、とにかく対処する必要があるものです。通常、私が行うことは、今後のリクエストのキャッシュを追跡し、キャッシュにハッシュ署名を追加することです。5 分以内に同じハッシュを持つ別のリクエストが表示された場合は、無視します。これを機能させるために、リクエストのタイムスタンプ (ミリ秒の粒度) と URL の一部の派生物をハッシュ パラメーターとして追加します。これにより、リクエストがリプレイ攻撃としてマークされることなく、同じクライアントから同じアドレスに対してミリ秒ごとに 1 つの操作が許可されます。
  • ハッシュ方式を使用している場合、jQuery について少し戸惑いました。これは、クライアント上に実際にハッシュ アルゴリズムと署名ロジックがあることを意味します。JavaScript を検査するだけで、リクエストに署名してサーバーに送信する方法を正確に知ることができるため、これは重大な欠陥です。
于 2013-02-23T21:15:55.297 に答える
1

簡単に言えば; 認証に関しては、ASP.NET WebAPI に特別なことはあまりありません。

私が言えることは、ASP.NET 内でホストしている場合、ASP.NET による認証と承認のサポートが得られるということです。セルフホスティングを選択した場合は、WCF バインディング セキュリティ オプションを有効にするオプションがあります。

ASP.NET で WebAPI をホストする場合、いくつかの認証オプションがあります。

  1. 基本認証
  2. フォーム認証 - たとえば、任意の ASP.Net プロジェクトから、フォーム認証のために Authentication_JSON_AppService.axd を有効にできます。
  3. Windows 認証 - HttpClient/WebHttpRequest/WebClient
  4. または、WebAPI のメソッドへの匿名アクセスを明示的に許可します
于 2013-02-23T18:06:18.020 に答える