CAS方式实现单点登录

单点登录，英文是 Single Sign On，缩写为 SSO。
多个站点(192.168.1.20X)共用一台认证授权服务器(192.168.1.110，用户数据库和认证授权模块共用)。用户经由其中任何一个站点(比如 192.168.1.201)登录后，可以免登录访问其他所有站点。而且，各站点间可以通过该登录状态直接交互。

CAS Server 为需要独立部署的 Web 应用。
CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。下图是 CAS 最基本的协议过程：

1. 访问服务：SSO客户端发送请求访问应用系统提供的服务资源。

2. 定向认证：SSO客户端会重定向用户请求到SSO服务器。

3. 用户认证：用户身份认证。

4. 发放票据：SSO服务器会产生一个随机的Service Ticket。

5. 验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。

6. 传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。

生活化例子：

现在我们知道了单点登录给我们所带来的好处，但是我们并不知道它是如何工作的。由于CAS协议的执行流程较为复杂，因此，让我们首先来看一个生活中的与单点登录相似的事例，以辅助我们对单点登录运行流程的理解。

　　假设公司马上就要来一位新同事，公司的行政人员需要在该同事到来前为他置办好日常工作所需要的各种办公用品。这些办公用品包括工作用的电脑以及一套全新的办公桌椅。在置办完这些办公用品后，该行政人员还要拿着购买办公用品时所开具的发票去公司的财务部报销。为了节省时间，该行政人员将会使用公司车辆在公司和卖场之间运送货物。

　　由于公司的司机常常在外奔波，因此他可能并不知道当天需要载着这位行政人员去购买办公用品。在该行政人员找到他之后，他无法确认行政人员的用车安排是否与公司的其它安排相冲突。因此司机会让行政人员打电话给公司的领导确认他是否可以用车。领导接到了该行政人员的电话并陈述用车的缘由后，行政人员会将电话转交给司机，让司机本人与领导沟通。在得到了领导的肯定答复后，司机就可以放心地载着该行政人员去电脑城购买电脑了。

　　当该行政人员在当天再次找到该司机说需要购买办公桌椅的时候，该司机就不再需要打电话询问领导。因为他已经打电话和领导询问过是否该行政人员需要用车的事情。

　　在所有的办公用品置办完毕以后，该行政人员就会去公司的财务处报销。在见到财务人员之后，该行政人员会直接说和领导之前已经沟通过并得到过批准。在该财务人员直接打电话给该领导并简单提起购买办公用品的事情后，领导就会很快地确认需要为一位新来的员工购买办公用品的事情。在得到了肯定的答复后，该财务人员将直接接受报销申请并迅速进入结算程序。

　　在整个过程中，行政人员都是资源的访问者及使用者。在每次尝试使用这些资源时，资源的管理者都需要领导的批准来给与该行政人员使用资源的权利。只是在不同时刻，由于领导及资源管理者所得到的信息量并不相同，因此产生了三种不同的使用资源的流程。

　　在第一次用车的时候，由于司机和领导都不清楚当天该行政人员需要用车，因此该行政人员需要从领导那里得到可以用车的许可，并将领导的许可转交给司机，进而真正获得使用公司车辆的权利。在该过程中，行政人员既需要与司机沟通，又需要与领导沟通，而司机也需要与领导沟通。

　　在第二次用车的时候，由于司机已经知道领导对于车辆使用的授权，因此他不再需要额外的沟通而直接允许该行政人员使用公司车辆。在该过程中，行政人员只需要和司机沟通，而不再需要与领导打招呼。

　　而在报销的过程中，由于财务人员并不知道购买办公用品是否已经获得了领导的同意，因此需要询问领导。而此时领导已经知道财务人员是为了新入职的同事准备的办公用品，因此将直接同意对该笔款项进行报销，也不再需要行政人员再次向领导解释公司将来一名新员工的事宜。在该过程中，财务人员需要与行政人员以及领导沟通。

CAS协议的运行流程实际上与上面所举示例的运行基本一致：第一次访问一个应用时，系统将要求用户转到SSO系统，输入表示自己身份凭证的用户名和密码，才能得到访问该应用的权限。而在第二次访问同一应用的时候，由于应用已经知道该用户曾经获得了访问权限，因此将直接允许用户对该应用进行访问。如果用户访问另一个应用，那么该应用将会根据用户当前所得到的身份凭证去SSO系统认证，从而得知用户已经拥有了对该应用的访问权限。

CAS第一次登陆：

上面的流程图列出了用户在第一次登录应用时所需要经历的步骤。首先，用户通过在浏览器的地址栏中键入https://app.ambergarden.com来尝试访问应用。由于此时应用会话并没有被创建，因此应用将拒绝用户的登录请求，并通过302响应将用户重定向到https://sso.ambergarden.com以要求用户首先通过SSO进行登录。注意在该重定向所标明的地址中包含了一个额外的URL参数service。其标示了用户原本想要访问的应用所在的位置。在浏览器接收到了302响应后，其将自动跳转到SSO。由于SSO中也没有与浏览器建立相应的会话，因此其将返回给用户一个登录界面，要求用户通过输入用户名和密码完成登录。在用户输入了用户名/密码并点击登录按钮后，页面逻辑将发送一个POST请求到SSO中以建立会话。如果用户登录成功，那么SSO将返回一个302重定向响应，并且该重定向响应中由Location所标明的地址还带了一个额外的参数ticket。在浏览器接收到该重定向响应之后，其将向重定向地址发送一个GET请求，并且该请求中还包含了刚刚从SSO所返回的ticket参数。在应用接受到该请求后，其将使用ticket参数所标明的凭据向SSO发送请求以验证该凭据的合法性。如果验证成功，那么应用将会认为当前对应用的访问是一个已经得到SSO认证的合法用户发起的，进而为该用户创建会话。

在浏览器再次访问该应用的时候，由于应用已经为当前浏览器创建了相应的会话，因此应用将能识别出它是一个合法的经过SSO验证的用户：

相较于对应用的第一次访问而言，第二次访问的流程图实际上就非常容易理解了。实际上，这就是在已经建立了会话之后再次访问应用时的流程图。

而在访问其它应用时，CAS协议运行的流程图将如下所示：

首先，用户尝试访问处于https://app2.ambergarden.com下的应用。由于之前用户并没有登录过该应用，因此该应用发送一个302请求来将用户重定向到SSO服务。而这里的URL参数service与首次登录时候的意义一样，用来在这一系列通信中记录登录成功后所需要返回到的服务地址。

　　浏览器一旦接收到了302响应，那么其将立刻执行重定向并访问SSO服务。由于用户在之前访问第一个应用的时候已经建立了SSO会话，因此SSO服务将立即返回一个302响应，并在响应的Location中使用URL参数ticket标示用户从SSO所得到的凭据。在接到302响应后，浏览器再次重定向，并访问应用。应用同样使用ticket所标示的凭据向SSO请求验证。在验证成功后，应用将会认为当前访问用户是合法的，因此将为该用户创建会话。在该过程中，用户没有输入任何信息，而只经过了几次浏览器跳转就验证了用户的合法性。