CAS单点登录(一)

CAS单点登录

一、单系统登陆机制

  1. http无状态协议

    web应用采用browser/server架构,http作为通信协议。http是无状态的,浏览器的每一次请求,服务器会独立处理,不与之前或之后的请求产生关联。

    但是这也意味着任何用户都可以通过浏览器访问服务器资源,如果想保护浏览器资源,就必须限制浏览器请求;就需要鉴别浏览器请求,响应合法请求。既然http是无状态的,那就让服务器和浏览器共同维护一个状态,这就是会话机制

  2. 会话机制

    浏览器第一次请求服务器,服务器会创建一个会话,并将会话id作为相应的一部分发送给浏览器,浏览器会存储会话id,并在后续第二次和第三次请求中带上会话id,服务器取得请求中的会话id就知道是不是同一个用户了。

    浏览器可以通过 1、请求参数 2、cookie保存会话id。

二、单点登录(Single Sign-On)

SSO体系中的主要的三部分

  1. User (多个)
  2. Web应用(多个)
  3. SSO认证中心(1个)

SSO实现基本核心原则

  • 所有的登陆都在SSO认证中心进行
  • SSO认证中心通过一些方法告诉Web应用当前访问用户究竟是不是已通过认证的用户
  • SSO认证中心和所有的Web应用建立一种信任关系,SSO认证中心对用户身份正确行的判断会通过某种方法告知Web应用,而且判断结果必须被Web应用信任

1、登陆

​ 通过认证中心简介授权令牌来实现,当SSO验证了用户信息的正确性后,就会创建授权令牌,在接下来的跳转过程中,授权令牌作为参数发送给各个子系统,子系统拿到令牌,即得到了授权,可以借此创建局部会话,局部会话登陆方式与单系统的登陆方式相同。

cas登陆
具体流程
  1. 首先用户访问系统一受保护的资源,系统一发现为登陆,跳转到SSO认证中心,并将自己的参数传递过去
  2. SSO认证中心发现用户未登陆,将用户引导至登陆页面
  3. 用户输入用户名和密码提交至SSO认证中心
  4. SSO认证中心校验用户信息,创建用户与SSO认证中心之间的对话,称为全局对话,同时创建授权令牌
  5. SSO认证中心带着令牌跳转最初的请求地址(系统一)
  6. 系统一拿到令牌,去SSO认证中心校验令牌是否有效
  7. SSO认证中心校验令牌,返回有效,注册系统一的地址
  8. 系统一使用该令牌创建与用户的会话,称为局部会话,返回用户受保护资源
  9. 用户访问系统二受保护的资源
  10. 系统二发现用户未登录,跳转到SSO认证中心,并将自己的地址作为参数传递过去
  11. SSO认证中心发现用户一登录,跳转回系统二的地址,并附上令牌
  12. 系统二拿到令牌,去SSO认证中心校验令牌是否有效
  13. SSO认证中心校验令牌,返回有效地址,注册系统二地址
  14. 系统二使用该令牌创建与用户的局部会话,返回给用户受保护资源

用户登录成功,会与SSO认证中心及各个子系统创建会话,用户与SSO认证中心的会话称为全局会话,用户与各个子系统的会话称为局部会话,局部会话建立后,用户访问子系统受保护资源不再通过SSO认证中心

  • 局部会话存在,全局会话一定存在
  • 全局会话存在,局部会话不一定存在
  • 全局会话销毁,局部会话必须销毁

2、注销

  1. 用户向系统一发起注销请求
  2. 系统一根据用户与系统一建立的会话id拿到令牌,向SSO认证中心发起注销请求
  3. SSO认证中心校验令牌有效,销毁全局会话,同时去除所有用此令牌注册的系统地址
  4. SSO认证中心向所有注册系统发起注销请求
  5. 各注册系统接收SSO认证中心的注销请求,销毁局部会话
  6. SSO认证中心引导用户至登陆页面

三、CAS基本原理

1、结构体系

CAS Server: 负责完成对用户的认证工作,需要独立部署,处理用户名/密码等凭证

CAS Client: 负责处理对客户端受保护资源的访问请求,需要对请求方进行身份验证,重定向到CAS Server进 行认证(原则上客户端应用不再接收任何的用户名密码等)

2、CAS协议

​ CAS协议是一个简单而强大的基于票据的协议,涉及一个或多个客户端和一台服务器。即在CAS中,通TGT(Ticket Granting Ticket)来获取ST(Server Ticket) ,通过ST来访问具体的服务

​ 在SSO中的令牌也就是CAS中的ST。

3、具体流程

​ 首先用户访问受保护的资源,权限没有认证,所以会把请求的URL以参数跳转到CAS认证中心,CAS认证中心发现没有SSO session,所以弹出登录页面,输入用户信息,提交到CAS认证中心进行信息的认证,如果信息正确,CAS认证中心就会创建一个SSO sessionCAS TGC (cookie),这个CASTGC cookie包含了TGT,而用户session则以TGT为key创建,同时服务端会分发一个ST返回给用户。用户拿到了ST后,访问带参数ST的资源地址,同时应用将ST发送给CAS认证中心,CAS认证中心对ST进行校验,同时判断相应的cookie(包含TGT)是否正确(通过先前设定的key),判断ST是否是有效的,结果会返回一个包含成功信息的XML给应用。应用在建立相应的session和cookie跳转到浏览器,用户再通过浏览器带cookie去应用访问受保护的资源地址,cookie和后端session验证成功便可以成功访问到信息。

