集成基于CAS协议的单点登陆

　　相信大家对单点登陆（SSO，Single Sign On）这个名词并不感到陌生吧？简单地说，单点登陆允许多个应用使用同一个登陆服务。一旦一个用户登陆了一个支持单点登陆的应用，那么在进入其它使用同一单点登陆服务的应用时就不再需要重新登陆了。而CAS协议则正是各单点登陆产品所需要实现的协议，其全称为Central Authentication Service。

　　那为什么要写这篇博客呢？这是因为在为公司的产品集成SSO的时候，我发现如果软件开发人员不了解CAS协议，那么他在集成出现错误的时候将完全没有办法对出错的原因进行分析。

 

单点登陆简介

　　如果您不知道单点登陆是什么，那么先来体会一次单点登陆。首先，请在一个全新浏览器（或者清除了登录信息缓存的浏览器）的地址栏中键入www.hotmail.com，并进入您的hotmail邮箱。接下来，我们再访问www.msn.com。请看网页的右上角，您会发现您已经成功地通过刚刚的hotmail邮箱登入了www.msn.com：

　　这就是单点登录：即使hotmail和msn的域名表明它们完完全全就是两个不同的网站，但是由于它们使用了同一个单点登录服务，因此在登陆hotmail之后再登陆msn，您刚刚输入的用户身份凭证依然有效。

　　这种在一处登录就能直接访问其它应用的功能在企业级应用中是非常有用的。试想这样一个情景：在每天的工作中，我们总需要通过浏览器访问几十个系统。如在浏览器中阅览公司邮件，在需要撰写Wiki的时候需要登录到公司的Wiki系统。而报销，请假，公司共享文件服务器等都需要用户登陆。而且如果一个公司的IT部门对安全比较重视，那么他们还会要求员工在一定时间内更换一次密码。试想一下，如果公司内部有几十个系统，那么每个员工都需要维护几十个密码，并且每隔几天就需要针对一个系统更改一个密码。这种密码管理的开销无论对于员工本身还是对于IT开销都是巨大的。

　　反过来，如果这些系统都使用同一个用户登录服务，那么我们就可以免除在每次登入一个系统时都要输入密码的开销，而且每个员工只需要管理一个密码。

　　因此，如果希望自己的企业级应用能够成功地进入各个大型企业，那么这个产品就必须支持标准的单点登录协议，即CAS协议。而只有在正确地理解了CAS协议的基础之上，我们才能在我们的产品中正确地添加对单点登录的支持。而这也便是我写这篇文章的真正原因。

 

CAS协议的工作流程

　　现在我们知道了单点登录给我们所带来的好处，但是我们并不知道它是如何工作的。由于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请求验证。在验证成功后，应用将会认为当前访问用户是合法的，因此将为该用户创建会话。在该过程中，用户没有输入任何信息，而只经过了几次浏览器跳转就验证了用户的合法性。

 

CAS协议集成

　　好了，在了解了基于CAS协议的SSO是如何工作的之后，我们就可以开始考虑如何在应用中集成对CAS协议的支持了。

　　我们所要做的第一步就是分析上面所讲的各个流程中的每一步对CAS协议所定义的各接口，进行使用的方式。在分析的过程中，我们需要时刻提醒自己是在为我们的应用添加CAS协议支持，而不是实现一个基于CAS协议的SSO。这会导致我们在查看CAS协议时的角度与实现一个基于CAS协议的SSO有以下几点不同：

1. 不必要理解CAS协议中的所有接口以及各接口中的所有参数。CAS协议中列出的很多接口实际上都是用来在浏览器和SSO服务之间进行交互的。因此我们不必要非常仔细地察看这些接口，而只需要知道这些接口所执行的功能以及产生的数据即可。而且即使是我们会用到的接口中也会有一部分参数并不会被用到。我们只需要关注在我们的应用使用SSO流程中所可能涉及到的各个参数即可。
2. 需要注意在流程中浏览器与应用之间的交互。在前面所展示的各个流程图中已经能够看到，应用是通过一系列302重定向响应等HTTP标准方法来完成将用户重定向到SSO服务这一动作的。

　　那么我们回过头来回忆一下用户首次登陆成功的流程图：

　　在该流程图里面，我们需要关心的就是到底谁与应用产生了交互，以及在交互过程中使用了什么样的接口及参数。可以看到，在用户通过浏览器第一次访问应用的时候，应用需要返回给用户一个302响应，而响应中所指定的地址就是SSO所提供的登陆接口。因此我们要做得第一步就是要理解Login这个URL所做的工作。

　　从API文档中可以看到，Login这个URL可以提供两种服务：请求用户输入身份凭证（Credential Requester）以及验证用户的身份凭证（Credential Acceptor）。在这张流程图里面，我们两次向该URL发送请求。第一次请求所使用的是该URL的第一种服务，该服务将请求用户输入用户的身份凭证，如显示一个登陆页面。而在用户输入了用户名和密码后，向该URL发送的请求就将使用第二种服务。在这两次请求中，URL中的service参数用来标明用户成功登陆后从SSO重定向出来时所需要跳转到的地址。由于我们是在为自己的应用添加SSO支持，那么该服务自然需要指向我们的应用。

