2009-04-08 25 views
1

我正在修改的應用程序有一個Web服務,並且該Web方法上的一個Web方法用於根據活動目錄對用戶進行身份驗證。因此,通過的authenticateUser Web方法稱爲當前的代碼看起來是這樣的:針對Active Directory進行身份驗證的Web服務的安全密碼解決方案?

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... 
} 

當我開始看這個代碼,這令我擔心的第一件事就是參數的Web方法是這樣的:

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

因此,當請求發送到service.asmx頁面時,當前Web服務正在期待一個密碼字符串,推測爲通過網絡以明文的形式作爲XML發送。

有沒有人處理過這類問題?我可以使用替代的Active Directory身份驗證機制來避免傳遞純文本密碼嗎?我可以自己想出的最佳選擇是使用加密密碼調用WebMethod,並讓另一方的代碼對其進行解密。但是,我更喜歡更好的解決方案 - 例如:是否有某種方式使用單向散列而不是密碼來搜索DirectoryEntry?

編輯:

其他細節:爲了這一點,我還沒有考慮過SSL,因爲這是一種工具,是內部的公司,因此它似乎矯枉過正,可能有問題(這是將在公司內部網上運行,而不是外部可見)。我甚至擔心發送純文本密碼的安全性的唯一原因是,即使在企業內部網上,惡意軟件的數量也在不斷增加(可能是密碼嗅探)。

回答

0

對於我們的特殊情況,因爲客戶端和Web服務都在我們公司的Intranet上運行,所以可能適用於我們的解決方案是使用集成Windows NTLM身份驗證處理客戶端上的身份驗證,然後只需讓客戶端向Web服務提供憑據即可。下面是客戶端代碼:

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

Web方法現在看起來是這樣:

[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服務,其他答案之一是更好的解決方案。

欲瞭解更多信息,請參見:

4

如果您有公鑰/私鑰組合,則客戶端可以使用公鑰進行加密,然後使用私鑰進行解密。

但是,這對客戶來說太多了,而不是一種非常「網絡方法」的方式。

由於您將用戶名和密碼作爲參數發送,因此基本上應採用傳輸安全性HTTPS,這要求您從可信證書頒發機構向您發佈公鑰/私鑰組合。


應該注意的是,您的SSL加密通道與面向外部的站點的關聯不正確。想要加密頻道的目的是防止中間人攻擊,就像你在這裏試圖做的一樣。

您可以使用自行頒發的證書,但需要在要調用Web方法的每臺計算機上安裝證書的公鑰。從一個可信任的機構獲得一個更容易。

+0

我已經處理過自己頒發的證書路徑,而且很難按照您的建議進行維護。我可能需要通過公司的IT渠道來獲得來自可信機構的「真實」SSL證書,但這可能是正確的。 – 2009-04-08 20:29:31

+0

重新發布自己的證書 - AD可以發佈您的機器。它將被域中任何其他機器自動信任。 – 2009-04-08 23:08:31

+0

我不知道馬克 - 這是很好的信息。我可能還需要得到批准,因爲AD服務器是爲整個公司服務的(當然),並且不在我們部門的範圍之內。但聽起來好像通過公司渠道更容易做到這一點。 – 2009-04-09 17:46:42

0

我們將AD服務放在自己的網站上,並獲得了SSL證書。問題解決了。

0

我認爲SSL或IPSec可能是您最好的解決方案。

1

HTTPS(如上所述)是簡單的選擇。或者,您可以讓IIS通過摘要或NTLM處理身份驗證。您的應用仍然可以制定授權規則。 NTLM是安全的,但它會傷害你的互操作性。否則,AD確實提供了一些摘要式身份驗證方法,但我沒有使用它們測試代碼。

使用Server 2000域時,可以選擇「以可逆格式存儲密碼」 - 這將允許域控制器計算密碼的MD5哈希以與您提供的MD5哈希進行比較。 MS認識到這是一個安全問題,所以Server 2003實現了「高級」摘要認證 - 它預先計算了散列。

LDAP登錄應選擇MD5摘要作爲身份驗證類型,提供用戶名,然後提供密碼的MD5哈希。正常的LDAP客戶端可能會自己想MD5你的密碼,所以你必須自己重寫或製作它們。

相關問題