web系统如何实现单点登录解决方案（WebSSO）

单点登录：

什么是单点登录 (SSO)

单点登录主要用于多系统集成，即在多个系统中，用户只需要登录一个中心服务器一次就可以访问其中任何一个系统，而不需要多次登录。

单点登录（Sign On），简称SSO，是目前比较流行的企业业务集成解决方案之一。 SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

如何在Web系统中实现单点登录

目前已经有成熟的单点登录实现方案，例如CAS。 我们只需要在Web系统中应用单点登录解决方案CAS即可。 （主要涉及注册、登录验证等模块的变更）

什么是CAS

CAS()是耶鲁大学发起的Java开源项目。 它旨在为Web应用系统提供可靠的单点登录解决方案（Web SSO）。 CAS具有以下特点：

1、开源企业级单点登录解决方案；

2、CAS是一个需要独立部署的Web应用——独立的Web应用（cas.war）。 ;

3、CAS支持多种客户端（指单点登录系统中的各种Web应用），包括Java、.Net、PHP、Perl等。

CAS于2004年12月成为Jasig项目，因此也称为JA-SIG CAS。

官网1：

官网2：

论坛：

：

为开发人员提供的快速资源：

下载链接：

开发文档：

CAS原理从结构上看，CAS由CAS和CAS两部分组成。

CASCAS需要独立部署，主要负责用户认证。 它将处理用户名/密码和其他凭据（）；

CAS负责完成用户认证。 CAS需要独立部署。 CAS 有不止一种实现。 Yale CAS 和 ESUP CAS 都是不错的选择。

CAS将处理诸如用户名/密码()之类的凭据。 它可以从数据库中检索用户帐户信息或在 XML 文件中检索用户密码。 对于这种方法，CAS提供了灵活但统一的接口/实现。 分离方式，CAS采用什么样的认证方式，是和CAS协议分离的，即这个认证的实现细节可以自己定制和扩展。

CAS CAS部署在客户端，负责处理本地Web应用（客户端）对受保护资源的访问请求，并在请求者需要认证时重定向到CAS进行认证。

CAS负责在客户端进行部署（注意，我指的是Web应用程序）。 原则上，部署CAS意味着当有请求访问本地Web应用程序的受保护资源，并且需要验证请求者的身份时，Web应用程序不再接受任何用户名、密码等，但重定向到 CAS 进行身份验证。

目前，CAS支持（部分正在开发中）大量的客户端，包括Java、.Net、ISAPI、Php、Perl、Acegi、Ruby等。几乎可以说，CAS协议可以适用于用任何语言写作。 客户端应用程序。

CAS相关词汇和概念

（后面代码部分会详细介绍，不过这里可以初步了解）

TGC(-)---------授权票证，由CAS通过SSL发送给最终用户；

KDC（Key）----------密钥分配中心；

ST ( )---------服务票据，由KDC的TGS签发，ST只能尝试验证一次。 任何计算机都需要有一个有效的计算机才能访问域 () 内的应用程序。 如果能够正确接收，则说明之间的信任关系已经正确建立，通常是数字加密的证书；

(TGT)----------Ticket授权票证，由KDC的AS签发。 即获得该票据后，以后申请其他各种服务票据（ST）时不再需要向KDC提交（凭证或身份认证信息）；

(AS)----------认证服务，请求并颁发TGT；

- (TGS) ---------票证授权服务，请求TGT，签发ST。

CAS 协议和工作流程

下图是CAS最基本的协议：

1. CAS与受保护的客户端应用程序一起部署，以保护受保护的资源。 对于每个访问受保护资源的Web请求，CAS都会分析HTTP请求中是否包含（ST）和（TGT）。 如果没有，则说明当前用户还没有登录，所以会将请求重定向到指定的CAS登录地址并传递（即要访问的目的资源地址），以便之后可以将该地址调回登录成功。 用户在步骤3中输入认证信息。如果登录成功，CAS会随机生成一个相当长的、唯一的、不可伪造的密码，并缓存起来以供将来验证。 之后，系统自动重定向到该地址并将其设置为客户端浏览器。 一（TGC）CAS获取并重新生成后，与步骤5、6中的CAS进行身份验证，确保合法性。