　　OK，现在我们就可以开始第一步集成了。该步骤的工作就是：当一个用户访问应用的时候，如果应用中没有该用户所对应的会话，那么返回302响应，并在响应中标示跳转的地址为SSO所在的地址，并在service参数中标明我们的应用所在的地址。如果这一切功能都正确地实现，那么对应用的访问会自动跳转到SSO服务，并在成功登陆后再次请求访问我们自己的应用。此时的访问会传入一个URL参数ticket以表示从SSO处得到的凭证。

　　如果正确地完成了第一步的集成，那么我们就可以开始集成的第二个步骤了，那就是向SSO服务验证用户。在第一步中，SSO最终验证了用户的身份并向浏览器中返回了一个302响应。浏览器接收到该302响应后，其便向302响应所标示的地址进行跳转。在应用接受到了包含ticket参数的请求后，它需要使用该ticket参数所记录的信息来访问serviceValidate接口，以验证所传入的ticket参数是否是一个真正的从SSO所返回的凭据。一旦验证成功，那么该用户就是一个合法用户。此时应用就需要为该用户创建一个会话并将他重定向到程序的初始页面，如应用的Dashboard等。

　　而在用户再次访问应用的时候，由于应用中已经包含了该用户所对应的会话，因此其不会再与SSO产生交互，因此也不再需要为SSO集成做任何工作。同样的，由于第三个流程也使用了同样的接口，因此我们也不再需要做任何额外的工作。

　　就这样，仅仅通过这两步，我们就可以完成对SSO登陆功能的集成了。是不是很简单？

　　除此之外，我们还可以选择支持Single Logout（有些讨论里面叫Single Sign Off）。但是反对该功能的人也不少。其中的原因就因为用户常常认为点击Logout按钮是从当前应用中安全地退出，但是这实际上导致用户所登陆的所有使用该SSO服务的应用都将退出。因此在决定对该功能进行支持之前一定要考虑清楚该功能是否会真的为用户带来好处。

 

需要注意的问题

　　就像大家在上面所看到的一样，在应用中集成对SSO的支持实际上并不需要多少工作。甚至可以说，一个有相关经验的人可以在几个小时内就能完成。但是反过来说，如果在集成中没有注意到一些问题，那么这些问题可能会耽误您几天的时间。因此在本节中，我会简单地说一下我在SSO集成中的一些经验。

　　首先就是CAS协议的API文档的阅读方法。我一直认为，对于这种侧重于流程的协议，协议的运行流程以及在该流程中的数据流是关键。因此一上来就冲到API文档中并尝试理解每个接口的含义，输入及输出并不是一个好的办法。可能对于外国人而言，先了解接口再弄懂运行流程是一种比较简单的方式，但是似乎这种方式并不太适合中国人的思维。这也就是我为什么一上来就讲解SSO的运行流程的原因。

　　而在CAS协议的API文档中，对ticket进行验证的接口有好几套，如第一版中的/validate接口在第二版中演进为/servicevalidate和/proxyvalidate两个接口等。请根据需要选择相应的一套接口即可。

　　一个需要注意的地方就是，很多SSO里面都有一个Filter，用来标示允许使用该SSO服务的各个应用。该Filter会阻止非法应用从SSO服务登陆。否则该非法应用将可以尝试对SSO展开攻击。举一个最简单的DDOS攻击的例子。在我的一篇博客里已经介绍过对用户名/密码对的验证实际上是一个较为耗时的行为，因此该步是SSO服务中最为脆弱的地方。如果一个恶意人员盯上了该SSO服务，并在一个用户群基数较大的网站上找到了漏洞，更改了它的SSO服务配置，那么该网站的用户就会在登陆该网站的时候跳转到该SSO服务。接下来这些用户就会尝试用他们的用户名/密码对在该SSO服务上登陆，从而在这些用户的帮助下展开了DDOS攻击。因此在通常情况下，SSO服务都会配置一个白名单。而在进行SSO集成之前，我们则首先需要向该白名单中添加我们的应用。

　　还有一个比较容易被忽略的问题就是会话的时效性问题。在整个SSO的使用中存在着两种会话：用户在应用程序中的会话以及用户在SSO服务上的会话。在一般情况下，SSO服务上的会话持续时间都会比应用程序中的会话时间略长。这样在应用程序的会话过期时，用户可以直接通过刷新页面等方式从SSO服务重新建立会话。但是在进行集成时，为了调试方便，我们常常会将应用会话时间调整得很长，甚至长于SSO服务上的会话时间，从而没有测试应用程序会话过期进而通过SSO会话来刷新应用程序会话的情况。

 

Reference

CAS协议：http://jasig.github.io/cas/development/protocol/CAS-Protocol-Specification.html

 

转载请注明原文地址并标明转载：http://www.cnblogs.com/loveis715/p/4491417.html