SSO单点登录-CSDN博客

sso 单点登陆原理

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

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

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

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

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

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

目前能够找到的最好的开源单点登录产品CAS也是采用Cookie机制。 CAShttp://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的客户端），而不再需要输入用户名和密码。