第二次访问应用时,浏览器就会携带相应的cookie信息,后台session验证用户是否登录,与一般单系统应用登录模式一样。

当我们访问其他的应用,与前面的步骤也是基本相同,首先用户访问受保护的资源,跳转回浏览器,浏览器含有先前登录的CASTGC cookie,CASTGC cookie包含了TGT并发送到CAS认证中心,CAS认证中心校验TGT是否有效,如果有效分发浏览器一个带ST参数的资源地址URL,应用程序拿到ST后,再发送给CAS认证中心,如果认证了ST有效后,结果会返回一个包含成功信息的XML给应用。同样的步骤,应用在建立相应的session和cookie跳转到浏览器,用户再通过浏览器带cookie去应用访问受保护的资源地址,验证session成功便可以成功访问到信息。

4、术语概念# CAS单点登录

一、单系统登陆机制

  1. http无状态协议

    web应用采用browser/server架构,http作为通信协议。http是无状态的,浏览器的每一次请求,服务器会独立处理,不与之前或之后的请求产生关联。

    但是这也意味着任何用户都可以通过浏览器访问服务器资源,如果想保护浏览器资源,就必须限制浏览器请求;就需要鉴别浏览器请求,响应合法请求。既然http是无状态的,那就让服务器和浏览器共同维护一个状态,这就是会话机制

  2. 会话机制

    浏览器第一次请求服务器,服务器会创建一个会话,并将会话id作为相应的一部分发送给浏览器,浏览器会存储会话id,并在后续第二次和第三次请求中带上会话id,服务器取得请求中的会话id就知道是不是同一个用户了。

    浏览器可以通过 1、请求参数 2、cookie保存会话id。

二、单点登录(Single Sign-On)

SSO体系中的主要的三部分

  1. User (多个)
  2. Web应用(多个)
  3. SSO认证中心(1个)

SSO实现基本核心原则

  • 所有的登陆都在SSO认证中心进行
  • SSO认证中心通过一些方法告诉Web应用当前访问用户究竟是不是已通过认证的用户
  • SSO认证中心和所有的Web应用建立一种信任关系,SSO认证中心对用户身份正确行的判断会通过某种方法告知Web应用,而且判断结果必须被Web应用信任

1、登陆

​ 通过认证中心简介授权令牌来实现,当SSO验证了用户信息的正确性后,就会创建授权令牌,在接下来的跳转过程中,授权令牌作为参数发送给各个子系统,子系统拿到令牌,即得到了授权,可以借此创建局部会话,局部会话登陆方式与单系统的登陆方式相同。

cas登陆
具体流程
  1. 首先用户访问系统一受保护的资源,系统一发现为登陆,跳转到SSO认证中心,并将自己的参数传递过去
  2. SSO认证中心发现用户未登陆,将用户引导至登陆页面
  3. 用户输入用户名和密码提交至SSO认证中心
  4. SSO认证中心校验用户信息,创建用户与SSO认证中心之间的对话,称为全局对话,同时创建授权令牌
  5. SSO认证中心带着令牌跳转最初的请求地址(系统一)
  6. 系统一拿到令牌,去SSO认证中心校验令牌是否有效
  7. SSO认证中心校验令牌,返回有效,注册系统一的地址
  8. 系统一使用该令牌创建与用户的会话,称为局部会话,返回用户受保护资源
  9. 用户访问系统二受保护的资源
  10. 系统二发现用户未登录,跳转到SSO认证中心,并将自己的地址作为参数传递过去
  11. SSO认证中心发现用户一登录,跳转回系统二的地址,并附上令牌
  12. 系统二拿到令牌,去SSO认证中心校验令牌是否有效
  13. SSO认证中心校验令牌,返回有效地址,注册系统二地址
  14. 系统二使用该令牌创建与用户的局部会话,返回给用户受保护资源

用户登录成功,会与SSO认证中心及各个子系统创建会话,用户与SSO认证中心的会话称为全局会话,用户与各个子系统的会话称为局部会话,局部会话建立后,用户访问子系统受保护资源不再通过SSO认证中心

  • 局部会话存在,全局会话一定存在
  • 全局会话存在,局部会话不一定存在
  • 全局会话销毁,局部会话必须销毁

2、注销

  1. 用户向系统一发起注销请求
  2. 系统一根据用户与系统一建立的会话id拿到令牌,向SSO认证中心发起注销请求
  3. SSO认证中心校验令牌有效,销毁全局会话,同时去除所有用此令牌注册的系统地址
  4. SSO认证中心向所有注册系统发起注销请求
  5. 各注册系统接收SSO认证中心的注销请求,销毁局部会话
  6. SSO认证中心引导用户至登陆页面

三、CAS基本原理

1、结构体系

