SSO调研：Central Authentication Service与Authelia

[mdianjun]

• https://blog.csdn.net/hzcyclone/article/details/7381269
• https://www.apereo.org/projects/cas

[glove747]

结论

不适用于clickhouse的认证场景

1. CAS一般用于多个web服务的单点登录场景
2. CAS是SSO（单点登录）解决方案里面比较成熟的架构，其后端认证用大多用的是LDAP

   CAS 最基本的协议过程

   

3. 访问服务：SSO客户端发送请求访问应用系统提供的服务资源。
4. 重定向认证：SSO客户端会重定向用户请求到SSO服务器。
5. 用户验证：用户身份认证。
6. 生成票据：SSO服务器会产生一个随机的Service Ticket。
7. 验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。
8. 传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。

CAS基本流程

• 用户在单点登录服务器的登录页面中，输入用户名和密码。

• 然后单点登录服务器会对用户名和密码进行认证。认证本身并不是单点登录服务器的功能，因此，通常会引入某种认证机制。认证机制可以有很多种，例如自己写一个认证程序，或者使用一些标准的认证方法，例如LDAP或者数据库等等。在大多数情况下，会使用LDAP进行认证。这是因为LDAP在处理用户登录方面，有很多独特的优势，这在本文的后面还会比较详细地进行介绍。

• 认证通过之后，单点登录服务器会和应用程序进行一个比较复杂的交互，这通常是某种授权机制。CAS使用的是所谓的Ticket。具体这点后面还会介绍。

• 授权完成后，CAS把页面重定向，回到Web应用。Web应用此时就完成了成功的登录（当然这也是单点登录的客户端，根据返回的Ticket信息进行判断成功的）。

• 然后单点登录服务器会在客户端创建一个Cookie。注意，是在用户的客户端，而不是服务端创建一个Cookie。这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。

• 如果用户此时希望进入其他Web应用程序，则安装在这些应用程序中的单点登录客户端，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。登录之后，CAS重定向回到用户的应用程序。

[mdianjun]

CAS client文档：https://apereo.github.io/cas/4.2.x/integration/CAS-Clients.html

让CAS对接以下server，需要确定如何支持golang和python:

• LDAP(java)
• ranger(java)
• ckman(golang)
• atlas(java)

• superset(python)

  go client：

• https://github.com/go-cas/cas （这个还在维护）

• https://github.com/lucasuyezu/golang-cas-client

  python client：

• https://github.com/python-cas/python-cas

[mdianjun]

authelia：

• https://www.authelia.com/docs/
• https://github.com/authelia/authelia