Java单点登录在校园身份管理系统中的实现

 

java单点登录在校园身份管理系统中的实现

摘要:

一个学校或企业的内部有很多信息系统，用户登录这些系统时需要进行身份认证。传统的认证机制是基于用户名和密码的，每一个系统都建立有自己的用户信息数据库，用来验证用户的身份。对于一个要访问处于不同系统中资源的用户，每进入一个系统就要登录一次，这无疑会耗费大量的时间，同时用户也需要记忆大量的账号信息。

单点登录系统就是为了解决这样一个问题而产生的，它把实际用户映射成一个电子身份，并可以将其安全、高效地传递给各个系统。这样，用户只需要参与一次身份认证过程，获得其电子身份标识。以后单点系统自动将该身份标识传递到各个系统进行身份认证，从而使用户可以高效地访问各个系统中的资源，提高工作效率。

本文阐述了单点登录的概念，优势，以及单点登录在基于Sun ONE的校园身份管理系统中的实现。

关键字：

单点登录

跨域单点登录

网络身份

轻量级目录访问协议

身份认证服务器

目录服务器

目     录

 

第一章 绪论... 1

1.1 项目背景... 1

1.2 系统介绍... 1

1.3 本文的工作... 2

第二章 网络身份管理策略... 3

2.1网络身份的内容... 3

2.2 身份管理的发展... 4

2.3 Sun开放网络环境概述... 9

第三章 系统结构... 11

3.1 系统环境... 11

3.2 功能设计... 12

第四章Sun ONE Identity Server 应用分析... 14

4.1 Sun ONE Identity Server 简介... 14

4.2 Sun ONE Identity Server 的基本组件... 14

4.3 Sun ONE Identity Server API 分析... 16

4.4 Sun ONE Identity Server特点以及扩展... 18

第五章SSO在校园身份管理系统中的实现... 20

5.1 单点登录（SSO）的实现... 20

5.2 跨域单点登录（CDSSO）的实现... 22

5.3 Web服务的部署... 23

5.4校园身份管理系统中单点登录的具体实现... 24

5.5 校园身份管理系统中单点登录的测试... 32

第六章 总结与展望... 36

6.1 总结... 36

6.2 系统的不足与展望... 36

致  谢... 37

参考文献... 38

第一章 绪论

1.1 项目背景

近年来，Web技术在政府、公司、学校中的使用已经出现了爆炸性的增长，通过Web提供的信息和应用越来越多。随着Web的使用进入成熟阶段，成功地管理和保护部门的Web资源已经成为一个越来越复杂的挑战。

身份认证管理是保护部门Web资源的核心部分。如今，内部网络登录服务、各种组织、商业服务等要求身份认证的需求者将一个人在网络上的身份分割成许多独立的碎片。这些碎片构成了繁多的一对一的客户服务关系，导致了更多的安全风险。

以学校为例，一个学校的内部有很多的信息系统，如学籍管理系统、电子邮件系统、文件共享服务器、成绩管理系统、图书馆信息系统等，每个用户在这些系统上都有账号，以前他们需要在每个系统上配置为各个账号分配的权限，由于系统过多，很容易出现遗忘，出现过用户被分配过高权限后没有及时修改的现象，发生了信息泄露的问题，影响了系统的安全。同时每个用户都需要记住自己在各个系统上的用户名和密码，众多用户同时面对多个系统要重复输入账号、口令等信息，不仅烦琐，更重要的是容易出现口令丢失，给系统和用户造成损失。因此，信息系统急需有一个统一的、具有较高安全控制的身份验证和授权系统，以保证数据安全和用户操作方便。

1.2 系统介绍

基于Sun ONE的校园身份管理系统很好的解决了上述问题，它使用Sun ONE的身份认证服务器，目录服务器，采用单点登录(single sign-on,SSO)的策略。当用户访问多个需要认证的系统应用时，只需要初始进行一次登录和身份认证，就可以访问具有权限的任何系统，而不需要再次登录，后续系统会自动获取用户信息，从而识别出用户的身份。这样，无论用户要访问多少个应用，他只需要进行一次登录，而不需要用户重复输入认证信息。单点登录技术可以简化用户访问多种系统应用，避免用户由于需记忆众多账号信息而出现的遗忘，而且可以减少口令等重要信息在网络传播时被截获的危险。

该系统有很好的用户权限控制粒度，可以整合学校的各种系统，如学籍管理系统、电子邮件系统、文件共享服务器、成绩管理系统、图书馆信息系统等的各种认证信息存放于单一的身份认证服务器中，实现单点认证，全局应用。用户在一点认证就可以根据权限访问整个学校的所有资源。比如用户在登录图书管理服务器时进行了认证，整个系统就知道了给用户的身份，该用户在使用电子邮件服务和文件共享服务时就不需要再认证了，系统会根据他的身份赋予相应的权限；管理员可以在一点改变所有系统上用户的权限，例如管理员通过统一的管理终端将某用户分配特定系统的权限，不用再到各个系统分别配置。

1.3 本文的工作

本文分几个部分介绍了单点登录（SSO）在基于Sun ONE的校园身份管理系统中的实现。第一章，绪论，介绍了项目背景和系统所解决的问题；第二章，介绍了网络身份管理策略和身份管理的发展情况；第三章介绍了基于Sun ONE的校园身份管理系统的系统结构；第四章分析了Sun ONE Identity Server的特点及扩展；第五章详细描述了单点登录在基于Sun ONE的校园身份管理系统中的具体实现；第六章，总结与展望，总结了系统的优缺点，以及今后的改进方向。

第二章 网络身份管理策略

2.1网络身份的内容

