Closed mdianjun closed 3 years ago
不适用于clickhouse的认证场景
用户在单点登录服务器的登录页面中,输入用户名和密码。
然后单点登录服务器会对用户名和密码进行认证。认证本身并不是单点登录服务器的功能,因此,通常会引入某种认证机制。认证机制可以有很多种,例如自己写一个认证程序,或者使用一些标准的认证方法,例如LDAP或者数据库等等。在大多数情况下,会使用LDAP进行认证。这是因为LDAP在处理用户登录方面,有很多独特的优势,这在本文的后面还会比较详细地进行介绍。
认证通过之后,单点登录服务器会和应用程序进行一个比较复杂的交互,这通常是某种授权机制。CAS使用的是所谓的Ticket。具体这点后面还会介绍。
授权完成后,CAS把页面重定向,回到Web应用。Web应用此时就完成了成功的登录(当然这也是单点登录的客户端,根据返回的Ticket信息进行判断成功的)。
然后单点登录服务器会在客户端创建一个Cookie。注意,是在用户的客户端,而不是服务端创建一个Cookie。这个Cookie是一个加密的Cookie,其中保存了用户登录的信息。
如果用户此时希望进入其他Web应用程序,则安装在这些应用程序中的单点登录客户端,首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输入用户名和密码,而是首先自动寻找Cookie,根据Cookie中保存的信息,进行登录。登录之后,CAS重定向回到用户的应用程序。
CAS client文档:https://apereo.github.io/cas/4.2.x/integration/CAS-Clients.html
让CAS对接以下server,需要确定如何支持golang和python:
superset(python)
go client:
https://github.com/lucasuyezu/golang-cas-client
python client: