我正在創建一些我希望使用自定義（即非WS-Secure等）方法來保護的Web服務。目前我的計劃是要有一個方法，它採用活動目錄用戶名&密碼（當然是通過HTTPS）來驗證用戶。然後，此方法將獲得該用戶的帳戶SID，並使用安全但可逆的方法對其進行加密，並將其作爲安全令牌傳回。使用Windows帳戶SID作爲安全令牌
之後，調用者將加密的令牌作爲參數傳遞給每個Web方法，以此確保調用者通過身份驗證。該令牌然後可以被解密並且相當平凡地轉回到目錄條目（並且因此確認它們的真實性）。這有額外的好處，允許方法絕對識別認證的調用者。
但是，使用通常只在內部使用的帳戶SID讓我有點擔心。這是安全的嗎？
編輯：正如我在下面的評論中所述，我已經意識到令牌需要「會話化」 - 即它需要過期以減少令牌重用的可能性。這可能會通過將客戶端會話保持爲令牌的一部分來處理。
右鍵，在這裏去 - 這是一個很長的答案...
與這樣將是持續的SID不會足以能，如果你需要進行重新驗證用戶的問題代表他們行動（即模仿該用戶） - 因爲您需要一個操作系統提供的安全令牌。如果你只有SID，你仍然需要在這種情況下的密碼 - 除非你在你的AD商店使用可逆加密，我認真懷疑是這種情況 - 當然希望它不是！
除此之外，還有一個問題，即一旦您加密該SID並將其發回，它可能會安全地通過網絡（只要我們假設HTTPS始終是安全的），但是一旦它處於客戶機。
有人可以竊取加密的SID並開始提出請求，就好像它們是該用戶一樣。
在我看來，如果您使用AD作爲後端身份驗證存儲，那麼您應該只使用協商或Kerberos身份驗證。如果需要的話，它生成的票據可以用來模擬用戶;我不相信它們會被盜（儘管在安全領域，幾乎任何技術上都是可行的）。
但是，您可能會使您的Web服務非常難以使用這樣做 - 我當然不會想到爲這些協議編寫自己的客戶端。
之前我說我可以做什麼，如果我面臨着這個問題，我會說：第一，它不是真的安全 - 這是有人棘手只是有點亂用，同時也消除令牌的關聯實際用戶（加密信息背後的模式是黑客最好的朋友）。還有其他注意事項，我列出算賬：
使用AD作爲身份驗證方法，但沒有更多的，跟蹤認證會話分開，並給他們唯一的密鑰不直接涉及到AD的SID - 的GUID什麼像那樣。這樣，每次用戶進行身份驗證時，他們將獲得不同的核心會話ID。
我會戳它的創建，以及加密的安全獨特隨機鹽（隨機數的時間每個會話 - 雖然它沒有被用在這裏是wikipedia描述同樣的方式使用RNGCryptoServiceProvider此）。我也會在其中包含一些（但不是全部）關於客戶端（ip，用戶代理）的信息。
我然後第一構造的令牌作爲字符串組合所有這些信息在一起，然後用加密它也許至少的RijndaelSymmetricAlgorithm執行具有128位的IV和256位密鑰（兩者必須保持非常安全，並應該使用RNG再次隨機生成！）。
您發回給客戶端，他們在接下來的請求中使用它（直到它過期 - 它絕對必須這樣做）。
當您收到令牌你
驗證會話永遠不應該是開放式的 - 它們應該有過期時間以防止能夠使用舊的令牌。
毫無疑問，當然要使用HTTPs。
所有這一切 - 你的選擇認證等應該正比於傳輸的數據的種類和人們可以做的事情。如果黑客不會對您的服務感興趣，或者如果環境完全是內部的，那麼就用你最初的想法開始。
（這是到無限存在的力量）
雖然我建議這個解決方案，它是不安全的原因很多，如果有任何真正的祕密參與我不會使用它。
它依靠HTTPS向客戶端驗證服務器 - 在客戶端交出其用戶名和密碼組合之前，這非常重要。拿走它，它會中斷，如果你操縱客戶端計算機上的證書鏈，也可以完全避開。它還依靠HTTPS通道來保護傳輸中的用戶名/密碼組合。
我們應該進一步去和引進信息編號和對請求籤名，以確保客戶是仍然他們展示自己誰是因爲IP地址和頭很容易被欺騙。在考慮到HTTP之前，我們也應該考慮使用大素數和所有jazz進行密碼傳輸的非對稱加密。因此，基本上，如果它是安全關鍵的 - 忽略我並諮詢專家 - 不要嘗試自己推出，因爲你會錯的。
如果你只是被一個12歲的怪胎黑客攻擊，而沒有其他原因，那是因爲那是12歲的孩子，那麼我的解決方案可能太重了，你最好還是跟着你的想法。
無論哪種方式 - 我並沒有可以/可能會發生什麼保修，我想在某種程度上，這現在很長的回答實際上是說，你既聽我不理我，後果自負:)
謝謝很長的考慮的答案。發佈之後，我意識到需要將令牌會話過期。也許我應該更新這個問題，以防有任何進一步的答案。需要注意的是 - 緩解措施主要與你所說的一樣：不是很祕密的祕密，沒有人會對此感興趣。很高興知道我的核心思想是合理的，並提供一些建議。 – 2011-01-28 16:25:42