2011-01-07 12 views
1

Webサービス、データ(画像、メディアなど)を提供する状況があり、適切なSilverlightクライアントによってのみアクセスできるようにセキュリティを確保する必要があります。多くの人がいるかもしれません。ある人はいくつかのメディアにアクセスし、ある人は他の人にアクセスすることができます。SilverlightクライアントからWCF Webサービスへの認証+ Authroizing

Webサービスが存在し、現在は.asmxですが、これをWFCにアップグレードします。

はこれまでのところ、WCFと認可に関するブログをたくさん読んだ後、私はこのアイデアに来ている:

  1. それぞれのSilverlightクライアントは、その設定のどこかでクライアントキーを持っています。
  2. WebサービスサーバーはSSLで保護されているため、クライアントIDはWebサービスパラメータとして暗号化されています。
  3. 認証はクライアントキーを使用して行われます。
  4. 承認はクライアントキーを介して行われます。

私が見る限り、私はと考えています。これは安全であるべきですが、気をつけてください!

私の研究ではバグが唯一のものですが、認証と認可にWCFを使用することには非常に有利ですが、私には必要なだけ複雑すぎると感じています!複雑なクライアント設定ファイルが、WCFサービスにアクセスするSilverlightアプリケーションのためにどのように機能するかを理解してください。

いずれにせよ、私の理解から、WCF認証を使用するには、どちらかといえば素敵なクライアントキーを提供するだけで、少なくともユーザー名とパスワードまたは証明書が必要です。

私のアイデアは安全で賢明なように見えるのですか?フレームワークがより良い解決策であるため、私はWFCの学習を続けるべきですか?

セキュリティのWCFフレームワークが優先される場合は、Webサービスを保護するためにどのようなフローを必要とするかについて、高いレベルのアドバイスがありますか?

聴覚障害者のアドバイスと経験を楽しみましょう! :)

ありがとう!

アンディ

答えて

0

Silverlightはクライアント側の技術であるので、ユーザのコンピュータでのSL制御とその設定ストアの両方ので、この方法では、セキュアではありません。誰でも自由にアクセス/変更が可能です。
カスタムセッションは、あなたのタスクを処理するための最も安全な方法です。
例:
認証/承認は、標準(またはカスタム、いくつかの特定のプロバイダを実装するには気軽に)役割/メンバーシッププロバイダを使用して実装できます。クライアントが認証されると、サーバーが生成したセッショントークン(guidなど)を受信します。同じguidは、サーバー側のデータベースに格納されます(たとえば、すべてのロール、ユーザーなどを格納するデータベース)。
各セッショントークンには有効期限があります(期限切れのキーをデータベースから削除するには、DBエージェント/タスク/スケジューラを使用します)。
クライアントがリソースを要求するたびに、セッショントークンと他のリクエストパラメータをサーバーに送信します。 DB内の同じセッショントークンの要求サーバー検索を受信した後、トークンが存在する場合は、要求されたリソースへのアクセスを提供します。さもなければ認証は失敗する。

カスタムセッションは非常に複雑ですが、同時に認証操作を処理するための最も安全な方法です。あなたがそれについて何か質問があるなら、私に尋ねてください。

+0

ああ、SLについての良い点はクライアント側です!その意味を完全に忘れてしまった。私はあなたのアイデアを理解していると思う、私はもう少し月曜日にそれについてもう少し考えなければならないだろう! :) – Andy

関連する問題