采用CAS原理构建单点登录

     企业的信息化过程是一个循序渐进的过程，在企业各个业务网站逐步建设的过程中，根据各种业务信息水平的需要构建了相应的应用系统，由于这些应用系统一般是 在不同的时期开发完成的，各应用系统由于功能侧重、设计方法和开发技术都有所不同，也就形成了各自独立的用户库和用户认证体系。随着新的业务网站不断的增 加，用户在每个应用系统中都有独立的账号，这样就造成在访问不同的应用系统时，需要记录对应的用户名和密码，多个用户名密码极易记混，如果忘记或记错了某 一个业务网站的用户名或密码就无法进行登录，耽误工作，影响工作效率，随着局内信息化进程的推进还会有新的应用系统产生，如果不引入单一用户登录的解决方 案，全公司工作人名特别是承担审批权限的各级领导很难记清各类应用系统的用户名和密码，严重影响由信息化带来快捷性和高效性。此外，多个应用平台就有多个 用户管理，这也为系统管理员维护人员系统带来巨大的工作量，例如，一次变更10个人员，即使只有5个应用系统，也需要重复维护50个人员信息，而企业的每 次人员调整远不至10人，这种几何增长的维护工作量，会浪费大量的精力和时间，减弱了信息化系统带来方便快捷，为此，需建立一套统一的、完善的、科学的单 点登录系统，每个用户只需记录一个用户名密码，登录一个平台后即可实现各应用系统的透明跳转，而且实行统一的用户信息管理系统，系统管理员只需维护一套人 员信息，更改信息通过平台接口同步更新至各个应用系统，实现人员系统单次维护全公司同步变更，大大提高工作效率。

      新的应用系统在不断开发，早一天规划设计出单点登录的规范接口，就可以为新开发的系统提出的一种整合的标准，在开发初期无论哪个开发商，无论采用哪种技术 开发，只要遵循单点登录的规范标准，新的系统开发完成之后即可无缝整合的到单点登录平台中，从而减少了系统开发完成后再整合到单点登录改动而造成资源的浪 费。

      从信息共享角度看现有的各个业务系统都使用各自的数据存储方式，不经过基础的用户名和密码认证后，相互之间无法传递有效信息。为避免信息孤岛的产生，因此 需要建立一个连接各个业务系统的技术架构和标准，实现平台统一化整合；通过对业务处理和异常处理实现监管透明；通过将业务流程从应用中抽离，实现业务流程 的灵活安排，这样就需要一套可以整合现有各个业务网站的信息共享平台。

      单点登录的英文名称为Single Sign-On，简写为SSO，它是一个用户认证的过程，允许用户一次性进行认证之后，就访问系统中不同的应用；而不需要访问每个应用时，都重新输入密码。IBM对SSO有一个形象的解释“单点登录、全网漫游”。

SSO将一个企业内部所有域中的用户登录和用户帐号管理集中到一起，SSO的好处显而易见：

• 减少用户在不同系统中登录耗费的时间，减少用户登录出错的可能性
• 实现安全的同时避免了处理和保存多套系统用户的认证信息
• 减少了系统管理员增加、删除用户和修改用户权限的时间
• 增加了安全性：系统管理员有了更好的方法管理用户，包括可以通过直接禁止和删除用户来取消该用户对所有系统资源的访问权限

对于内部有多种应用系统的企业来说，单点登录的效果是十分明显的。很多国际上的企业已经将单点登录作为系统设计的基本功能之一。

      公司第一个版本的单点登陆系统从2005年运行以来，从几十个应用系统扩展到现在的几百个系统。在应用的过程中没有很好的解决跨域名的问题，单点登陆客户端代码使用问题，应用系统的访问规则问题等都没有很好的解决。

      SSO的实现机制不尽相同，大体分为Cookie机制和Session机制两大类。

