作者:翻译:姚洪 2015-09-06 10:34:47
云计算 dex是近日CoreOS发布的一项新的开源项目,它是一个基于多种标准的身份服务提供者和认证的解决方案。对于企业应用而言, 安全的进行认证和授权是必选项,dex无疑是解决这一问题的一大利器。
创新互联建站专注于企业营销型网站建设、网站重做改版、武陵源网站定制设计、自适应品牌网站建设、H5场景定制、商城网站制作、集团公司官网建设、成都外贸网站建设、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为武陵源等各大城市提供网站开发制作服务。
近日,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架构图解
在我们的防火墙之后,我们有如下几个组件:
在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仍然相当年轻, 接下来有很多工作要做。 如果你也对它感兴趣, 我们欢迎你的帮助!
网页标题:dex:CoreOS的开源身份认证服务解决方案
分享网址:http://www.shufengxianlan.com/qtweb/news13/168863.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联