dex：CoreOS的开源身份认证服务解决方案

作者：翻译：姚洪 2015-09-06 10:34:47

云计算 dex是近日CoreOS发布的一项新的开源项目，它是一个基于多种标准的身份服务提供者和认证的解决方案。对于企业应用而言，安全的进行认证和授权是必选项，dex无疑是解决这一问题的一大利器。

近日，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路线图中还包括：