如果我們*需要共享密鑰進行加密，我們如何支持ADFS？

編輯:(摘要）：我正在尋找一種方法來獲得作爲ADFS登錄的一部分傳遞給我們的自定義用戶特定屬性;如果這是合理的，我會深入探討如何保護它。如果我們*需要共享密鑰進行加密，我們如何支持ADFS？

編輯：（澄清）：我不想在登錄時通過AD的東西 - 如果用戶要打擊AD再次輸入密碼和然後身份驗證，他們會最終會出現令人困惑的，不匹配的密碼。相反，我想在我們登記是這樣的：

用戶輸入信息（電子郵件等）
我們生成一個長的隨機字符串，對其進行加密，然後提供作爲對客戶的一種獨特的ID的一部分AD

然後：

我們將用戶重定向到客戶的廣告面向auth
一旦用戶授權d，他們被重定向回給我們用戶&索賠信息
該信息包括我們生成的唯一ID--所以我們提取用戶ID並從中解密密碼。

這會比我們通常提供的安全性要低，但如果涉及廣告，這是最好的設想。這可能嗎？

長版本：客戶要求我們爲我們的Web應用程序添加對單點登錄的支持，實施Microsoft ADFS（Active Directory聯合服務）。

問題是我們依靠用戶的密碼來解密他們的記錄;他們的私鑰是用他們的密碼加密的，所以我們不能在沒有密碼的情況下訪問他們的記錄。

我一直在深入研究文檔，例如http://msdn.microsoft.com/en-us/library/bb897402.aspx - 但目前我沒有看到使用AD FS安全管理某種祕密加密密鑰的方法。

當然，它不一定是密碼本身 - 我們通過生成具有與密碼相同屬性的隨機訪問令牌（可用於解密用戶的記錄）來實現OAuth2 ......但是，傳入，驗證用戶需要與一些類型的安全，私人令牌。

任何指導非常感謝！

來源

2014-02-12 Rob Whelan

我發現了一個相關的問題在這裏：http://stackoverflow.com/questions/6416282/what-can-i-use-from-ad-via -dap-as-an-user-specific-encryption-key？rq = 1 - 這表明將敏感數據存儲在AD中是不明智的，因爲它的設計不是安全的。此時，我正在尋找如何在AD登錄時獲取傳遞給我們的服務器的自定義每用戶屬性，然後我會理清，即使AD沒有安全地存儲它，也可以保證安全。 –

如果您使用的是ADFS 2.0，則可以使用customize the pages。

所以你可以例如取出密碼，對其進行修改，在調用SignIn之前將其寫入AD，然後通過聲明規則來通過該聲明。然後在應用程序中顛倒過程。

注 - 我並不是說這是一個「好」的解決方案 - 只是您可以做的一個例子。

安全顯然需要至關重要！

來源

2014-02-12 18:27:26 nzpcmad

謝謝，這是一個開始 - 我已經更新了這個問題，首先我應該找出一個乾淨的方法，將自定義的，用戶特定的屬性傳回給我們，並帶上AD標誌;接下來我可以深入探討如何確保這一點。您的鏈接提到「自定義屬性商店」以及自定義頁面 - 是更好的方式嗎？ –

該上下文中的「自定義屬性存儲」是ADFS支持的不是AD/SQL/LDAP的某些存儲。我沒有看到它比AD更安全？ – nzpcmad

哦，閱讀其他回覆，我突然明白你在說提示用戶輸入密碼，然後通過。我已經在我的問題中添加了說明，以解釋我認爲可以工作的流程。 –

那麼有兩種方法可以解決您的問題。

自定義ADFS SignOn頁面（您應該反正進行備份）來創建一個接收用戶密碼的表單。它是一個webforms aspx頁面，所以你不應該這樣做。從那裏你必須建立你自己的STS來向ADFS發出聲明，這樣ADFS才能將這些聲明傳遞給你的依賴方。將自定義STS作爲屬性存儲映射到ADFS
通過掌握安全性，您只是在做錯事情。 ADFS使用HTTPS進行傳輸級安全性和使用SAML 2.0進行安全加密來處理您的信息，因此另一種加密技術將毫不費力。

讓我知道你喜歡哪種方式去

來源

2014-02-17 03:03:01 Deeptechtons

對於這些用戶，我想依靠ADFS進行身份驗證，但仍然在AD中存儲一個很長的隨機字符串（鏈接到該用戶的帳戶，並進行了加密以保證安全），以取代我們的加密密碼。當每個用戶註冊我們時，如何在客戶的AD中存儲每個用戶的唯一字符串？如果將來有更新方法，還有獎勵點，以及...密碼應該一次又一次地更改。 –

如果我們*需要共享密鑰進行加密，我們如何支持ADFS？

回答

相關問題