CAS Server: 负责完成对用户的认证工作,需要独立部署,处理用户名/密码等凭证

CAS Client: 负责处理对客户端受保护资源的访问请求,需要对请求方进行身份验证,重定向到CAS Server进 行认证(原则上客户端应用不再接收任何的用户名密码等)

2、CAS协议

​ CAS协议是一个简单而强大的基于票据的协议,涉及一个或多个客户端和一台服务器。即在CAS中,通TGT(Ticket Granting Ticket)来获取ST(Server Ticket) ,通过ST来访问具体的服务

​ 在SSO中的令牌也就是CAS中的ST。

3、具体流程

​ 首先用户访问受保护的资源,权限没有认证,所以会把请求的URL以参数跳转到CAS认证中心,CAS认证中心发现没有SSO session,所以弹出登录页面,输入用户信息,提交到CAS认证中心进行信息的认证,如果信息正确,CAS认证中心就会创建一个SSO sessionCAS TGC (cookie),这个CASTGC cookie包含了TGT,而用户session则以TGT为key创建,同时服务端会分发一个ST返回给用户。用户拿到了ST后,访问带参数ST的资源地址,同时应用将ST发送给CAS认证中心,CAS认证中心对ST进行校验,同时判断相应的cookie(包含TGT)是否正确(通过先前设定的key),判断ST是否是有效的,结果会返回一个包含成功信息的XML给应用。应用在建立相应的session和cookie跳转到浏览器,用户再通过浏览器带cookie去应用访问受保护的资源地址,cookie和后端session验证成功便可以成功访问到信息。

第二次访问应用时,浏览器就会携带相应的cookie信息,后台session验证用户是否登录,与一般单系统应用登录模式一样。

当我们访问其他的应用,与前面的步骤也是基本相同,首先用户访问受保护的资源,跳转回浏览器,浏览器含有先前登录的CASTGC cookie,CASTGC cookie包含了TGT并发送到CAS认证中心,CAS认证中心校验TGT是否有效,如果有效分发浏览器一个带ST参数的资源地址URL,应用程序拿到ST后,再发送给CAS认证中心,如果认证了ST有效后,结果会返回一个包含成功信息的XML给应用。同样的步骤,应用在建立相应的session和cookie跳转到浏览器,用户再通过浏览器带cookie去应用访问受保护的资源地址,验证session成功便可以成功访问到信息。

4、术语概念

TGC(ticket-granting cookie):

​ 授权的票据证明,由CAS Server通过SSL方式发送给终端用户,存放用户的身份凭证的Cookie,在浏览器和CAS Server间通讯时使用,并且只能基于安全通道传输(Https),是CAS Server用来明确用户身份的凭证

TGT(Ticket Grangting Ticket)

​ TGT是CAS为用户签发的登陆票据,拥有了TGT,用户就可以证明自己砸CAS成功登陆过,TGT封装了Cookie值对应的用户信息。用户在CAS认证成功后,CAS生成TGC,写入浏览器,同时生成一个TGT对象,放入自己的缓存,TGT对象的ID就是Cookie的值。当http请求到来时,如果传过来的有CAS生成的Cookie,则CAS以此Cookie值为keu查询缓存中有无TGT,如果有的话 ,则说明用户之前登陆过,如果没有,则用户需要重新登录。

ST(Service Ticket)

​ ST是CAS为用户签发的访问某一Service的票据。用户访问Service时,Service发现用户没有ST,则要求用户去CAS获取ST。用户向CAS发送获取ST请求,如果请求包含cookie,则CAS会以此cookie值为key查询缓存总有无TGT,如果存在TGT,则用ciTGT签发一个ST,返回给用户。用户凭借ST访问Service,service拿ST去CAS验证,验证通过后,允许用户访问资源。

TGC(ticket-granting cookie):

​ 授权的票据证明,由CAS Server通过SSL方式发送给终端用户,存放用户的身份凭证的Cookie,在浏览器和CAS Server间通讯时使用,并且只能基于安全通道传输(Https),是CAS Server用来明确用户身份的凭证

TGT(Ticket Grangting Ticket)

​ TGT是CAS为用户签发的登陆票据,拥有了TGT,用户就可以证明自己砸CAS成功登陆过,TGT封装了Cookie值对应的用户信息。用户在CAS认证成功后,CAS生成TGC,写入浏览器,同时生成一个TGT对象,放入自己的缓存,TGT对象的ID就是Cookie的值。当http请求到来时,如果传过来的有CAS生成的Cookie,则CAS以此Cookie值为keu查询缓存中有无TGT,如果有的话 ,则说明用户之前登陆过,如果没有,则用户需要重新登录。

ST(Service Ticket)

​ ST是CAS为用户签发的访问某一Service的票据。用户访问Service时,Service发现用户没有ST,则要求用户去CAS获取ST。用户向CAS发送获取ST请求,如果请求包含cookie,则CAS会以此cookie值为key查询缓存总有无TGT,如果存在TGT,则用ciTGT签发一个ST,返回给用户。用户凭借ST访问Service,service拿ST去CAS验证,验证通过后,允许用户访问资源。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值