身份管理是一个发展很久的名词，在以前的描述中，身份管理曾经被简单地认为是目录管理，或者简单地对用户身份进行数据库式的线性管理。现在，真正的身份管理，已经发展为包含认证机制、密码管理、Web和企业网上的一次性登录（SSO）、账号管理、集成身份访问控制等非常全面的企业安全技术。身份管理包括两部分内容：身份识别和访问控制。

身份识别管理需要集中并自动实现用户账号和批准工作流的创建，从整体角度设置IT和非IT资源，并通过流程自动地降低成本。借助集成化的一次登录和个性化的门户自服务（包括密码重置），也提升了用户的生产效率。由于有了能够满足当前及未来企业需求的功能强大的身份鉴别和识别存储支持，身份识别管理可以管理企业身份识别的各个环节。从员工工作、合作伙伴签约或客户访问系统开始，它就追踪和管理并自动实现所要求的系统访问变更，并且启动所有的工作流和批准过程。

通过提供一次登录，可自动实现安全地访问基于浏览器、客户机/服务器以及传统设备的应用程序，并且可消除当今IT安全领域最大的、造成高额成本支出的安全难题——持有多个ID的密码问题。

实现网络身份的有效识别何管理需要有强大的存储库，并借助接近实时的查找功能来管理成千上万的用户。管理用户合理的访问企业当前庞杂的资源是一项复杂工作，员工、企业合作伙伴及客户通常跨不同平台和操作系统，需要安全地访问关键业务应用。管理访问意味着对被认证的用户访问的所有类型资源进行控制，确保强大的安全策略始终如一地应用到所有相关人员。

访问管理解决方案通过集中和强化端到端的安全性，确保业务关键型资源的安全，而无需受限于操作系统、平台和业务应用以及是否是Web资源。借助主动的动态安全措施，解决方案能提供最强大的保护，在防止内部破坏和外部攻击的同时，全面监控IT和物理访问设备的访问违规。

2.2 身份管理的发展

身份管理系统近些年发展很快，现在有扩大范围的趋势。身份认证技术已经逐渐由传统的多点登录向集中式单点登录方向发展，同时身份也不只局限在一个公司内部，公司之间联合身份认证已很热门。联合身份认证解决如何在公司之间实现单点认证，涉及到多个身份管理服务器互相交互，建立信任管理的问题。

身份管理的发展趋势如图2－1所示：

在解决认证和单点登录（SSO）问题方面，很多流行的新技术被采用，这其中包含Kerberos、公用密钥基础结构（PKI），结合了XML标准以及Web Service 安全规范的标准也正在被制定，这是未来发展的一个方向。

2.2.1 传统的用户登录模式

传统的认证机制是基于用户名和密码的，每一个系统都建立有自己的用户信息数据库，用以验证用户的身份。用户要访问n个系统就需要在n个系统中建立n个帐号。当其要访问一个系统中的资源时，用户首先要登录进入该系统，如果他同时要访问处于多个系统中的资源，用户就不得不按照各个系统的要求分别登录进入相应的系统。

这种情况在网络广泛应用的单位中更为明显。例如在一个大型的公司里，职员要访问技术文档、查看个人工资情况、使用邮件服务等就要分别登录到技术文档服务器、企业员工工资管理系统、邮件服务器等。用户会输入相应的帐号来登录进入这些系统。对于繁多的用户帐号，大多数用户会选择简单易一记的用户名和密码，甚至有人把用户帐号写在字条上，以防忘记；更有人为了避免重复登录系统，干脆在不使用服务的情况下也不退出系统。这样的系统既增加了用户的负担，也容易导致违反基本安全策略的事件发生，使系统更容易受到攻击，降低了系统的安全性。有资料显示，典型的网络用户一般每年在登录到网络应用程序上要花费44小时。更有甚之，70%的帮助小组电话都与密码遗忘有关，可见，传统的认证机制耗费了大量的人力物力，仍然不能很好地满足人们的对网络应用高效、安全的需要。

从技术上分析，传统的认证机制有着严重的安全问题。首先，用户名和密码信息会在网络上传送，且常常为明文传送，这就很容易被攻击者截取到，假扮合法用户来攻击系统。另外，在一般的系统中，密码一般由长度不长的字符组成，用户为了方便记忆往往会选用一些更为简便的密码形式，这很容易遭受到密码猜测的攻击，尤其是基于字典方式的攻击往往非常有效。如果强迫用户使用复杂的密码，则用户很可能将密码写在便条上，以便查阅，这样更大大增加了密码泄露的可能性，安全仍然难以得到保障。由于用户账号是不断重用的，这样为重播攻击提供了条件，攻击者只要记录下上一次用户的登录数据，以后他就可以原封不动的使用该数据来假扮合法用户通过系统的认一证，破坏系统。  

同样对网络管理员来说，这样的系统会使他们的工作量大大增加。因为每个系统都保存有自己的用户信息数据库。例如当公司新增了一名员工，管理员就要在该员工有权访问的所有系统中逐个为该员工建立账号。当该员工离开公司后，管理员又要在各个系统中将其账号删除，工作量无疑是巨大的，而且很难避免某些遗漏。因为网络管理员并不知道用户到底在多少个系统中建立了自己的账号，只能逐个检查，很容易忘记在某个系统中删除该员工账号，这样就会留下安全隐患。

分析其原因，这一切都是由于分散的用户管理造成的，各个系统间没有联系。用户在现实世界中的身份通过账号映射成为网络世界中的用户身份标识，但用户的这种身份标识是分别被每个系统分别保存的，无法互相传递。这就迫使用户在进入每一个系统时都要重新提交自己的身份标识，来通过系统的认证。其概念结构如图2-2所示：

 

总之，基于效率和安全的因素，人们必须改变传统的认证机制，设计出一个更为高效、安全的网络认证机制，来简化人们访问网络中各种资源的过程。