• WebLogic通过Session共享认证信息。Session是一种服务器端机制，当客户端访问服务器时，服务器为客户端创建一个惟一的 SessionID，以使在整个交互过程中始终保持状态，而交互的信息则可由应用自行指定，因此用Session方式实现SSO，不能在多个浏览器之间实 现单点登录，但却可以跨域。
• WebSphere通过Cookie记录认证信息。Cookie是一种客户端机制，它存储的内容主要包括: 名字、值、过期时间、路径和域，路径与域合在一起就构成了Cookie的作用范围，因此用Cookie方式可实现SSO，但域名必须相同。

     目前大部分SSO产品采用的是Cookie机制，公司第一个版本的单点登陆系统也是如此，目前能够找到的最好的开源单点登录产品CAS也是采用Cookie机制。 CAS http://www.ja-sig.org/products/cas/，CAS 单点登录系统最早由耶鲁大学开发。2004年12月，CAS成为JA-SIG中的一个项目。JA-SIG的全称是Java Architectures Special Interest Group，是在高校中推广和探讨基于Java的开源技术的一个组织。CAS的优点很多，例如设计理念先进、体系结构合理、配置简单、客户端支持广泛、技 术成熟等等。这也是我们这次SSO改造的参照产品。

以CAS为例，使用Cookie实现单点登录的原理图如图1所示。

• 首先，单点登录分为“服务端”和“客户端”。服务端就是单点登录服务器，而客户端通常是“函数库”或者“插件”。需要使用单点登录的应用程序，需要把客户 端插件安装到自己的系统中，或者将客户端函数库包括在代码中。单点登录的客户端通常替换了原来应用程序的认证部分的代码。
• 某个应用程序首先要发起第1次认证。大部分情况下，应用程序中嵌入的客户端会把应用程序原来的登录画面屏蔽掉，而直接转到单点登录服务器的登录页面。

           图 1 使用Cookie实现单点登录的原理图

• 用户在单点登录服务器的登录页面中，输入用户名和密码。
• 然后单点登录服务器会对用户名和密码进行认证。认证本身并不是单点登录服务器的功能，因此，通常会引入某种认证机制。认证机制可以有很多种，例如自己写一 个认证程序，或者使用一些标准的认证方法，例如LDAP或者数据库等等。在大多数情况下，会使用LDAP进行认证。这是因为LDAP在处理用户登录方面， 有很多独特的优势，这在本文的后面还会比较详细地进行介绍。
• 认证通过之后，单点登录服务器会和应用程序进行一个比较复杂的交互，这通常是某种授权机制。CAS使用的是所谓的Ticket。具体这点后面还会介绍。
• 授权完成后，CAS把页面重定向，回到Web应用。Web应用此时就完成了成功的登录（当然这也是单点登录的客户端，根据返回的Ticket信息进行判断成功的）。
• 然后单点登录服务器会在客户端创建一个Cookie。注意，是在用户的客户端，而不是服务端创建一个Cookie。这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。
• 如果用户此时希望进入其他Web应用程序，则安装在这些应用程序中的单点登录客户端，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户 输入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。登录之后，CAS重定向回到用户的应用程序。

这样，就不再需要用户继续输入用户名和密码，从而实现了单点登录。

注意，这种单点登录体系中，并没有通过http进行密码的传递（但是有用户名的传递），因此是十分安全的。

CAS被设计为一个独立的Web应用，目前是通过若干个Java servlets来实现的。CAS必须运行在支持SSL的web服务器至上。应用程序可以通过三个URL路径来使用CAS，分别是登录URL（login URL），校验URL（validation URL）和登出URL（logout URL）。

• 应用程序一开始，通常跳过原来的登陆界面，而直接转向CAS自带的登录界面。当然也可以在应用程序的主界面上增加一个登录之类的按钮，来完成跳转工作。
• 如果用户喜欢的话，也可以手工直接进入CAS的登录界面，先进行登录，在启动其他的应用程序。不过这种模式主要用于测试环境。
• CAS的登录界面处理所谓的“主体认证”。它要求用户输入用户名和密码，就像普通的登录界面一样。
• 主体认证时，CAS获取用户名和密码，然后通过某种认证机制进行认证。通常认证机制是LDAP。
• 为了进行以后的单点登录，CAS向浏览器送回一个所谓的“内存cookie”。这种cookie并不是真的保存在内存中，而只是浏览器一关 闭，cookie就自动过期。这个cookie称为“ticket-granting cookie”，用来表明用户已经成功地登录。
• 认证成功后，CAS服务器创建一个很长的、随机生成的字符串，称为“Ticket”。随后，CAS将这个ticket和成功登录的用户，以及服务联系在一起。这个ticket是一次性使用的一种凭证，它只对登录成功的用户及其服务使用一次。使用过以后立刻失效。
• 主体认证完成后，CAS将用户的浏览器重定向，回到原来的应用。CAS客户端，在从应用转向CAS的时候，同时也会记录原始的URL，因此CAS知道谁在调用自己。CAS重定向的时候，将ticket作为一个参数传递回去。
• 例如原始应用的网址是http://www.itil.com/，在这个网址上，一开始有如下语句，转向CAS服务器的单点登录页面https: //secure.oa.com/cas/login?service=http://www.itil.com/auth.aspx。
• CAS完成主体认证后，会使用下面URL进行重定向http://www.itil.com/authenticate.aspx?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。
• 收到ticket之后，应用程序需要验证ticket。这是通过将ticket 传递给一个校验URL来实现的。校验URL也是CAS服务器提供的。
• CAS通过校验路径获得了ticket之后，通过内部的数据库对其进行判断。如果判断是有效性，则返回一个NetID给应用程序。
• 随后CAS将ticket作废，并且在客户端留下一个cookie。
• 以后其他应用程序就使用这个cookie进行认证（当然通过CAS的客户端），而不再需要输入用户名和密码。