2、本协议中所有与CAS的交互都使用SSL协议，保证ST和TGC的安全。 协议工作过程中会有两次重定向过程，但CAS与CAS之间的验证过程对用户是透明的。

3. CAS如何实现单点登录？

当用户访问其他服务并再次重定向到CAS时，CAS会主动获取这个TGC，然后进行以下操作：

1）如果User持有TGC且未过期，则进入基本协议图第4步，实现SSO效果；

2）如果TGC失败，用户仍需要重新认证（转基本协议图步骤3）。

此外，CAS协议还提供了Proxy模式，以适应更高级、更复杂的应用场景。 详细介绍请参考CAS官网相关文件。

CAS验证流程

1. 用户浏览受系统保护的URL。

2、CAS服务器收到请求，拦截请求，判断用户是否已经登录，如果是则直接进入系统。 否则，请求将转发到 CAS 服务器。

3. 在 中获取用户，并检查该用户是否已成功登录其他使用SSO的相关系统。 如果您已经登录了另一个系统，则该请求将被传输回CAS并带回，CAS将再次发送该请求。 否则，系统会提示用户输入 ID 和 。

4. 提交请求后，CAS将验证有效性。 然后将结果返回给CAS。 如果有效，CAS 应允许用户浏览受保护的资源。 否则，重定向到登录页面，提示用户输入 ID 和 .

5. 验证 ID 和是否匹配。 如果不匹配，则系统会再次要求用户输入 ID 和 。 否则，CAS记录用户登录成功。 并发送回浏览器记录用户登录成功。 如果浏览器不支持，则无法实现单点登录。

用户访问流程流程示例

当用户第一次访问CAS服务的客户Web应用时（例如访问URL::8081/web1），客户Web应用中部署的CAS会拦截请求，生成参数，然后转到CAS服务的登录界面。 网址为：8443/cas/login?=http%3A%2F%2F192.168.1.90%%%2F。 认证成功后，CAS服务器会生成认证信息，写入浏览器，并缓存在服务器本地。 CAS服务器也会根据参数生成，保存到服务器，并添加到url末尾，然后将请求返回给客户Web应用程序。 网址为：8081/web1/?=ST-5--20。

这时候客户端看到参数后就会跳过它，由后面的ER处理。 ER将使用该工具访问cas服务的/接口，并将两者传递给该接口以验证该接口的有效性。 如果 er 得到 验证成功，则用户信息将被写入 Web 应用程序中。

至此，SSO会话已经建立。 以后用户在同一个浏览器中访问这个Web应用时，会在那里读取用户信息，因此不会进行CAS认证。 如果用户在这个浏览器中访问其他Web应用程序时，如果这里无法读取用户信息，就会去CAS的登录界面进行认证。 不过此时 CAS 会读取浏览器发送过来的信息，所以 CAS 不会要求用户登录登录页面，而只会根据参数生成。 一，然后与 Web 应用程序进行经过验证的交互。

如何在代码层面实现CAS

现在我们知道了工作原理和流程，我们来看看如何用代码实现CAS。

一般来说，我们在编写Web应用的时候，只需要熟悉这些就可以了。 如果我们不需要 https 连接，我们甚至不需要熟悉第一个。 但肯定有人在想，这些和我的数据库有什么关系呢？ 别担心，这些并不直接处理用户的认证，也不直接处理用户的授权，而是交给认证管理器和决策管理器。

对于这两个管理器，我们不需要编写代码。 Acegi 还提供现成的课程。 那么大家又疑惑了：既然是现成的，那怎么和我的数据库关联起来呢？ 别担心，事实上，这两位经理自己什么也不做。 认证管理器将任务交给决策管理器，决策管理器将任务交给Voter，如下图：

现在我想告诉大家，这里和Voter不需要我们写代码。 别崩溃，你就快到了。 Acegi提供了多个实现类，这意味着CAS认证方法有很多种。 我们可以从数据库中检索用户帐户信息，或者在 XML 文件中检索用户密码。 对于很多方法，CAS提供了一种灵活但相同的接口/实现分离方法，我们可以决定CAS使用哪种认证方法，即这个认证的实现细节可以自己定制和扩展。 例如，如果我们想使用数据库来存储用户认证数据，那么我们选择vider。 对于Voter来说，我们一般选择够用即可。 它会根据我们配置文件中的设置来决定是否允许某个用户访问指定的Web资源。