2.2.2 单点登录模式

单点登录，即SSO（Single Sign-On），SSO的机制就是在企业网络用户访问企业网站时作一次身份认证，随后就可以对所有被授权的网络资源进行无缝的访问，SSO 可以提高网络用户的工作效率，降低了系统出错的几率，但是比较难于实现。

单点登录系统就是用户只需要在网络中主动地进行一次身份认证过程，然后就可以访问其被授权使用的所有处在网络上的资源而不需要其主动参与其后的身份认证过程。这些服务资源可能处在不同的计算机环境中，用户以后的身份认证是系统自动完成的。在此系统中，管理员无需修改或干涉用户登录就能方便的实施希望得到的安全控制。这是一个为了能够在分布式计算机环境中，安全和方便地鉴别用户而产生的课题。

在这里，网络的资源可以是打印机或其它硬件设备，也可以是各种厂创利程序和文档数据等等，这些资源可能处于不同的计算机环境中。

单点登录系统从根本上不再使用基于用户名和密码的身份认证机制，而是采用结合了密码学技术的新的身份认证机制。新的身份认证机制可以大大提高系统的安全性，同时也可以保证用户的电子身份标识可以安全、高效地在网络之间传递。

其次，单点登录系统把原来分散的用户管理，集中起来了。各个系统之间依靠相互信赖的关系来进行用户身份的自动认证。用户的账号信息是集中保存和管理的，管理员只需要在统一的用户信息库中添加、删除用户账号，不必在多个系统中分别设置用户信息库。由此可见单点登录系统的优点有：

1.提高工作效率。用户不再需要每访问一个服务资源就进行一次身份认证过程，从而使用户有更多的时间从事有益的工作。同时这样也可以使帮助人员从为用户找回密码的繁重工作中解脱出来。

2.更好的网络安全性。系统中使用的身份认证机制使用了加密等多种方法，可以防止大部分的网络攻击。同时由于新的身份认证机制使用户的账号信息记忆量减少，使系统由于用户机密信息的泄露而导致安全事故出现的机会大大减少。

3.更有效的管理。用户的账号数据统一保存，网络管理员只需要在一个用户信息库中对用户的账号信息进行操作，减少了他的工作量和由于马虎造成的安全漏洞，提高其工作效率。

其概念结构如图2-3所示：

单点登录分为域内单点登录和跨域单点登录（Cross Domain SSO）。同一个企业可能有不同的域名，如微软有microsoft.com、msn.com、hotmail.com等不同的域名，如果需要要在多个不同的域之间实现单点登录，就会用到跨域单点登录。

2.2.3 联合身份认证

身份管理系统近些年发展很快，现在有扩大范围的趋势。身份不只局限在一个公司内部，公司之间联合身份认证解决如何在公司之间实现单点认证现已很热门。

为了促进网络身份认证项目的顺利推广，2001年9月，由HP、Cisco等十多家IT知名企业以及美国30多家著名大企业发起组成了自由联盟(www.projectliberty.org)，自由联盟旨在开发和部署开放的、客户操作的网络身份认证标准。该联盟在征求各方意见的前提下，于2002年7月推出了Liberty 1.0 版规范，这是这个成立不到一年的跨行业共同体制定的第一套开放性联合身份认证规范。

在这种联盟下，用户只用登录过任何一个联盟参与者的服务网站或终端，并许可联盟内的其他参与者可以获得自己信息，就可以按照系统返回的ID号码，在联盟企业中任意访问，而不用重新登录。这样，很多重复的工作就由联盟在后台完成了，给用户带来了真正的方便。

举一个简单的例子。美联航和花旗银行都是自由联盟的发起者。如果某个用户希望用花旗银行的信用卡购买美联航的机票，那么他只用登录过一次美联航的网站或者电话通知他的个人信息及所需机票要求，美联航就会为他出票并按照自由联盟协议，自动到花旗银行该用户信用卡上将机票费用划走。联合身份认证将成为今后网络身份认证的一种必然趋势。

联合身份认证解决如何在公司之间实现单点认证，涉及到多个身份管理服务器互相交互，建立信任关系的问题。

2.3 Sun开放网络环境概述

在网络身份认证领域，支持单点登录的产品很多，有Microsoft公司的Passport解决方案，有Sun公司的Sun ONE解决方案，有IBM公司的WebSphere解决方案。在这个校园身份管理系统中，我们选择Sun ONE，因为Sun ONE遵循而自由联盟提出的Liberty 1.0 版规范，这是一套开放性联合身份认证规范。Sun ONE 网络身份认证平台便利于提供开放和安全的授权和身份验证服务、简化访问方式以及提高生产效率。

Sun ONE的全称是Sun Open net Environment，也就是Sun开放网络环境，它是Sun整合了其门下所有软件产品后的成果。Sun ONE是Sun Microsystems的标准软件理念、体系结构、平台和专业技术，用于开发和部署定制服务。Sun ONE体系结构支持定制服务应用及服务的创建和交付。Sun ONE网络身份认证平台包含支持自由规范的 Sun ONE Identity Server、Sun ONE Directory Server以及 Solaris 9 操作环境。它还包含 Sun 公司硬件以及新合作伙伴提供的服务。

所谓的开放，就是无论运行在何种硬件平台下，都可以按照统一的标准进行整合和规划。Sun ONE品牌下面有从基础的操作系统环境到高端的门户服务、目录服务等全线产品，为传统企业信息化提供全套工具。企业原有资源、系统经过Sun ONE延伸，有了良好的集成和统一的接口。