采用.NET 来实现CAS原理的SSO系统，在第一个版本的SSO系统基础上罗列一些问题，有的已经是第一个版本的SSO系统中采用的方式。有些问题需要澄清的，

很多人谈论单点登录时，常常和统一用户，以及单一用户管理混淆了，要么误认为单点登录自然实现了单一用户管理；要么误认为统一用户或者单一用户管理就是单点登录。实际上，这三个概念是有明确的区别的。

统一用户就是指不同的系统，使用同一套用户处理的机制。

• 用户ID全局惟一，用户登录名，密码全局唯一，并且统一存储在单一系统中。
• 用户的一些属性，如姓名、电话、地址、邮件等，统一存储在单一系统中。尽管各应用系统还可以自行增加一些属性，但是基本的属性应该统一存储和管理。
• 应用系统不应该直接对用户信息的进行增加、修改和删除，但是可以进行查询。对用户信息的增加、修改和删除，应该由专门的系统进行统一的管理。

很显然，统一用户是单点登录的基础，但是统一用户并不意味着实现了单点登录。

单一用户管理则指所有的用户管理工作都在唯一的地方进行处理，而每个应用程序不再保留自己的用户管理功能。单一用户管理和统一用户管理的最大区别在于，统 一用户管理之后，每个应用程序仍然保留自己的用户管理功能，用于额外的属性设置；而单一用户管理时，每个应用程序不再保留自己的用户管理功能。

在企业应用场景下，所有的用户信息来自HR系统，HR系统中包含的户信息和部门信息，同时这些信息会存在于公司的活动目录中。公司采用的是LDAP和数据 库连接方式相结合,正式员工登陆OA系统并不采用LDAP方式认证，采用的RSA的token方式认证，也就是数据库方式认证。对于忘记带token卡和 客户服务部的外聘人员没有token卡的，通过白名单方式允许他们通过LDAP方式认证。第一个版本的单点登陆系统使用的HTTP，新版本的集成子系统使 用https方式通讯。

术语解释：

• HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容 请看SSL。它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同 于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司进行，提供了身份验证与加密通讯方法，现在它被广 泛用于万维网上安全敏感的通讯。
• LDAP（全称是Lightweight Directory Access Protocol），一般都简称为LDAP。它是基于X.500标准的，但是简单多了并且可以根据需要定制。与X.500不同，LDAP支持 TCP/IP，这对访问Internet是必须的。LDAP的核心规范在RFC中都有定义，所有与LDAP相关的RFC都可以在LDAPman RFC网页中找到。

• 简单说来，LDAP是一个得到关于人或者资源的集中、静态数据的快速方式。LDAP协议是跨平台的和标准的协议，因此应用程序就不用为LDAP目录放在什 么样的服务器上操心了。实际上，LDAP得到了业界的广泛认可，因为它是Internet的标准。产商都很愿意在产品中加入对LDAP的支持，因为他们根 本不用考虑另一端（客户端或服务端）是怎么样的。LDAP服务器可以是任何一个开发源代码或商用的LDAP目录服务器（或者还可能是具有LDAP界面的关 系型数据库），因为可以用同样的协议、客户端连接软件包和查询命令与LDAP服务器进行交互。

cas sso原理（转）