既知のクライアントが使用できるパブリック WCF サービスを実装する必要があります。また、カスタム ID (Windows 認証ではなく) を使用してクライアントを認証したいと考えています。
カスタムのユーザー名とパスワードを使用した認証のための WCF セキュリティを調査しました。異種ネットワークのソリューションを実装する必要があるため、Windows 認証を使用できません。
カスタム認証を WCF に組み込む方法は 2 つあります。以下のように、各アプローチについていくつか質問があります。
1)「UserNamePasswordValidator」クラスを介して。カスタム ユーザー名パスワード バリデーターを作成し、データベースからユーザーを検証できます。このアプローチは、各リクエストが SOAP ヘッダーに資格情報を持っているため、SSO (シングル サインオン) を実装するのに最適です。クライアントは、各リクエストの前に自分自身を検証する必要はありません。
質問:
- このアプローチは承認に対しても簡単に拡張できますか? 認証は、SOAP ヘッダーから資格情報を取得することにより、サービス呼び出しの前に行われるためです。また、資格情報は ObjectContext の一部ではありません。承認のアプローチは簡単ではないと感じています。
- このアプローチに従うには、ブローカー認証パターンを使用する必要があり、そのためにはサード パーティの証明書が必要です。プロジェクトで証明書のコストを追加する必要があるため、このアプローチを採用することはお勧めですか。
- メッセージ セキュリティを使用してメッセージを暗号化する場合、なぜ証明書が必要なのでしょうか? クライアントのアイデンティティのためだけですか？誰がこのサービスを利用するかを知っているので、本番環境で自己署名証明書を使用することはできませんか?
2)「ServiceAuthenticationManager」クラスを介して。このクラスを使用するアプローチは 1 つだけ知っています。それは、直接認証パターンを使用してソリューションを実装することです。また、ユーザーを認証した後、SSO (シングル サインオン) を実装するためにサービスに送られる後続のすべての要求に対して、カスタム ヘッダーを介してその ID またはトークンを提供する必要があります。
質問:
- これは公共サービスにとって有効なアプローチですか？各リクエストのカスタム ヘッダーを介して、資格情報 (またはサービスが認証された後にサービスによって提供されたトークン) を提供するようにユーザーに強制する必要がありますか?
- このアプローチは認証を必要としないため、プロジェクトのコストを節約できます。これは、このアプローチを選択する十分な理由ですか?
個人的には、最初のアプローチは実装が簡単で、WCF サービスで認証を実装するためのより標準的な方法だと思いますが、唯一の問題は、サードパーティの証明書が必要なことです。
私の質問に答えてください。可能であれば、私の要件に最適なアプローチを提案してください。
ありがとう、
アンクル