近日，CoreOS發布了一個新的開源項目dex，一個基于OpenID Connect的身份服務組件。 CoreOS已經將它用于生產環境：自家的tectonic.com上。用戶認證和授權是應用安全的一個重要部分，用戶身份管理本身也是一個特別專業和復雜的問題，尤其對于企業應用而言， 安全的進行認證和授權是必選項，dex無疑是解決這一問題的一大利器。

今天我們興奮的發布CoreOS家族一個新的開源項目 dex：一個基于多種標準的身份服務提供者和認證解決方案。

幾乎每一個項目都需要某種認證和用戶管理。應用也需要一種方式能讓用戶從多種平臺安全地登錄， 例如web、移動端、命令行工具(CLI)，以及自動化系統等。開發者通常使用一個依賴于平臺的解決方案， 或者當常常發現已有的解決方案無法的解決他們的需求后就自己從頭寫一個解決方案。

然而， 大多數開發者并不負責安全的業務。讓他們自己寫認證軟件不僅會讓他們從核心產品的開發工作中分心，同時也顯然會帶來軟件安全方面的危險。正確的處理安全方面的工作是很有難度的， 我們最近看到很多引人注目的安全事故，在沒有被其他工程師或者安全專家做恰當審計的情況下任意而為只會帶來更多的風險。

正是基于這些原因， 我們決定開源dex，這樣我們已經完成的讓dex成為一個安全健壯的平臺的工作會讓其他人也能受益。開放給社區之后，dex反過來也會從更多的合作者中受益。沒有人再需要自己寫一遍“忘記密碼?”的流程，或者“以X，Y或者Z來登錄”的功能了。

項目起名為『dex』是因為它是一個中心化的用戶索引， 軟件里面其他組件可以基于dex做認證。

核心設計元素

Dex如此獨特是它包含了以下這些元素， 這些元素從最開始就驅動著設計和實現：

安全

安全是首要的工作：dex的設計采用了安全和加密的最佳實踐來最小化攻擊者獲得系統訪問權限的風險。 更進一步， dex的架構劃分也可以減輕任何單個攻擊可能帶來的損害。例如，dex缺省使用軟token生命周期，并自動輪換它的簽名秘鑰。由于秘鑰本身是加密的，攻擊者需要在短時間內同時侵入數據庫和一個dex worker才能得到一個tocken。

標準

Dex是OpenID Connect(OIDC)核心標準的實現。OIDC(不要與OpenID混淆)是由業界領袖和安全專家基于web安全領域的多年經驗合作創建的。它是OAuth 2之上的一層，提供了一個安全并且易于實現的認證協議。今天OIDC 已經作為一個單點登錄的解決方案使用在眾多互聯網巨頭里，例如Google、Facebook、Amazon等。

語言與平臺無關性

因為dex實現了OpenID Connect(OIDC) 核心標準，所以將dex集成入你的應用中十分簡單。僅需要一步：加入你所用的編程語言的OIDC客戶端庫。我們用Go寫了一個 go-oidc，其他的幾乎每種語言都有(請審查對應的客戶端庫以保證有適當的簽名驗證和協議符合度)。

聯合身份

dex有自己的用戶的概念， 但也允許通過不同的方式做認證， 稱之為連接器connector。 現在， dex自帶了兩種類型的連接器: 本地local連接器和OIDC 連接器。 當使用local連接器做認證時， 用戶使用email和密碼通過dex本身提供的定制化UI來登錄; 當使用OIDC連接器時， 用戶可以通過登錄第三方的OIDC身份服務提供方來認證， 例如Google或者Salesforce。

因為dex本身就是一個OIDC身份服務提供者， 它甚至可以做到將多個dex實例串聯到一起，每個實例依次將認證工作委派給下一個。

現在用戶必須在連接器中做選擇，但是在未來我們計劃允許身份的鏈接linking， 這樣每個單獨的用戶都可以以不同的方式登錄。 可擴展的連接器架構將會允許與多種身份服務做集成，例如GitHub， LDAP， SAML系統等。

案例學習: Tectonic.com

在CoreOS我們正使用dex的一種方式是做Tectonic客戶的注冊和認證。當一個用戶首次決定成為Tectonic客戶并按下Join的按鈕時， 他們會被帶到https://auth.tectoinc.com， 也就是OpenID Connect術語中的Issuer URL。 他們可以使用自己的Google身份或者輸入用戶名密碼來注冊。然后他們會被重定向回Tectonic.com網站來完成注冊。

下面的圖描述了整個部署：

圖：dex架構圖解

在我們的防火墻之后，我們有如下幾個組件：

• 一個postgres數據庫用作dex的后端存儲
• 一個單獨的dex-overlord， 負責輪換秘鑰和其他的管理任務
• 多個dex-worker， 提供前端給終端用戶做認證
• 產品站點，Tectonic.com

在OIDC中的依賴方(Relying Party， RP)-此案例中， 即我們的產品站點-為了一個ID token， 與身份提供者(identity provider， IdP)，也就是dex， 交換一個Authorization Token(從終端用戶那得到， 這里是Tectnoic的用戶)。 注意雖然這里我們把我們的應用和dex都一起放在同一個防火墻后面， 但這并不是必須的。 他們互相之間是通過跨公網的一個TLS連接來溝通;如果你有多個不同的應用跑在不同的環境并都需要認證時這是相當有用的。

當用戶選擇使用Google賬號做認證時，dex就臨時變成RP，Google就變成了IdP來認證和識別用戶。 一但dex完成了這個工作(通過上面提到的token交換協議)， dex就回來成為IdP并完成與Tectonic.com的token交換。

整個過程中token都是加密簽名過的，客戶端會檢查簽名。 簽名的秘鑰會持續的被IdP來輪換并被RP來同步。

dex未來的計劃

dex現在已經可以使用， 但是還有許多工作要做。 除了GitHub上的issues， dex路線圖中還包括：

• 授權 - 除了讓dex處理認證之外，我們也想要讓它成為一個通用的授權服務器。
• 用戶管理 - 我們正處理初始開發階段：開發API讓管理員來管理用戶， 但是很快它會更加完整并且也會帶UI。
• 多個遠程的身份 - 如上所述，用戶將會可以使用多種認證方法做認證
• 更多的連接器類型 - 例如，LDAP、GitHub等。

dex仍然相當年輕， 接下來有很多工作要做。 如果你也對它感興趣， 我們歡迎你的幫助!

原文鏈接：http://dockone.io/article/643