Active Directoryを認証するWebサービスのための安全なパスワードソリューションですか？

Question

私が修正しているアプリケーションにはWebサービスがあり、そのWebメソッド上のWebメソッドの1つは、アクティブディレクトリに対してユーザーを認証するために使用されます。だから、のauthenticateUserウェブメソッドによって呼び出され、現在のコードは次のようになります。

string domainAndUsername = aDomain + @"\\" + username; 
string ldsPath = buildLdsPath(searchBase); 
DirectoryEntry entry = new DirectoryEntry(ldsPath, domainAndUsername, 
    password); 

try 
{ 
    //Bind to the native AdsObject to force authentication. 
    object obj = entry.NativeObject; 

    DirectorySearcher search = new DirectorySearcher(entry); 

    search.Filter = "(sAMAccountName=" + username + ")"; 
    search.PropertiesToLoad.Add("cn"); 
    SearchResult result = search.FindOne(); 

    // more code to validate the result, etc... 
} 

私はこのコードを見始めたとき、私を心配まず最初に、ウェブメソッドの引数は次のようになります：

[WebMethod] 
public ResultObj AddRole(string roleToAdd, string username, string password) 
{ 
    // code that calls above Authentication fragment... 
} 

だから、現在のWebサービスは、要求がservice.asmxページに行われているXML、などのネットワークを介してクリアなに送られたパスワード文字列、おそらくを期待しています。

誰もこのタイプの問題に対処していますか？プレーンテキストのパスワードを渡すことを避けるために使用できる別のActive Directory認証メカニズムがありますか？私が自分自身で思いつくことができる最良の選択肢は、暗号化されたパスワードを使ってWebMethodを呼び出し、反対側のコードでそれを解読することです。しかし、私はもっと良い解決策を望んでいます。たとえば、パスワードの代わりに一方向ハッシュを使ってDirectoryEntryを検索する方法はありますか？

編集：

追加詳細：ここまで私は、これは私たちの会社の内部にあるツールであり、それはやり過ぎのように思えるようSSL考えられ、おそらく問題にしていない（これ会社のイントラネット上で実行され、外部からは表示されません）。私がプレーンテキストのパスワードを送信することの安全性についても心配している唯一の理由は、最近、企業のイントラネット上に存在するマルウェア（パスワードを盗む可能性がある）

Answer 1

クライアントとWebサービスの両方が当社のイントラネット上で実行されているため、私たちのために役立つソリューションは、統合Windows NTLM認証を使用してクライアント側の認証を処理し、クライアントからWebサービスに資格情報を提供させるだけです。ここでは、クライアントコードは次のとおりです。

public void AddRole(string roleName) 
{ 
    webSvc.Credentials = CredentialCache.DefaultCredentials; 
    // Invoke the WebMethod 
    webSvc.AddRole(roleName); 
} 

ウェブメソッドは次のようになります：

再び

[WebMethod] 
public ResultObj AddRole(string roleToAdd) 
{ 
    IIdentity identity = Thread.CurrentPrincipal.Identity; 
    if (!identity.IsAuthenticated) 
    { 
     throw new UnauthorizedAccessException(
       ConfigurationManager.AppSettings["NotAuthorizedErrorMsg"]); 
    } 
    // Remaining code to add role.... 
} 

を、私は、サーバーがクライアント、および両方の話を信頼している場合、このソリューションは、おそらくのみ動作します強調する必要があります同じActive Directoryサーバーに移動します。パブリックWebサービスの場合、他の答えの1つがより良い解決策になるでしょう。詳細については

、以下を参照してください

• Microsoft Support Article on passing credentials
• MSDN Article on Building Secure Applications
• MSDN Article on Windows Authenticationを - 正確に必要なWindowsのプリンシパルとアイデンティティオブジェクトを使用するWebサービスの設定に関する情報が含まれています。

Answer 2

公開鍵/秘密鍵の組み合わせがある場合、クライアントは公開鍵で暗号化し、秘密鍵で復号化することができます。

しかし、これはクライアントにとってあまりにも多くの作業であり、あまり「ウェブメソッド」のやり方ではありません。

ユーザー名とパスワードをパラメータとして送信するため、基本的にトランスポートセキュリティであるHTTPSを使用する必要があります。これは、信頼できる認証局からパブリック/プライベートキーの組み合わせを発行する必要があります。

---

SSL暗号化チャネルと外部サイトの関連付けが間違っていることに注意してください。チャネルを暗号化したいという要点は、あなたがここでやろうとしているのとまったく同じように、中間者の攻撃を防ぐことです。

自己発行の証明書を使用できますが、Webメソッドを呼び出す各マシンに証明書の公開鍵をインストールする必要があります。信頼できる機関から取得する方が簡単です。

Answer 3

私たちは自分のウェブサイトに私たちのADサービスを置き、SSL証明書を手に入れました。問題が解決しました。

Answer 4

おそらく、SSLまたはおそらくIPSecは、おそらくあなたの最善の解決策だと思います。

Answer 5

HTTPS（前述のように）は簡単な選択です。または、IISにダイジェストまたはNTLMによる認証を処理させることもできます。あなたのアプリは依然として承認ルールを作ることができます。 NTLMは安全ですが、相互運用性を損なうことになります。さもなければ、ADはいくつかのダイジェスト認証方法を提供しますが、私はそれらを使ってテストされたコードを持っていません。

Server 2000ドメインには、「パスワードをリバーシブル形式で保存する」というオプションがあります。これにより、ドメインコントローラは、提示されたMD5ハッシュと比較するためにパスワードのMD5ハッシュを計算できます。しかし、MSはこれが少しセキュリティ上の問題であることを認識しました。そのため、Server 2003は「高度な」ダイジェスト認証を実装しました。これはハッシュを事前計算します。

LDAP signonは、認証タイプとしてMD5ダイジェストを選択し、ユーザー名を指定して、パスワードのMD5ハッシュを指定する必要があります。通常のLDAPクライアントはおそらく自分のパスワードを自分自身でMD5にしたいと思うでしょうから、あなた自身でオーバーライドしたり工夫したりする必要があります。