4

Web サイト (MVC4/シングル ページ アプリケーション + ノックアウト + Web.API) を実装する必要があり、大量の記事やフォーラムを読んできましたが、セキュリティ/認証のいくつかのポイントとその方法についてまだ理解できません。ログインページと Web.API を保護するときに先に進みます。

サイトは完全に SSL で動作します。ユーザーが初めてログオンすると、登録プロセスを確認するためのリンクが記載された電子メールが送信されます。パスワードと「salt」値は暗号化されてデータベースに保存され、パスワードが解読される可能性はありません。この API は、このアプリケーション専用に使用されます。

さらに先に進む前に、いくつかの質問に答える必要があります。

  1. セキュリティの観点から、どの方法が私のアプリケーションに最適でしょうか: Basic/SimpleMembership? 他の可能性はありますか？
  2. オブジェクト Principal/IPrincipal は基本認証だけで使用されますか?
  3. 私の知る限り、SimpleMembership を使用すると、Cookie が使用されるため、これは RESTful パラダイムを壊していませんか? では、REST Web.API を構築する場合、SimpleMembership の使用を避けるべきではないでしょうか?
  4. トークンを使用して、ThinkTecture.IdentityModel をチェックしていました。これは Basic、Forms、Auth などの認証タイプですか、それとも他の認証タイプに追加できるものですか?

ありがとうございました。

4

2 に答える 2

4

ほとんどの場合、この質問はローカライズされすぎているためクローズされます。それでも、いくつかのポインタを入れます。これは答えではありませんが、これにはコメント セクションが小さすぎます。

  1. 認証方法と認証方法は、完全にサブシステム次第です。誰にとっても最善の方法はありません。SPA は他のアプリケーションと同じです。認証に基づいて特定のリソースへのアクセスを引き続き許可します。それは、カスタム Authorization 属性を持つ API である可能性があり、トークン ベースのヘッダー値である可能性があります。どう考えても最高です。
  2. これがどのように機能するかを理解するために、これについてもっと読むことをお勧めします。
  3. Cookie の使用は、REST を壊すとは決して言いません。この特定のアイテム自体に関する記事がたくさんあります。Cookie は、サーバーがデータを提供するために必要な特定の情報を渡すのと同じように、リクエストと共に渡されます。Cookie を送信すると REST が壊れる場合、API にパラメーターを送信すると REST も壊れるはずです。
  4. 現在、非常に一般的なアプローチ (決して ONE AND ALL アプローチではない) は、SPA にトークン ベースのシステムを使用することです。多くの場合、説明するのが最も簡単な理由は、サービス (Web API など) を個別にホストでき、クライアントが CORS クライアントとして機能するためです。その場合、選択した任意の形式で認証し、安全なトークンを作成してクライアントに送り返します。認証されたユーザーを必要とするすべてのリソースがトークンに対してチェックされます。トークンは、リクエストごとにヘッダーの一部として送信されます。単純な 401 (未承認) になるトークンがないか、無効なトークンが 403 (禁止) になる可能性があります。

SPA がすべて静的な HTML である必要があると言う人はいません。データ バインディングを使用する必要があります。MVC サイトがロードされているパーシャルを返す可能性もあります (私が過去に行ったことがあります)。HTML と JS (具体的には Durandal) だけで作業する限り、クライアント アプリも保護する方法があります。最終的に、サーバーからのデータをロックダウンし、401/403 を受信した瞬間にクライアントをログイン画面にルーティングします。

XSS やリクエスト フォージングに関して懸念がある場合は、HTML と JS だけでもそれを防ぐ方法があります (ただし、MVC で偽造防止トークンをドロップするほど簡単ではありません)。

私の2セント。

于 2013-04-29T17:07:44.577 に答える