Sun ONE强调的是开发与配置按需服务，它为企业量身搭建符合他们需求的信息系统架构，帮助他们实现内部的有效管理，实现对外与合作伙伴及用户的沟通。在这样一种结构下，企业可以降低成本，降低复杂性，提高资产回报率。 该平台支持且适用于由自由联盟计划(Liberty Alliance Project)推出的联合网络身份认证的Liberty Alliance 1.0 技术规范。以支持Liberty Alliance 1.0 技术规范为特色，Sun ONE不仅有助于商业机构和非商业机构维护其重要身份信息的保密性，同时还从经济上受益于网络联合身份认证的业务合作伙伴。

第三章 系统结构

3.1 系统环境

3.1.1前端系统

(1) 开发环境：

(a) 硬件环境：

普通PC机：奔腾2.4G Hz CPU，512M DDR内存，17寸纯平显示器、显存64M，80G硬盘

(b) 软件环境：

操作系统：    Windows 2000 Server SP4 , IE6.0SP1

 (2) 运行环境：

(a) 硬件环境：

普通PC机：CPU 主频500MHz以上、内存频率128MHz以上

(b) 软件环境：

WINDOWS系列操作系统 IE5.0以上

3.1.2后台系统

(1) 开发环境：

(a) 硬件环境：

普通PC机：奔腾2.4G Hz CPU，512M DDR内存，17寸纯平显示器、显存64M，80G硬盘

 (b) 软件环境：

操作系统：Windows 2000 Server SP4

服务器： Sun ONE Application Server 7.0，Sun ONE Directory Server 5.1，Sun ONE Identity Server 6.0

数据库：PointBase，MySql

开发语言：Java(JSP，Servlet，JavaBean)，HTML，Java Script，SQL

开发工具和编译器：Sun ONE Studio5.0，JDK1.4.2

(2) 运行环境：

(a) 硬件环境：

普通PC机：CPU 主频2G Hz 以上，内存512M以上

 (b) 软件环境：

操作系统：Windows 2000 Server系列

服务器： Sun ONE Application Server 7.0，Sun ONE Directory Server 5.01，Sun ONE Identity Server 6.0

数据库：PointBase，MySql

3.2 功能设计

3.2.1 系统拓扑结构：

系统采用当今流行的B/S结构，使用Sun ONE Application Server作为应用程序服务器，Sun ONE Identity Server作为身份管理服务器，Sun ONE Directory Server作为身份存储库。如图3－1所示：

3.2.2 功能设计：

基于Sun ONE的校园身份管理系统的功能模块如图3－2所示：

该校园身份管理系统包括3个子系统：

l         身份管理子系统：具有用户信息管理、身份认证、权限分配等功能

l         图书管理子系统：配合实现单点登录的子系统

图书管理系统中有两种用户：图书馆管理员和普通读者

图书馆管理员具有：图书管理、借书管理、还书管理、罚金管理、读者管理、基本代码维护、查询等权限

普通读者具有：读者信息查询、图书信息查询、已借图书信息查询等权限

l         校园邮件子系统：配合实现单点登录的子系统

邮件系统具有：收信、发信、管理信件等功能。每个用户有四个个人文件夹，分别是收件箱、发件箱、草稿箱、回收站，用于邮件的管理。

第四章Sun ONE Identity Server 应用分析

4.1 Sun ONE Identity Server 简介

Sun ONE Identity Server 6.0是业界第一个基于开放性标准的网络认证解决方案。它采用了Java技术，遵循Liberty联盟原则，符合SAML(安全断言标记语言)和XML(可扩展标记语言)的技术规范。Sun ONE Identity Server 6.0也是第一个商用的身份认证管理解决方案。它将身份认证管理、访问管理、委托管理、目录服务和联盟服务等都集成到一个产品中。作为Sun全方位的身份认证解决方案中的一个关键组件，Sun ONE Identity Server 6.0建立在Sun ONE目录服务器的基础之上，并利用了Sun ONE Meta Directory的整合能力。

这一Sun ONE身份认证服务器通过降低应用开发、安全管理和桌面员工安置的费用，大大减少了企业的IT成本。

Sun ONE Identity Server 6.0的一个关键性能是，可以能通过SAML或Liberty的技术规范，完成内、外部对机构防火墙的联合认证。现在，越来越多的客户选择Sun为其提供具有高缩放性和可用性的解决方案。这既保护了他们原有的投资，又为他们开辟了新的业务途径。

作为Sun开放网络(Sun ONE)环境中必不可少的组成部分，Sun ONE身份认证服务器（旧称iPlanet目录服务器访问管理版）包括身份管理解决方案所具有的核心组件：

l         在多个Web和应用服务器之间实现安全访问控制。

l         具有委托功能的集中管理特性。

l         用于存储身份的高性能、高可用性以及高可扩展性存储库。

身份认证服务器软件有助于解决现今商业挑战，同时为执行下一代战略做好充分准备。

4.2 Sun ONE Identity Server 的基本组件

Sun ONE身份认证服务器包含三个关键性身份管理组件：策略服务、管理服务和身份存储库。

l         策略服务：集中实施访问，并针对基于Web的资源提供单点登录功能。

l         管理服务：可扩展、集中地进行身份、策略和服务管理（可以委托）。

l         身份存储库：使用Sun ONE Directory Server5.1 ，作为存储身份认证策略和服务信息的存储库。各种机构都可以重复利用现有身份，而不是针对每项新服务重新输入数据和进行过多的管理工作。

(1)     策略服务

Sun ONE身份认证服务器取用一种公用身份验证和授权基础结构取代在单独的Web服务器和应用服务器上进行临时的和针对应用的身份验证和授权方法。

