网络经纪人登录(安居客app官方下载)「终于解决」

大家好，我是讯享网，大家多多关注。

专注Java领域的优质技术号，欢迎关注作者:寒夜如梦

1. CAS 简介

1.1.CAS是什么？

CAS(Central authentic ation Service)是耶鲁大学发起的企业级开源项目，旨在为Web应用系统提供可靠的单点登录解决方案(属于Web SSO)。

CAS始于2001年，2004年12月正式成为JA-SIG项目。

1.2.主要特征

1.开源、多协议SSO解决方案；协议:自定义协议、CAS、OAuth、OpenID、RESTful API、SAML1.1、SAML2.0等。

2.支持多种认证机制:活动目录、JAAS、JDBC、LDAP、X.509证书等。

3.安全策略:使用Ticket实现支持的认证协议；

4.支持授权:您可以决定哪些服务可以请求和验证服务票；

5.提供高可用性:通过将认证的状态数据存储在TicketRegistry组件中，这些组件中有很多都支持分布式环境的实现，如:BerkleyDB、Default、EhcacheTicketRegistry、JDBCTicketRegistry、JBOSS TreeCache、JpaTicketRegistry、MemcacheTicketRegistry等。

6.支持多个客户端:Java。Net，PHP，Perl，Apache，uPortal等。

2. SSO 单点登录原理

本文主要关注Web SSO。

2.1.什么是SSO

单点登录是目前流行的企业业务集成解决方案之一。SSO使得用户只需要登录一次* *就可以访问多个应用系统中的所有可信应用系统。

2.2.单点登录原则

2.2.1.单点登录系统中的角色

一般单点登录系统中有三个主要角色:

1.用户(多个)

2.Web应用程序(多个)

3.SSO认证中心(**1 * *)

2.2.2.单点登录实施模式的原则

单点登录实现模式一般包括以下三个原则:

1.所有的认证登录都在SSO认证中心进行；

2.SSO认证中心通过一些方法告诉Web应用当前的访问用户是否是经过认证的用户；

3.SSO认证中心与所有web应用建立信任关系，也就是说Web应用必须信任认证中心。(单点信任)

2.2.3.单点登录的主要实现方法

实现单点登录的主要方式有:

1.共享cookies

基于共享同一个域的Cookie是Web诞生之初使用的一种方式。它利用浏览同一个域名之间自动传递cookies的机制来实现两个域名之间的系统令牌传递。另外，关于跨域问题，虽然cookies本身不跨域，但是可以用来实现跨域SSO。例如代理、公开SSO令牌值等。

缺点:不灵活，安全隐患多，已弃用。

2.基于代理(基于代理)

这项技术的特点是有一个集中的认证和用户账户管理服务器。允许代理访问用于进一步请求的电子身份。中央数据库的使用降低了管理成本，并为身份验证提供了一个公开、独立的“第三方”。比如Kerberos，Sesame，IBM KryptoKnight等等。Kerberos是MIT发明的安全认证服务，已经被UNIX和Windows集成到操作系统中，作为默认的安全认证服务。

3.基于代理(基于代理)

在此解决方案中，有一个代理可以自动验证不同应用程序的用户。这个代理需要设计不同的功能。例如，它可以使用密码表或加密密钥来自动消除用户的身份验证负担。代理位于服务器上，充当服务器的身份验证系统和客户端的身份验证方法之间的“转换器”。例如SSH。

4、基于令牌

比如SecureID，WebID，现在广泛使用的密码认证，比如FTP，邮件服务器登录认证，这是一种简单易用的方式，实现在各种应用中使用一个密码。

5.基于网关

6.基于SAML

SAML(安全断言标记语言)的出现大大简化了SSO，它已经被OASIS批准为SSO * *的* *实现标准。开源组织OpenSAML实现SAML规范。

3. CAS 的基本原理

3.1.结构体系

在架构上，CAS包括CAS服务器和CAS客户端两部分。

3.1.1.CAS服务器

CAS服务器负责认证用户，需要独立部署。CAS服务器将处理用户名/密码等凭据。

3.1.2.CAS客户端

处理对客户端受保护资源的访问请求，当请求者需要进行身份验证时，重定向到CAS服务器进行身份验证。(原则上，客户端应用程序将不再接受任何凭据，如用户名和密码)。

Cas与受保护的客户端应用程序一起部署，以过滤的方式保护受保护的资源。

3.2.CAS原则和协议

3.2.1.基本方式

基本模式SSO访问流程主要包括以下步骤:

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

以下是CAS最基本的协议流程:

实现CAS的单点登录原则

基本协议图

如上图所示:CAS Client部署了受保护的客户端应用，以过滤的方式保护Web应用的受保护资源，过滤来自客户端的每一个Web请求。同时，CAS客户端会分析HTTP请求中是否包含请求服务票(上图st中的票)，如果没有，说明用户没有通过认证；然后CAS客户端将用户的请求重定向到CAS服务器(步骤2)，并交付服务(要访问的目标资源地址)。步骤3是用户认证的过程。如果用户提供了正确的凭证，CAS Server随机生成一个相当长的、唯一的、不可伪造的服务票，缓存以备将来验证，并将用户重定向到服务所在的地址(带有刚刚生成的服务票)，* *并为客户端浏览器设置一个票授予cookie(TGC)* *；收到服务和新生成的票证后，CAS客户端在步骤5和6中向CAS服务器验证其身份，以确保服务票证的合法性。

在该协议中，所有与CAS服务器的交互都采用SSL协议来保证ST和TGC的安全。在协议的工作过程中会有**2次重定向**。但是，CAS客户端和CAS服务器之间的票证身份验证过程对用户是透明的(使用HttpsURLConnection)。

