Wcfサービスをホストしました
ユーザーが自分のユーザーアカウントにログインすると、それがwcfサービスの最初のレイヤーのセキュリティになります。これは通常のWindowsログイン認証です。Wcfサービスにアクセスする前に第2層のセキュリティを提供したいと思います。第2層のセキュリティは、ユーザー名の確認またはユーザー名とパスワードの確認です。さらにもう1つ、第2層のセキュリティでは、ユーザーが現在ログインしているユーザーと同じである場合、認証を要求しません。それ以外の場合は、第2層のセキュリティの一部として認証を要求します。
このロジックをどのように実装する必要がありますか？
ここで読むことができるカスタム資格情報による認証について質問していると思います
答えは、WCF サービスを Web サーバーのように (REST、BasicHttpBinding、WSHttpBinding、または WebHttpbinding を使用して) 使用しているか、または NetNamedPipeBinding のようなよりネットワークに似たプロトコルを使用しているかによって異なります。ネットワークのようなプロトコルを使用すると、ユーザーがサインインした後、必要なだけ持続するライブ セッションを確立できます。
ただし、Web 中心のプロトコルの 1 つを使用していると仮定すると、1 番目、2 番目、n 番目のセキュリティ層を実際にセットアップすることはできません。ユーザーがサービスにアクセスする前にユーザーをキャッチするカスタム資格情報リスナー (Paramosh が指すものなど) を送信できますが、それだけです。認証イベントとリクエストがファンに到達するまでの間に、いわばそれ以上のイベントはありません。
したがって、これは私が提案するものです: http通信はほとんどの場合、要求と応答の繰り返しセットであるため、最初の連絡で認証を行い、(資格情報を送信した後) ユーザーに SessionID (GUID) トークンを与えます。あなたが望む限りで戻ることができます。SessionID トークンは DB のどこかに保存する必要があり、その後の訪問のたびに、ユーザーは検証のためにそのトークンを提示する必要がありますが、その後、望ましくない侵入を防ぐライブ セッション シナリオが効果的に得られます。そして、この SessionID (または使用するもの) は、上記のカスタム資格情報関数によって確認できます。