管理员可以通过每个用户一个帐户的原则针对多项服务集中执行访问控制。可以给每个用户分配一个或多个角色，这有助于简化针对大规模但成份不同的群体的管理。单点登录授权服务使用户能够访问多个服务器上的所有其有权访问的Web资源（即使是在不同DNS域中），而无需进行多次身份验证。

Web单点登录(SSO):用户一旦通过某项服务的身份验证，就可以使用其他已授权的Web服务，而无需针对每项服务重新进行身份验证。SSO是通过一个发送到用户的Web浏览器的令牌来实现的。此令牌可以是标准的浏览器Cookie或ULR重写功能。

身份验证：各种机构可以选择各种身份验证方法，从简单的用户名和密码、像RADIUS或Safeword令牌卡这样的企业方法，到PKI证书。可以把身份验证方法链接在一起来增强安全性。支持的身份验证方法包括：

l         LDAP用户ID/密码

l         x.509v3数字证书

l         RADIUS

l         SafeWord令牌卡

l         UNIX身份验证服务

l         匿名

公用的服务提供商接口(SPI)可以用来增加其他身份验证方法。

授权和角色：管理员通过应用到在Sun ONE目录服务中建立的角色的策略控制身份验证和授权。策略定义基于URL的资源（网页、应用或服务）的访问。角色与策略相关连，用来指出该角色可以提供何种服务，以及该角色控制哪一组用户的访问权限。

(2)     管理服务

Sun ONE身份认证服务器包括基于Web浏览器的可扩展的用户身份、策略和服务管理。可以针对多个Web服务器和应用服务器集中管理，但也可以将管理委托给其他管理员（如本地组管理员和外部合作伙伴），甚至可以委托给最终用户。委托功能允许顶级管理员把管理工作量和成本直接分配给各个业务单位、部门和最终用户。

委托模式具有极高的可配置性，因而允许基于用户组以及基于允许管理的用户的特征进行委托。例如，部门管理员可以具有管理该部门内几乎任何方面的权限，而电子邮件管理员则可以获得仅管理与电子邮件用户的电子邮件相关的设置的权限。

另外，还支持自我管理功能，该功能允许最终用户管理其配置文件，例如，更改密码或更新其家庭地址。此功能有助于节约管理成本。

(3)     身份存储库

Sun ONE身份认证服务器包含有Sun ONE Directory Server，作为身份存储库，提供一个存储用户信息以及角色、访问控制和客户应用程序配置数据的公用存储区。它还具有把数据项组织成为树型结构以及从逻辑上把数据项组织成为动态组。

       Sun ONE Directory Server的特点包括：

l         针对每个系统支持数百万个项目的多数据库体系结构。

l         双向多主复制，实现高可用性，从而消除单一故障点。

l         联机备份、配置更改和架构更新，实现对关键任务服务进行24x7支持。

4.3 Sun ONE Identity Server API 分析

Sun ONE Identity Server的提供了一系列Package，用于实现身份管理，这些Package包括：

com.iplanet.am.sdk,

com.iplanet.am.util,

com.iplanet.log,

com.iplanet.services.cdm,

com.iplanet.sso,

com.sun.identity.authentication,

com.sun.identity.authentication.spi,

com.sun.identity.log,

com.sun.identity.log.spi,

com.sun.identity.policy,

com.sun.identity.policy.client,

com.sun.identity.policy.interfaces,

com.sun.identity.saml,

com.sun.identity.saml.assertion,

om.sun.identity.saml.common,

com.sun.identity.saml.plugins,

com.sun.identity.saml.protocol,

com.sun.identity.saml.xmlsig,

com.sun.identity.sm, com.sun.liberty

其中用于单点登录的最主要的Package是com.iplanet.sso，下面我来详细介绍一下这个Package中的主要类和方法：

Package com.iplanet.sso

Interface Summary
SSOToken	The SSOToken class represents a "single sign on"(SSO) token.
SSOTokenEvent	The SSOTokenEvent class represents an SSO token event.
SSOTokenID	The SSOTokenID class is used to identify an SSOToken object.
SSOTokenListener	The SSOTokenListener interface needs to be implemented by the applications to receive SSO token events.
Class Summary
SSOTokenManager	The class SSOTokenManager is a final class that provides interfaces to create, get, and validate SSOTokens.
Exception Summary
SSOException	An SSOException is thrown when there are errors related to SSOToken operations.

 

SSOToken类代表一个单点登录的令牌（Token）。它包含 SSO 令牌相关的数据，例如认证方法，认证水平，发送请求的客户端（浏览器）的主机名，也包含Session相关的信息，例如最大的Session时间，最大的Session空闲时间和当前Session空闲时间。

SSOTokenEvent 类代表一个 SSO 的令牌事件，即SSO令牌的改变。下列各项是可能的 SSO令牌事件类型： SSO_TOKEN_IDLE_TIMEOUT（超过最大Session空闲时间），SSO_TOKEN_MAX_TIMEOUT（ 超过最大Session时间）以及 SSO_TOKEN_DESTROY（令牌被销毁）。

SSOTokenID 类用来识别一个 SSO令牌对象。它包含一个随机的字符串和服务器的名字。SSOTokenID中的随机的字符串在一个给定的服务器上是唯一的。

SSOTokenListener：当一个SSO令牌事件到达时，SSOTokenListener对象开始生效。这时, SSOTokenListener 对象中的ssoTokenChanged()方法就会被应用程序所调用。

SSOTokenManager类是一个Final类，不能够被继承，它提供接口创建，获取，并且验证SSO的令牌是否有效。它是一个Singleton类,我们可以调用 SSOTokenManager.getInstance() 方法来获得这个类的实例。

SSOException：当有关SSOToken的错误发生时，会抛出SSOException异常。

4.4 Sun ONE Identity Server特点以及扩展

