WCF 経由で認証を実装する最良の方法は何ですか?
WS-* はトランスポートに依存しない必要があるため、使用しないことをお勧めします。
「自分で巻く」べきですか?それを行うためのガイダンスはありますか (記事/ブログ投稿)?
または、組み込みの ASP.NET メンバーシップおよびプロファイル プロバイダーをサーバー側で使用する方法はありますか?
WCF 経由で認証を実装する最良の方法は何ですか?
WS-* はトランスポートに依存しない必要があるため、使用しないことをお勧めします。
「自分で巻く」べきですか?それを行うためのガイダンスはありますか (記事/ブログ投稿)?
または、組み込みの ASP.NET メンバーシップおよびプロファイル プロバイダーをサーバー側で使用する方法はありますか?
WS-Security ベースのメッセージ ベースの認証は、あなたが探しているものであり、basicHttpBinding と netTcpBinding によって確実にサポートされています。WsHttpBinding だけが WS-Security をサポートするという誤った仮定をしていると思いますが、これは不正確です。
WS バインディングは、WS-ReliableMessaging など、WS-Security 以外の WS-* 要素用です。安全性を維持したい場合、トランスポートに依存しないメッセージ セキュリティの設定は依然として難しいものです。二重化されていないトランスポートについては、事前に少なくとも 1 つの証明書を交換する必要があります。
これが、メッセージ セキュリティが basicHttpBinding でサポートされていないと思われるもう 1 つの理由かもしれません。basicHttpBinding では、トランスポート セキュリティなしで UserName 認証を使用することはできません (正当な理由も追加します)。そして、トランスポートセキュリティは本質的にトランスポートに依存しているため、あなたはそれを避けようとしていると思います.
とにかく、完全にトランスポートに依存しないようにしたい場合、最初に取り組む必要があるのは、証明書を順番に取得し、最初の (ルート) 証明書を配布する方法、または証明書を安全に交換する方法を理解することです。マスター証明書を配布できるアプリケーションの余裕がある場合は、そのルートを選択してください。それよりも複雑なシナリオにいる場合は、一歩下がって、この問題が実際にどれほど難しいかを考える必要があります。
WS- *がトランスポートに依存する必要があるのはなぜですか?
WS- *仕様の要点は、それらがメッセージの一部であり、したがってトランスポートに依存しないことです。
回答ありがとうございます。
私は輸送に依存するという意味ではありませんでした、私の間違いです。私は、コンシューマーがバインドするエンドポイントを選択できるようにしたいと考えていました。また、basicHttpBinding と netTcpBinding などは WS-* をサポートしていないため、サービス レベルで何かを使用する必要があります。
Davids の単純な認証は、私が避けようとしてきたものです。理想的には、すべての操作コントラクトにトークン引数を追加することなく、同じことを達成する方法が必要です。
WS-* はトランスポートに依存しません。それが要点です。
認証は、サービスの必要な利用者が誰であるかによって異なります。必要のないセキュリティで内部サービスを圧迫しないでください。同様に、サードパーティのユーザーについて特定のことを知る必要がある場合は、セキュリティのレイヤーを追加すると便利です。
外部 API については、証明書を使用した WS-* 認証を使用してから、単純な認証メカニズムを使用しました (ユーザー名とパスワードが提供され、GUID 認証トークンが返され、事後にすべての要求と共にトークンが提供されます)。
ユーザー レベルの認証/承認を必要とする外部サービスを公開している場合は、ASP.NET プロバイダーを使用することをお勧めします。
ここには、ASP.NET プロバイダーのリモート管理を可能にする便利なユーティリティがあります。ASP.NET ソリューションには SQL が必要です...