作者：PioneerYi链接：https://juejin.|如何设计一个通用的权限管理系统？说的太详细了！( 二 )

1：ST是TGT签发的。用户在CAS上认证成功后， CAS生成TGT ，用TGT签发一个ST ， ST的ticketGrantingTicket属性值是TGT对象，然后把ST的值redirect到客户应用。
2：PGT是ST签发的。用户凭借ST去访问Proxyservice ， Proxyservice去CAS验证ST（同时传递PgtUrl参数给CAS），如果ST验证成功，则CAS用ST签发一个PGT ， PGT对象里的ticketGrantingTicket是签发ST的TGT对象。
3：PT是PGT签发的。 Proxyservice代理back-endservice去CAS获取PT的时候， CAS根据传来的pgt参数，获取到PGT对象，然后调用其grantServiceTicket方法，生成一个PT对象。
1.1.2、CAS的服务
CAS的主要服务有：
KDC（KeyDistributionCenter)；
AS（AuthenticationService）它索取Crendential ，发放TGT；
TGS（TicketGrantingService），索取TGT ，发放ST 。
1.1.3、CAS的媒介
TGC（TicketGrantingCookie)
存放用户身份认证凭证的cookie ，在浏览器和CASServer间通讯时使用，并且只能基于安全通道传输（Https），是CASServer用来明确用户身份的凭证。
【作者：PioneerYi链接：https://juejin.|如何设计一个通用的权限管理系统？说的太详细了！】1.2、CAS工作原理
CAS的单点登录的认证过程，所用应用服务器受到应用请求后，检查ST和TGT ，如果没有或不对，转到CAS认证服务器登录页面，通过安全认证后得到ST和TGT ，再重新定向到相关应用服务器，在回话生命周期之内如果再定向到别的应用，将出示ST和TGT进行认证，注意，取得TGT的过程是通过SSL安全协议的。
从网上找了一个比较专业又比较详细的CAS工作原理流程图：

CAS流程
专业版可能比较晦涩难懂，来个通俗版。通俗形象地说就是：相当于用户要去游乐场，首先要在门口检查用户的身份(即CHECK用户的ID和PASS),如果用户通过验证，游乐场的门卫(AS)即提供给用户一张门卡(TGT) 。
这张卡片的用处就是告诉游乐场的各个场所，用户是通过正门进来，而不是后门偷爬进来的，并且也是获取进入场所一把钥匙。
现在用户有张卡，但是这对用户来不重要，因为用户来游乐场不是为了拿这张卡的而是为了游览游乐项目，这时用户摩天楼，并想游玩。
这时摩天轮的服务员(client)拦下用户，向用户要求摩天轮的(ST)票据，用户说用户只有一个门卡(TGT),那用户只要把TGT放在一旁的票据授权机(TGS)上刷一下。
票据授权机(TGS)就根据用户现在所在的摩天轮，给用户一张摩天轮的票据(ST),这样用户有了摩天轮的票据，现在用户可以畅通无阻的进入摩天轮里游玩了。
当然如果用户玩完摩天轮后，想去游乐园的咖啡厅休息下，那用户一样只要带着那张门卡(TGT).到相应的咖啡厅的票据授权机(TGS)刷一下，得到咖啡厅的票据(ST)就可以进入咖啡厅
当用户离开游乐场后，想用这张TGT去刷打的回家的费用，对不起，用户的TGT已经过期了，在用户离开游乐场那刻开始，用户的TGT就已经销毁了。
二、基于角色的权限管理模型
在业界接受度较高的权限模型是RBAC(Role-BasedAccessControl),基本的概念是将“角色”这个概念赋予用户，在系统中用户通过分配角色从而获得相应的权限，一个用户可以有多个角色，一个角色可以有多个权限，从而实现权限的灵活配置。
2.1、基本的RBAC模型
最基本的RBAC模型，就是由“用户” ， “角色”以及“权限”这三个主体组成，一个用户可以有多个角色，一个角色可以有多个权限，他们之间的关系可以是多对一关系，也可以是多对多关系。