l         一致的安全性——整合的身份验证服务使各种应用能够使用所有受支持的身份验证方法，而不是针对每个身份验证方法的各种应用逐个添加支持。Sun ONE身份认证服务器取代了针对实施Web资源访问的临时性和一次性访问控制。与单独推出的Sun ONE Web代理服务器（旧称iPlanet Web代理服务器）一起使用，Sun ONE身份认证服务器可以为几乎所有Web通信提供统一的保护——而不考虑是何种平台或应用程序。

l         强大的安全性——通过提供单点进行所有身份验证尝试，可以检测到并阻止强力(brute-force)攻击，从而可以提高整体安全性。利用Sun ONE身份认证服务器，可以根据各个帐户失败的身份验证尝试总数来实施帐户封锁，而不管进行每次尝试所用的身份验证方法（用户ID/密码、硬件卡等）是什么。此功能可防止攻击者根据每种身份验证方法进行无限次数的尝试。所有日志文件数据（如身份验证、授权和管理事件）都可以整合到一个符合JDBC技术的数据库。报告和监视产品——从通信分析到侵入窃密检测——都可以从第三方供应商获得。

l         通过单点登录提高了工作效率—— Web单点登录方法允许用户仅需登录一次即可访问其经过授权的多种应用，从而提高了用户的工作效率。这有助于通过减少向咨询台请求重设密码的呼叫来降低管理成本。

l         降低管理成本——大型用户群体和许多应用会使管理面临严峻挑战。Sun ONE身份认证服务器的策略驱动型管理方式是对企业级权限进行集中式管理，与对每个用户实施管理的方式不同的是Sun ONE身份认证服务器只向用户分配一个角色或多个角色，并通过与角色相关的策略来管理对应用的访问。另外，Sun ONE身份认证服务器为管理员提供了向其他管理员（甚至最终用户）委托管理权限的能力。这使管理大规模雇员、客户和合作伙伴群体更为容易。

l         公用身份认证平台——通过一个公用的并可复用的身份管理层，各个公司可以把时间花费在构建满足其核心业务要求的应用，而不是开发访问实施和管理工具。一旦企业建立一个公用身份管理基础结构，新的应用和服务就可以通过API和开放标准重复使用同样的信息。

 

Sun ONE身份认证服务器提供了有助于企业解决现今身份认证问题的基础，并为未来提供新的服务创造了条件。

第五章SSO在校园身份管理系统中的实现

5.1 单点登录（SSO）的实现

5.1.1 实现原理

在Sun ONE Identity Server 6.0里，支持两种不同方式的SSO，一种是针对Web方式的应用，另一种是非Web方式的应用。对于Web的应用，实现方式有两种：

l         一个是基于Proxy Agent，Sun为很多主流的Web Server和Application Server都提供了相应版本的Proxy Agent，把Proxy Agent装在Web Server或Application Server上面，让Proxy Agent截获客户端发送过来的对资源的请求，然后强制对该请求进行访问控制，通过认证的客户端会由Identity Server 上的Session Server发一个SSO 的Token（令牌），在Token里会包含有Session的信息，以及客户的一些信息。SSO Token是通过Web浏览器的Cookies或URL的Rewriting来存储SSO的Token的；

l         另一种则是用Sun ONE Identity Server 所提供的SSO的API函数去手工写一些程序来实现Proxy Agent的功能，从而获得SSO的Token。

 

对于非Web方式的应用来说，只能用Sun ONE Identity Server 所提供的SSO的API函数去手工写一些程序来获得SSO的Token。

 

5.1.2 基于Web的 SSO 流程

 

图5－1基于web的SSO流程示意图

基于Web的SSO的工作流程如图5－1所示：User是Web浏览器或支持Http协议的客户端，User发送请求到它所要访问的应用程序或资源，当它访问Mail服务器时，Mail服务器上所部署的Proxy Agent（或验证程序）会把请求截获，检查这个Request是否包含SSO的Token（令牌）。第一次访问时当然没有这个Token，对于这个Request，Proxy Agent（或验证程序）会把它重定向到Sun ONE Identity Server 上，Identity Server接到这个请求，就会把管理员预先配置好的一些需要用户进行认证的页面发送到浏览器，客户在经过认证之后，Identity Server会建立一个SSO的Token，把Token返回给浏览器。客户端浏览器 再次用SSO的Token去访问它原来所要访问的应用程序，当Proxy Agent（或验证程序）再次接受到请求会发现请求中包含SSO的Token，它会用Token上存储的用户信息去Identity Server上把这个用户相应的Policy（策略）的设置取出来进行对比，看这个用户是否有访问该资源的权限，如果有就允许访问，如果没有则拒绝访问。

经过了这样一次认证之后，客户端再访问同一个Identity Server 所控制的域（Domain）里面的其他应用的时候就不用再进行第二次的认证了。比如说它再去访问Library Application（图书管理系统）时，图书管理系统上的Proxy Agent（或验证程序）就会发现这个请求时带有SSO的Token的，它就会用Token里的Session信息取得相应的策略数据，然后同样进行一次策略的比较，看这个用户是否有权限访问资源，从而避免了再次认证。

5.2 跨域单点登录（CDSSO）的实现

同一个企业可能有不同的域名，如微软有microsoft.com、msn.com、hotmail.com等不同的域名，如果要在多个不同的域之间实现单点登录，就会用到跨域单点登录（Cross Domain SSO）。用户对每个不同域名得到一个Cookie，在Cookie里有SSO的Token，Identity Server通过在自己上面加装一个跨域SSO控制器（Cross Domain SSO Controller）来完成的，这个控制器会和安装在每个域的Web Server上面的Cross Domain SSO的Servlet进行通讯来合作完成，给用户发放针对于每个域的Cookie，从而实现跨域单点登录的任务。

