0

インターネット経由でダウンロードした Silverlight アプリによって消費される wcf サービスを作成する必要があります。基本的に、ユーザーは Windows ドメインの一部ではありませんが、資格情報とロールはデータベースに保持されます。

  1. wcf サービスはインターネット対応である必要がありますが、匿名でメソッドにアクセスすることはできません。
  2. 承認もサポートする必要があります\
  3. ユーザー テーブルとロール テーブルが ASP.NET メンバーシップ スキーマに従っていない
  4. 開発者は、IIS をインストールして証明書を構成する必要はありません。
  5. 許可されたユーザーは、関連する情報のみにアクセスできる必要があります。関連会社は削除または更新できますが、他の会社は削除できません。

1と2を達成するために、以下のリンクをたどりました。

Robbin Cremers による WCF セキュリティ

ポイント 3 をカバーするために、MembershipProvider クラスと RoleProvider クラスのカスタム実装を提供し、ValidateUser メソッドと IsUserInRole メソッドをそれぞれオーバーライドして、独自のスキーマ ユーザーとロール テーブルから取得しました。

これまでのところ、優れた認証と承認はうまく機能しています。

問題は、開発者が IIS をインストールして証明書を構成できないため、開発モードでこれを無効にする必要があることです。したがって、開発モードまたは運用をチェックし、カスタム IPermission または PrincipalPermission を使用するカスタム CodeAccessSecurityAttribute クラスを実装しました。

[質問 1] 私の質問は、人々がこのアプローチを推奨している場所はどこにもないということです。そのため、これが正しいアプローチなのか、それともこの状況を処理するためのより良いアプローチなのかを少し心配しています。

[質問 2] 最後にポイント 5 に関連して、何らかのトークンを送信する必要がありますか? これに最適なアプローチは何ですか？

[質問 3] Robbin Cremers メソッドのパフォーマンスへの影響。サービス呼び出しごとに、認証と承認のために "ValidateUser" と "IsUserInRole" で 2 つの追加のデータベース呼び出しが行われるためです。より良い方法はありますか？

大きな質問で申し訳ありません。

4

1 に答える 1

0

シナリオの説明からわかる限り、カスタム メンバーシップ/ロール プロバイダーを作成して接続したら、Message Security は実際には必要ありません。代わりに、http://msdn.microsoft.com/en-us/library/dd560702(v=vs.95).aspx で説明されている標準的なアプローチ(または http://msdn.microsoft.com/en) が問題なく機能します。 -us/library/dd560704(v=vs.95).aspx (通常の Web ページではなく、Silverlight アプリを介してユーザーにログインさせたい場合)。次に、ブラウザーは必要なトークンの送信を自動的に (Cookie を介して) 処理します。ASP.NET は認証/承認の結果をキャッシュするのが賢明なので、すべての呼び出しでオーバーヘッドが発生することはないと思います。

于 2012-12-17T05:23:37.847 に答える