一、CAS身份认证
二、基于角色的权限管理模型三、数据表设计四、角色及权限点设计五、身份认证加权限管理实施一个系统，如果没有安全控制，是十分危险的，一般安全控制包括身份认证和权限管理。用户访问时，首先需要查看此用户是否是合法用户，然后检查此用户可以对那些资源进行何种操作，最终做到安全访问。身份认证的方式有很多种，最简单的就是直接用户名密码，还有业内比较通用的方式CAS方式登陆等；授权的框架也很多，比如OAuth2，Shiro等。本文首先会讲解一下CAS的概念，以及基于角色的权限管理模型（RBAC）的概念，接着进行数据表的设计，最后讲解如何利用Shiro进行权限管理。
一、CAS身份认证集中式认证服务（英语：CentralAuthenticationService，缩写CAS）是一种针对万维网的单点登录协议。它的目的是允许一个用户访问多个应用程序，而只需提供一次凭证。
1.1、名词概念CAS的核心就是其Ticket，及其在Ticket之上的一系列处理操作。CAS的主要票据有TGT、ST、PGT、PGTIOU、PT，其中TGT、ST是CAS1.0(基础模式)协议中就有的票据，PGT、PGTIOU、PT是CAS2.0(代理模式)协议中有的票据。这些票据谁生成得了？肯定是有相关服务的，主要服务有：KDC，AS，TGS。两者媒介肯定也是有的：TGC。
1.1.1、CAS的Ticket1）TGT（TicketGrantingTieckt）
TGT是CAS（具体为KDC的AS发放）为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。用户在CAS认证成功后，CAS生成cookie，写入浏览器，同时生成一个TGT对象，放入自己的缓存，TGT对象的ID就是cookie的值。当HTTP再次请求到来时，如果传过来的有CAS生成的cookie，则CAS以此cookie值为key查询缓存中有无TGT，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。
简而言之，即获取这样一张票据后，以后申请各种其他服务票据(ST)便不必再向KDC提交身份认证信息(准确术语是Credentials)。
2）ST（Serviceticket）
ST是CAS（由KDC的TGS发放）为用户签发的访问某一service的票据。
用户访问service时，service发现用户没有ST，则要求用户去CAS获取ST。用户向CAS发出获取ST的请求，如果用户的请求中包含cookie，则CAS会以此cookie值为key查询缓存中有无TGT，如果存在TGT，则用此TGT签发一个ST，返回给用户。用户凭借ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源。
任何一台Workstation都需要拥有一张有效的ServiceTicket才能访问域内部的应用(Applications)。如果能正确接收ServiceTicket，说明在CASClient-CASServer之间的信任关系已经被正确建立起来。
3）PGT（ProxyGrantingTicket）
ProxyService的代理凭据。用户通过CAS成功登录某一ProxyService后，CAS生成一个PGT对象，缓存在CAS本地，同时将PGT的值（一个UUID字符串）回传给ProxyService，并保存在ProxyService里。ProxyService拿到PGT后，就可以为TargetService（back-endservice）做代理，为其申请PT。
4）PT（ProxyTicket）
PT是用户访问TargetService（back-endservice）的票据。如果用户访问的是一个Web应用，则Web应用会要求浏览器提供ST，浏览器就会用cookie去CAS获取一个ST，然后就可以访问这个Web应用了。如果用户访问的不是一个Web应用，而是一个C/S结构的应用，因为C/S结构的应用得不到cookie，所以用户不能自己去CAS获取ST，而是通过访问proxyservice的接口，凭借proxyservice的PGT去获取一个PT，然后才能访问到此应用。
TGT、ST、PGT、PT之间关系的总结
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用来明确用户身份的凭证。
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模型，就是由“用户”，“角色”以及“权限”这三个主体组成，一个用户可以有多个角色，一个角色可以有多个权限，他们之间的关系可以是多对一关系，也可以是多对多关系。
用户角色权限关系2.2、引入用户组的RBAC模型如果用户数量比较庞大，新增一个角色时，需要为大量用户都重新分配一遍新的角色，工程量巨大，此时可以引入用户组的概念。如果部分用户的使用场景是相对一致和基础的，可以把这些用户打包成一个组，基于这个组的对象进行角色和权限的赋予。最终用户拥有的所有权限=用户个人拥有的权限+该用户所在用户组拥有的权限。
2.3、角色分级的RBAC模型在一些业务场景中，上层角色需要继承下层角色的全部权限，此时则需要使用角色继承的RBAC模型。此时除了对角色进行定义，还需要管理角色间的关系，通过关系来体现角色的层级关系，从而达到继承权限的效果。角色的继承关系主有两种：树形图和有向无环图。
角色继承模式继承关系常常来源于公司团队的组织架构，此时常常将角色与组织结构进行关联达到继承角色模型的效果。
2.4、角色限制的RBAC模型在一些产品或系统中，部分角色可能是需要隔离的、不允许被同时赋予一个人的，比如不能既是运动员又是裁判员。因此，有些角色存在互拆关系。此外，限制还可能是数量上的，比如某个产品组中有且只有一个管理员，不允许删除或再分配其他管理员。
根据不同的业务需求，限制的形式很多，需要注意的是不能仅仅依赖后段限制，而是要在前端展示清晰的规则和恰当的限制，避免用户出错。
2.5、权限管理的基本元素权限管理的基本元素为：用户，角色，资源，操作，权限。
1、用户应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。
2、用户组（可选）为了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际情况中，我们知道，组也可以具有自己的角色信息、权限信息。
3、角色为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。
4、资源权限管理的一个单元实体对象，我们广义的称之为资源，可以是一个人，也可以是一个产品，一个文件，一个页面等等。5、操作对资源进行的实际操作，比如读、写、编辑等等。
6、权限资源+操作，构成一个权限控制点。
对象间的关系包括：
是否关系继承关系限制关系（互斥、范围限制、边界限制、字段限制）三、数据表设计按照RBAC模型，数据库可以这样设计：
1、产品表（t_product_info）字段名称字段类型备注产品Idpro_idint(11)自增产品名称（英）name_envarchar(50)notnull产品名层（中）name_chvarchar(50)notnull创建人creatorvarchar(50)notnull所属人ownervarchar(50)notnull描述descriptionvarchar()创建时间create_timetimestampnotnull2、产品成员表（t_product_member）字段名称字段类型备注记录IDidint(11)自增产品IDpro_idint(11)fk:t_produck_info成员IDmember_idint(11)notnull创建时间create_timetimestampnotnull3、用户信息表（t_user_info)字段名称字段类型备注用户IDuser_idint(11)notnull英文名nike_namevarchar(10)notnull中文名real_namevarchar(10)notnull创建时间create_timetimestampnotnull更新时间update_timetimestampnotnull4、用户角色表(t_user_role)字段名称字段类型备注记录IDidint(11)自增用户IDuser_idint(11)notnull角色IDrole_idvarchar（50）notnull创建时间create_timetimestampnotnull5、角色表（t_role）字段名称字段类型备注记录IDidint(11)自增角色IDrole_idvarchar（50）notnull,比如：A~USER角色名称role_namevarchar（50）notnull对象objectvarchar（50）notnull对象IDobject_idvarchar（50）notnull角色备注