我應該推出自己的OpenID提供商，還是有更好的方法？

Question

我正在爲一個客戶開發一個解決方案，他正在處理一個相當典型的問題：他們有很多生產系統，每個系統都有自己的用戶和密碼，導致每個用戶必須記住三或四個不同（或不）登錄和密碼，每個系統允許使用一個。另外，每個應用程序都有自己的認證級別（也就是說，如果你是一個超級用戶，那並不意味着你是所有用戶的超級用戶）。

到目前爲止，我的最佳想法是安裝OpenID提供程序，並使用AX（屬性交換）擴展提供訪問級別。然而，這很複雜，主要是因爲我找不到一個體面的OpenID提供程序的擴展實現 - 對於我在檔案中閱讀的內容，甚至連Google和朋友都沒有做到這一點...

幾個加分：

• 有關使用AX好的一面是，獲得能夠從一箇中心點進行管理 - 如果一個應用程序要求的領域，但OpenID提供沒有返回，那麼你不準登錄。這樣，高級用戶（又名老闆，或更確切的說是他的祕書）可以從一個網頁授予/撤消所有系統的權限。
• 我很樂意使用myOpenId，但如果您曾經試圖說服經理與外國網站分享用戶，密碼和權限的完整列表，那麼您知道答案的種類得到。本地服務器雖然可能不如使用Google安全，但似乎矛盾地成爲首選解決方案。
• LDAP被詬病，主要原因是擔心您可以通過適當的查詢（可能不是普通用戶，但開發人員可以獲得它）來獲取完整用戶列表。不過，我不是LDAP的專家，所以如果你認爲這是一個有效的選擇，我正在傾聽。
• 是的，我知道SREG更容易使用，但沒有「application_access」屬性，並捎帶另一個領域，如「電子郵件」，聽起來有點難看。

那麼，你認爲我在這裏做的是對的嗎？有沒有更好的解決方案，我錯過了？如果是這樣，你碰巧知道一個好的OpenID提供者（帶AX擴展！）我可以安裝嗎？

Answer 1

隨着您所要求的要求（管理員能夠撤銷通過屬性等傳遞的權限），聽起來像運行自己的提供者是最好的方式，因爲公共提供者不太可能提供您想要的靈活性。 DotNetOpenAuth作爲消費者和提供商都提供AX的全面支持，所以它將是一個很好的開始的地方 - 您還可以在其上構建所有管理級存儲和屬性通信定製。它仍然不是一個交鑰匙解決方案（即，需要編碼來從存儲的任何地方「獲取」AX值），但這比嘗試從頭開始要好得多。很多好的示例和社區，主要作者在StackOverflow上處於活動狀態。