SUN的SSO解决方案是基于Cookie的，所以它也很容易的实现了跨域的SSO。在配置了跨域SSO的情况下，某个用户在一个域中经过Identity验证后，能够访问被同一个Identity服务器保护的另一个域的网络资源。比如说，一个Identity服务器位于Domain 1并且作为验证服务提供者，用户在Domain 1中被Identity验证，因此Token是在Domain 1中设置的。另有一Server B位于Domain 2并且受Agent保护，而保护Server B的是位于Domain 2的另一个Identity服务器，Domain 2中的Identity服务器以Domain 1中的Identity服务器作为验证服务器。

假如User A经过位于Domain 1中的Identity服务器进行验证以后，他接着访问Domain 2中的Server B，位于Domain 2中的Agent会检查该请求是否拥有一个SSO Token，结果是没有属于Domain 2的令牌。在配置了跨域SSO的情况下，Agent会将用户请求重定向到位于Domain 2中的Identity Server的跨域SSO Servlet，接着该组件会将用户的请求重定向到位于Domain 1中的Identity Server服务器中的跨域处理组件，也就是跨域SSO控制器，因为位于Domain 1中的Identity Server是验证服务器。Domain 1中的Identity Server接收到属于Domain 1的Cookie，负责处理SSO的服务向 Domain 2中的Identity Server发送一个SSO Token，Domain 2的验证服务验证来自Domain 1的SSO Token并且为用户创建一个属于Domain 2的SSO Token，最后为用户设置属于Domain 2的Cookie。在该用户具有访问Server B权限的条件下，用户可以访问他所请求的URL。

以图形化方式表示的跨域SSO流程如图5－2所示。

 

图5－2跨域SSO实现示意图

目前，由于时间关系以及试验条件的限制，我们对于跨域单点登录的解决方案还停留在理论分析阶段，没有具体实现。这一部分将是我们系统的改进的重点。

5.3 Web服务的部署

目前，本系统实现了域内单点登录的功能，服务具体部署如下。

我们共在三台电脑上部署Web服务，称为服务器A、B、C，都安装了Windows 2000 Server 操作系统并升级为Sp4。服务器A升级为域服务器，并安装Win2000 Server的DNS服务，服务器A、B、C均把服务器A做为首选DNS服务器。服务器B装有Sun ONE Identity Server、Sun ONE Directory Server、Sun ONE Application Server提供身份管理、权限分配、访问限制等功能。服务器C装有Sun ONE Application Server和MySQL数据库服务器，提供Web电子邮件服务。服务器A还装有Sun ONE Application Server和Point Base数据库服务器，提供Web图书管理服务。服务器A、B、C的域名分别为library.bishe.com，nk-zja.bishe.com，mail.bishe.com。

5.4校园身份管理系统中单点登录的具体实现

5.4.1 Sun ONE Identity Server的配置

首先在IE浏览器输入：http://nk-zja.bishe.com:58080/amconsole进入Identity Server的登录界面，使用管理员帐号amadmin登录，进入管理页面。在视图下拉列表中选择用户，可以添加和删除用户，这里我们添加了四个测试用户，use1，use2，user3和user4。如图5－3所示：

在视图的下拉列表中选择角色，进入角色管理页面，我们在这里添加了三个角色，System Email User，System Library Admin和System Library User，如图     5－4所示。其中System Email User具有访问邮箱系统的权限，System Library Admin具有图书馆管理员的权限，System Library User具有图书馆普通读者的权限。

 

然后，我们将用户添加到这三个角色，即给用户分配权限。将user1，user2和user4三个用户添加到System Email User这一角色；将用户user1添加到System Library Admin这一角色；将user2和user3两个用户添加到System Library User 这一角色。如图5－5，图5－6和图5－7所示。

从而使user1具有了System Email User，System Library Admin的权限，user2具有了System Email User，System Library User的权限，user3具有了System Library User的权限，user4具有了System Email User的权限。

图5－5设置用户权限




图5－6设置用户权限

图5－7设置用户权限

 

System Email User，System Library Admin和System Library User这三个角色的权限分配和资源访问需要在具体程序中进行控制。

5.4.2 编码实现

l         代码1：验证用户登录程序的核心代码：

// 从登录页面获取用户信息 String UserName = request.getParameter("username"); String Password = request.getParameter("password"); String gotoURL = request.getParameter("goto"); boolean userok = false; String orgName = "dc=bishe,dc=com"; String indexName = ""; AuthContext.IndexType indexType; // 验证用户信息 if (UserName != null && UserName.length() > 0) {        // verify against table        AuthContext lc = null;        try        {           lc = new AuthContext(orgName);          indexType = AuthContext.IndexType.MODULE_INSTANCE;          indexName = "LDAP";          System.out.println("LDAPLogin: Obtained login context");          lc.login(indexType, indexName);      }      catch (LoginException le)        {               …….      }      Callback[] callbacks = null;        // get information requested from module        while (lc.hasMoreRequirements())        {               callbacks = lc.getRequirements();          if (callbacks != null)               {                      int i = 0;               for (i = 0; i < callbacks.length; i++)                      {                           ........... // 完成回掉过程                      }                      lc.submitRequirements(callbacks);               }        }//end while        if (lc.getStatus() == AuthContext.Status.SUCCESS)        {               // 登录成功               userok = true;        }        else if (lc.getStatus() == AuthContext.Status.FAILED)        {               //登录失败      }        else        {               //未知情况        }        if (userok)  //如果登录成功，则创建Token，将用户信息写入Cookie        {               String tokenid = lc.getSSOToken().getTokenID().toString();               String cName = (new com.iplanet.am.util.SystemProperties()).get("com.iplanet.am.Cookie.name");               Cookie newCookie = new Cookie(cName,tokenid);               newCookie.setDomain("bishe.com");          newCookie.setPath("/");               response.addCookie(newCookie);               if(gotoURL ==null)                      gotoURL = request.getContextPath();               response.sendRedirect(gotoURL);               return;        } } response.sendRedirect("SSOFailure.jsp"); //如果登录失败，则跳转到错误页面

 

