【授权与认证】Dex 与 LDAP、OIDC

参考

• Kubernetes通过Dex集成企业外部认证系统

• 解读认证和授权 OAuth、SSO、CAS、JWT

• 盘点认证协议 : 普及篇之OAuth , OIDC , CAS

Dex 的起源因素

1. 首先明确，有多种认证协议 OIDC、LDAP 等
2. 基于这些认证协议实现了多种认证系统（比如 微信、微博、github、google 等认证系统，可能都是基于不同认证协议实现）
3. 目前有一个需求：我开发了一个网站，想支持用户通过【微信、微博、github 等进行登录】，但是我需要【逐个将我的认证系统与他们的认证系统进行对接，就是需要考虑他们的认证协议，从而进行大量开发工作】
4. 因此 dex 出现解决了此问题，【dex 支持多种认证协议，可以对接多个不同的认证系统】，因此安装了 dex ，便可进行统一纳管这些认证系统（如微信、微博、github 等），之后便可以进行愉快的登录

可以把Dex当作一个轻量级的认证的代理入口（portal），应用APP只需要通过与Dex交互，由Dex负责与后端的上游认证服务器交互，从而屏蔽了后端认证服务器的协议差异。

目前Dex已经实现对接的外部认证系统如下:

• LDAP
• GitHub
• SAML 2.0
• GitLab
• OpenID Connect
• Google
• LinkedIn
• Microsoft
• AuthProxy
• Bitbucket Cloud
• OpenShift
• Atlassian Crowd
• Gitea

当然其实实现了LDAP基本就实现一半以上企业的认证对接问题。

LDAP Lightweight Directory Access Protocol（轻量目录访问协议）

• LDAP 协议入门（轻量目录访问协议）

LDAP 协议是一个历史悠久的协议，诞生时间早于万维网。在当时商业数据库并不发达，而且当时商业数据库的驱动在多语言支持上也不友好——有可能这个数据库在你使用的编程语言上根本没有相关的开发包。LDAP 一直沿用至今，有很多的历史原因，因此许多应用都会支持通过 LDAP 登录。

LDAP 协议的用户目录是树形结构，天然与组织机构契合，而且在查询上速度非常快，比任何其他数据库都要快。

目录服务的数据库以**「树形方式」存储数据，也是一种 NoSQL。需要注意的是这是推荐的底层数据存储方式，因为目录服务查询比写入要多得多，所以使用树形数据库存储要有优势。但其实也可以使用 MySQL 或 MongoDB** 这样的数据库**「当做 LDAP 数据源」**。LDAP 只是一个「协议」，约定的是 C/S 之间的通信方式。理论上服务器只要能够处理所有 LDAP 协议规定的操作，并返回正确的结果就可以。

目录服务就是按照**「树状」存储信息的模式。目录服务的数据类型主要是「字符型」**, 而不是关系数据库提供的整数、浮点数、日期、货币等类型。为了检索的需要添加了 BIN（二进制数据）、CIS（忽略大小写）、CES（大小写敏感）、TEL（电话型）等语法（Syntax）。同样也不提供象关系数据库中普遍包含的大量的函数。目录有很强的查询（读）功能，适合于进行大量数据的检索；但目录一般只执行简单的更新（写）操作，不支持批量更新所需要的事务处理功能；它主要面向数据的查询服务（查询和修改操作比一般是大于 10:1），不提供事务的回滚（rollback）机制；目录具有广泛复制信息的能力，适合于多个目录服务器同步/更新。

LDAP 目录服务器将信息以树形的方式组织，每一项都可以包含 0 个或多个子项。这样的结构叫做目录信息树。

目录信息树可以类比我们的**「磁盘文件系统目录树」**，上面的定义是官方定义，理解起来，DIT 就是指像文件系统一样的目录结构树。

OIDC (OpenID Connect)

• 身份云动态 | 认证和授权，都离不开的 OIDC 协议

• 开发者谈 | OAuth 2.0 和 OIDC 协议的关系？（内含必看案例）

OAuth 2.0 是一个授权标准协议，可以使第三方应用获得对资源服务的有限访问。

身份验证存在的意义是什么？

是为了对那些有安全需求的特定***资源***进行访问控制，只让某些特定的主体（个人、公司、甚至是一段代码）对其执行某些特定的操作（查看、修改等）。因此，对于想要访问资源的主体，需要按照顺序达成如下两个条件：

1.认证（Authentication）：知道 ta 究竟是谁

2.授权（Authorization）：知道 ta 有没有权限对资源执行试图执行的操作

这其中，实际上存在着一个隐含的假设：

资源的所有权并不在用户手中，而是在外部的管理者手中，因此用户访问资源时才需要首先获取权限。

然而在当今的互联网中，很大一部分信息都是用户产生的，用户理应拥有自己资源的完全控制权限。

在这种场景之下，「授权」的概念依旧存在，只不过被授权的主体不再是***用户***，而是「想要访问用户***资源***的第三者」，而颁发权限的主体也不再是管理员，而是用户自己。

作为标准身份协议之一的 OIDC 正是为此种场景而生。

OIDC 全称是 OpenID Connect，是一个基于 OAuth 2.0 的认证 + 授权（OAuth 2.0 提供的能力）协议。