CAS请求认证的时序图如下:

实现CAS的单点登录原则

3.2.1.CAS如何实现SSO？

当用户访问的另一个应用的服务再次重定向到CAS服务器时，CAS服务器会主动获取这个TGC cookie，然后进行如下操作:

如果 User 持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO 的效果；如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。

3.2.2.CAS代理模式

模式是用户访问App1，App1依靠App2获取一些信息，比如:user->；app 1->；附录2 .

在这种情况下，假设App2也需要认证用户才能访问，CAS引入了代理认证机制，即CAS客户端可以代表用户访问其他Web应用，目的是为了不影响用户体验(过多的重定向导致用户的IE窗口不断闪烁)。

代理的前提是CAS客户端需要有用户的身份信息(类似凭据)。前面提到的TGC是用户持有自己身份信息的一种凭证，这里的PGT是CAS客户端持有用户身份信息的一种凭证。使用TGC，用户可以避免输入密码来获取服务票以访问其他服务。因此，使用PGT，Web应用程序可以代理用户实现后端身份验证，而无需前端用户的参与。

代理应用(helloService)获取PGT的如下过程:(注:PGTURL用于表示代理服务，是回调链接；PGT相当于代理证书；PGTIOU是获得代理证书的关键，用于与PGT建立关联关系；)

实现CAS的单点登录原则

如上图CAS代理示意图所示，**CAS客户端**在基本协议之上提供了一个额外的PGT URL(并且是SSL的入口)给CAS服务器，这样CAS服务器就可以通过PGT URL提供一个PGT给CAS客户端。

客户获得PGT (PGT IOU-85…TI2TD)，因此它可以通过PGT向后端Web应用程序进行身份验证。

下面是代理认证和服务提供的过程:

实现CAS的单点登录原则

如上图所示，代理认证和普通认证区别不大。步骤1 1和2与基本模式几乎相同。唯一的区别是代理模式使用PGT代替TGC，使用代理票证(PT)代替服务票证。

3.2.3.辅助解释

CAS的SSO实现可以简化为:1个Cookie和n个Session。Cas创建cookie，在所有应用程序进行身份验证时使用。每个应用程序通过创建自己的会话来识别用户是否已经登录。

用户通过某个应用的验证后，以后用户在同一个浏览器中访问这个应用时，客户端应用中的过滤器会读取会话中的用户信息，所以不会去CAS服务器进行认证。如果在此浏览器中访问其他web应用，客户端应用中的过滤器无法读取会话中的用户信息，它会去CAS服务器的登录界面认证，但随后CAS服务器会从浏览器中读取cookie (TGC)，所以CAS服务器不会要求用户在登录页面登录。它只根据服务参数生成一张票，然后与web应用程序交互来验证这张票。

3.3.术语解释

CAS系统设计了五种票据:TGC、圣、PGT、葡萄牙和葡萄牙。

票证授予cookie (TGC):存储用户身份验证凭证的cookie。它用于浏览器和CAS服务器之间的通信，只能基于安全通道(Https)传输。它是CAS服务器用来标识用户的凭据；

服务票(ST):服务票，服务的唯一识别码，由CAS服务器发送(Http传输)，通过客户端浏览器到达业务服务器；一个特定服务只能有一个唯一的ST；

代理授予票(PGT):由CAS服务器颁发给具有ST证书的服务，PGT绑定一个用户的特定服务，使其具有向CAS服务器申请并获得PT的能力；

proxy-granted ticket I won you(pgt iou):用于将CAS服务器验证证书时的响应信息返回给CAS客户端，同时将此PGT借据对应的PGT通过回调链接传递给Web应用。Web应用负责维护PGTIOU和PGT之间映射关系的内容表；

代理票(PT):是应用代理用户访问目标程序的凭证；

其他解释如下:

票据授权票据(TGT):票据授权票据，由KDC AS签发。即获得这样的机票后，以后申请各种其他服务机票(ST)时，无需再向KDC提交凭据；

身份验证服务(as)-身份验证服务，需要凭证并颁发TGT；

出票服务(TGS)-票据授权服务，获得TGT，发行ST；

KDC(密钥分发中心)——密钥分发中心；

4. CAS 安全性

CAS的安全性只依赖于SSL。使用安全cookie。

4.1.TGC/PGT安全

对于CAS用户来说，最重要的事情是保护其TGC。如果TGC被CAS服务器以外的实体无意中获取，黑客可以找到TGC，然后伪装成CAS用户访问* *所有* *授权资源。PGT的角色和TGC一样。

从基本模式可以看出，TGC是由CAS服务器通过SSL发送给最终用户的，因此拦截TGC非常困难，从而保证了CAS的安全性。

默认情况下，TGT的生存期为120分钟。

4.2.ST/PT安全性

ST(服务票)是通过Http传输的，所以网络中的其他人可以嗅探到其他人的票。CAS通过以下几个方面使ST更加安全(事实上，它是可以配置的):

1.ST只能使用一次。

根据CAS协议，无论服务票验证成功与否，CAS服务器都会清除服务器缓存中的票，从而保证一张服务票不会被使用两次。

2.ST在一定时间内失效。

规定CAS ST只能存活一定时间，之后CAS服务器会使其失效。默认有效时间是5分钟。

3.ST是基于随机数生成的。

ST必须足够随机。如果猜测ST生成规则，Hacker相当于绕过CAS认证，直接访问相应的服务。

https://www.jianshu.com/p/555da8c42a53