而vider并不直接操作数据库，它是委托任务，如下图：

而我们要做的就是实现这一点。 说了这么多，终于到了我们开发的关键点了，那就是我们要实现自己的，就是连接我们的数据库和Acegi的桥梁。 需求也很简单，只需要一个返回org....User对象的()方法。 因此，你可以用任何方式设计数据库，无论我们使用一张表、两张表还是三张表，或者我们使用用户授权、用户角色授权或用户用户组角色授权。 这些具体的Acegi不关心任何事情，它只关心返回的User对象。 至于如何从数据库中读取数据，那是我们自己的事了。

依次看上面的过程我们发现，即使我们要做的只是实现自己的类，我们也要在里面配置很多的Bean，包括几个、几个、几个和Voter，而这些配置往往是重复且不必要。 幸运的是，Acegi 2.0也认识到了这个问题，因此设计了一个标签来简化Acegi的配置。

这些细节我们会在后面具体的部署实现中详细讲到。

CAS相关接口和处理逻辑介绍 概念介绍 CAS的核心是它以及在它之上的一系列处理操作。 CAS的主要法案有TGT、ST、PGT、PT。 TGT、ST是CAS1.0协议包含的话单，PGT、PT是CAS2.0协议包含的话单。

TGT()

TGT是CAS为用户发放的登录凭证。 通过TGT，用户可以证明自己已经成功登录CAS。 TGT封装了该值以及该值对应的用户信息。 用户CAS认证成功后，生成CAS并写入浏览器。 同时生成一个TGT对象并放入自己的缓存中。 TGT 对象的 ID 就是该值。 当另一个HTTP请求到来的时候，如果传递的这个是CAS生成的，CAS就用这个值作为key去查询缓存中是否有TGT。 如果有，则说明该用户之前已经登录过。 如果没有，用户需要重新登录。 。

英石（ ）

ST是CAS发行的供用户访问某个区域的票证。 用户访问时发现用户没有ST，需要用户去CAS获取ST。 用户向CAS发送请求获取ST。 如果用户的请求包含它，CAS就会以这个值作为key来查询缓存中是否有TGT。 如果存在TGT，则使用该TGT签发ST并返回给用户。 用户依靠ST进行访问，并使用ST转CAS进行验证。 验证通过后，允许用户访问该资源。

PGT(代理)

代理的代理凭据。 用户通过CAS成功登录Proxy后，CAS会生成一个PGT对象并缓存在CAS本地。 同时，PGT值（一个UUID字符串）被传回Proxy并存储在Proxy中。 Proxy获得PGT后，可以作为（后端）的代理，为其申请PT。

（代理借据）

它是CAS协议中定义的附加票据，增强了传输和获取PGT的安全性。

传输和获取PGT的过程：Proxy调用CAS接口验证ST成功后，CAS会首先访问指向的https url，并将生成的PGT传输给Proxy。 proxy会将key视为key，将PGT视为value，并将其存储在Map中。 在; 然后CAS会生成一条验证ST成功的xml消息返回给Proxy。 xml 消息包含该值。 代理收到Xml消息后，会解析其中的值，然后将其作为键在map中查找PGT的值。 ，将其赋值给代表用户信息的对象的pgtId，并在map中删除。

PT（代理）

PT 是用户访问（后端）票证。 如果用户正在访问Web应用，Web应用会要求浏览器提供ST，浏览器会使用CAS获取ST，然后就可以访问Web应用了。 如果用户访问的不是Web应用，而是C/S结构的应用，由于C/S结构的应用不可用，用户无法自行去CAS获取ST。 相反，他访问代理接口并依赖代理。 PGT 在访问此应用程序之前会先获得 PT。

类和方法

CAS类图如下：

方法

方法声明：(final id,final,final,final)

方法说明：

1：生成

2：更新属性：

这。 = 这个。；

这。 = .();

这个.++;

3：给对象的属性赋值

4：将对象放入地图中

票务法