2

ASP.NET と Flex で記述された Web ベースのアプリケーションを構築しています。私の最大の課題の 1 つは、柔軟で保守可能な方法でアプリケーションのセキュリティを実装することです。この課題は、さまざまなテクノロジーが関与する場合に複雑になります。私が持っているものを以下に説明しようとします。

Web サイトは次のように構成されています。

  • /mydomain.com/
    • ログイン.aspx
    • Default.aspx (ホスト フレックス [.swf] アプリケーション)
    • /管理/
      • AddUsers.aspx
      • AddRoles.aspx
      • AddPermissions.aspx
      • 等...
    • /サービス/
      • SecurityService.asmx
      • MapService.asmx
      • PhotoService.asmx
      • 等...

現在、フォーム認証を使用して Web サイト上のリソースを保護しています。/Services/ フォルダーにないすべてのページ/リソースは、認証されたユーザーを必要とし、まだ認証されていない場合は Login.aspx にリダイレクトされます。.asmx ページは、認証されていないユーザーを許可します。これらのリソースを保護するために、SOAP メソッドで例外をスローします。これにより、私が認識している SOAP Web サービス クライアントでサポートされていない SOAP Web サービスのページをリダイレクトすることを回避できます。最後に、SecurityService.asmx には、何らかの理由で Cookie の有効期限が切れた場合に、Flex アプリケーションが Login.aspx ページにリダイレクトせずにログインできるようにする Login メソッドが含まれています。確立された Cookie は、Flex アプリケーションからの要求を含め、サーバーへのすべての要求と共に送信されるため、これはかなりうまく機能しているようです。

ただし、これは依然として、Web サービスを保護するための悪いアプローチのように感じられます。意図されていない目的でフォーム認証を使用しているように感じます。具体的には、次の点が懸念されます。

  • このモデルは、サービスがコア Web サイトから分離されている場合には機能しません。これは新たに発見された要件であり、フォーム認証は、さらに多くの変更やトリックを行わなければ (まったく機能しないとしても) うまく機能しないと私は信じています。
  • Flex 以外のクライアントは、サービスへのアクセスを必要とする場合があります。これらのクライアントの中には、Cookie を使用できないものもあります。もしそうなら、このモデルはすぐにバラバラになります。これは当面の要件ではありませんが、長期的な目標の 1 つであることがわかっています。
  • 最終的には (願わくば遅かれ早かれ) REST ベースのアーキテクチャ (対 SOAP) に移行する予定なので、どのソリューションも SOAP と REST で機能する必要があります。

それで、私の質問はです。

ASP.NET、Flex、および SOAP または REST Web サービス上に構築されたアプリケーションを保護するための最適な認証および承認メカニズムは何ですか?

注: 私は積極的に OAuth を検討しています。ただし、学習する完全な例を見つけるのに苦労しています。さらに、ユーザーが持っているアクセス許可に基づいて、特定のユーザーに対して返されたデータをフィルター処理できる必要があります。OAuth はトークンからユーザーの ID を削除するようです。そのため、きめ細かいセキュリティ モデルで OAuth がどのように適用されるかはわかりません。

4

6 に答える 6

1

他の人は同意しないかもしれませんが、私は実際にあなたが今のようにそれを扱うことに大きな問題があるとは思いません。それがおそらく、少なくとも最初は自分自身を処理する方法です。何らかの方法で、将来的にも、おそらく Flex アプリにセッションの認証状態を認識させたいと思うでしょう。それが ASP.NET セッション トークンを直接チェックすることを意味する場合、または認証時に設定した他の Cookie をチェックすることを意味する場合それを設定すると、うまく信頼できる方法のように思えます。

サービスのリダイレクトについてあなたが何を意味するかはわかりますが、それでもフォーム認証では、ASP.NETアプリ自体ほどリダイレクトを処理しているのはサービスではありません。後で別の認証方式を使用する必要が生じた場合は、その方式の特定の実装に関する考慮事項を考慮することができます。一般的にフォーム認証を使用することに懸念がある場合を除き、Flex クライアントと Web サービスがあるという理由だけでアプローチを複雑にする必要はおそらくないでしょう。

于 2009-02-12T17:06:49.323 に答える
0

Webサービス認証-ベストプラクティスを参照してください。

デイブダンキンは書いた:

さまざまなプラットフォームでこれを処理する最も簡単な方法は、トランスポート層にHTTP基本認証とHTTPSを使用することです。WS-Securityは、ニーズが単純なユーザー名/パスワードを超えている場合に適していますが、サポートはプラットフォーム間でかなり異なります。HTTP認証は、すべての適切なSOAP実装でサポートされています。

および.NET3.5/VS2008上のASP.NETWebサービスのカスタムHTTP基本認証

于 2009-03-19T07:39:29.530 に答える
0

ユーザーとバックエンドの認証トークンの間に関係があるとしても、独立した認証システムを持つことが最善だと思います。それらは、異なる能力と要求を持つ異なる獣です。

flex 部分には通常のフォーム ベースの認証を使用します。それはいいです。

Web サービスの場合、後続のタスクが実行するために使用される認証トークンを返すログイン メソッドを作成できます。または、Web サービスにいくつかのフィールドを追加して (ヘッダーまたはパラメーターとして投稿)、毎回認証にユーザー ID/パスワードの組み合わせを使用します。

補足: 認証の問題を処理するために SOAP 例外に依存するつもりはありません。ただし、WS 要求で認証トークンまたはユーザー/パスを送信する場合は、リダイレクトについて心配する必要はありません。

編集: RE: コメント - 理想的にはあります。これらのニーズに対応する製品 (Tivoli Access Manager) がありますが、それらは高価です。

代替クライアントへのアクセスを許可するという苦痛を軽減し、サービスを正しく設計している限りステートレスであるため、この推奨事項を示しました。また、サービス側のデータ レベル アクセスをより細かく制御できます。

于 2009-03-11T19:49:18.340 に答える
0

CodePlex で公開されているWCF セキュリティ ガイドは、WCF を使用している、または使用できる場合に役立ちます。

Microsoft の Web Services Enhancements (WSE) 3.0もあり、WS-* セキュリティ仕様の一部を実装していると思われます。

それが役立つことを願っています。

于 2009-03-12T01:20:27.997 に答える
0

Web サービスをあまり扱っていないことは認めますが、アクセス キーを SOAP ヘッダー パラメータとして要求することについてはどうでしょうか。SOAP Web サービスと通信できるすべてのクライアント アプリには、SOAP リクエストを変更するための低レベル API が含まれている可能性が高く、アクセス キーを使用すると、(理論上は) サービスの使用を制限できます。Google、Amazon、および他のいくつかのプロバイダーは、Web サービスにこのタイプの認証を使用しており、非常にうまく機能しているようです。

この記事は、開始するのに適した場所のように思われます...

于 2009-03-08T16:46:04.297 に答える