此段程序用于验证用户的身份。首先，从登录页面的提交中获取用户名和密码的信息，然后与身份存储库（Sun ONE 目录服务器）中存储的用户信息进行比较，如果身份存储库中包含该用户的信息，并且用户名、密码正确，则登录成功，否则登录失败。如果登录成功则授予该用户一个令牌（Token），并将用户的信息写入Cookie，然后转到资源列表页面。相反，如果失败则抛出异常或定位到错误页面

l         代码2：验证Token是否有效的核心代码：

boolean loggedIn = false;      SSOTokenManager manager;      SSOToken ssoToken; //    String roleDN = "cn=System Library User,dc=bishe,dc=com"; //    String roleDN = "cn=System Library Admin,dc=bishe,dc=com";      String roleDN = "cn=System Email User,dc=bishe,dc=com";      // 该函数用于验证用户的角色      AMUser validate(SSOToken Token ,String systemRole) throws Exception      {         Set roleSet=null;         AMStoreConnection amsc = new AMStoreConnection(Token);         AMUser user=amsc.getUser(Token.getPrincipal().getName());         if(systemRole == null)             return user;         roleSet = user.getRoleDNs();         Iterator it = roleSet.iterator();         String role;         while(it.hasNext())         {             role = (String)it.next();             if(role.equals(systemRole))             return user;         }         throw new Exception("no role");     }     //检查用户的令牌是否有效 try {         manager = SSOTokenManager.getInstance();         ssoToken = manager.createSSOToken(request);         if(ssoToken != null && manager.isValidToken(ssoToken))         {               SSOToken oldToken = (SSOToken)session.getAttribute("SSOToken");             if(oldToken!=null&& oldToken.getTokenID().toString().equals(ssoToken.getTokenID().toString()))             {                 loggedIn = true;                 break;             }             System.out.println("validate a new token and get user inform");             AMUser user = validate(ssoToken,roleDN);                            String uid =(String)user.getAttribute("uid").iterator().next();             // 向Session中写入信息             session.invalidate();             session = request.getSession(true);             session.setAttribute("uid",uid);             session.setAttribute("SSOToken",ssoToken);                         loggedIn = true;         }         catch (Exception e)         {             ……         }     if(!loggedIn) {         response.sendRedirect("SSOFailure.jsp");         return;     }

 

此段程序嵌在具有访问限制的Web页面的头部，用于检查用户的令牌（Token）和用户的身份。如果令牌有效，并且该用户具有访问这个页面的权限，则显示该Web页面的信息，同时将用户的信息写入Session中，供以后的Web程序取用。如果令牌失效，或该用户没有访问这个页面的权限，则定向到错误页面，让用户用具有访问权限的帐号重新登录。

代码3：用户注销程序的核心代码：

try     {         SSOTokenManager manager = SSOTokenManager.getInstance();         SSOToken ssoToken = manager.createSSOToken(request);     if(ssoToken != null && manager.isValidToken(ssoToken))     {         //丢弃令牌             manager.destroyToken(ssoToken);             //删除Cookie             String cName = (new com.iplanet.am.util.SystemProperties()).get("com.iplanet.am.cookie.name");             Cookie deletecookie = new Cookie(cName,null);             deletecookie.setDomain("bishe.com");             deletecookie.setPath("/");             deletecookie.setMaxAge(0);             response.addCookie(deletecookie);             //清除Session信息             session.invalidate();             if(gotoURL ==null)             gotoURL = request.getContextPath();             response.sendRedirect(gotoURL);         } } catch (com.iplanet.sso.SSOException e)     {         response.sendRedirect("SSOFailure.jsp");     }

 

此段程序用于注销用户，防止用户有忘记关闭浏览器而被其他用户使用其资源。注销程序包括三个步骤，使令牌失效，删除Cookie信息，清除Session信息，从而保证了系统的安全性。

第六章 总结与展望

6.1 总结

我们只是在实验室环境下实现了一个十分简单的单点登录系统。仅仅是对单点登录系统的设计与实现做了一些有益的探索，主要在于尝试了用户电子身份标识的自动安全传递和多个系统之间的信任关系建立，并利用它们来实现单点登录。现在出现的技术趋势是在网络上建立一个统一的、标准的安全认证机制，这样在不远的将来便可以实现全网络的单点登录，当然这还需要人们不断地进行研究和扩充。

6.2 系统的不足与展望

目前，本单点登录系统的设计方案，适用范围基本上局限于一个企业网或校园网，还不能扩展到跨域的网络环境。由于条件限制，我们主要基于一台认证服务器来进行认证工作，如果是有多台认证服务器，我们可以进一步研究如何使它们之间可以建立信任关系，使之由一个认证服务器所管理的客户可以访问在另一个认证服务器管理域中的资源。要达到完善的网络身份认证需要涉及联合身份认证及各种服务资源的定位，从现在的发展趋势来看，认证技术与目录技术相结合，是实现全网络的联合认证与资源访问的一个有效手段。

另外，由于条件和时间的限制，我们并没能完全发挥出Sun ONE Identity Server身份管理与安全性方面的作用。在本系统的实现中，我们主要应用了其身份管理的功能，实现了其中最为基本的部分。Sun ONE是一个很庞大的体系，有许多强大的功能与扩展等待我们去学习和探索。