本科毕业设计WEB单点登录系统的研究与设计Word文件下载.docx
《本科毕业设计WEB单点登录系统的研究与设计Word文件下载.docx》由会员分享,可在线阅读,更多相关《本科毕业设计WEB单点登录系统的研究与设计Word文件下载.docx(41页珍藏版)》请在冰点文库上搜索。
当这些安全风险逐步反映出来,管理员增加一些新的安全措施的时候,这些措施却在减少系统的可用性,并且会增大系统管理的复杂度。
另一方面,较大的企业内部,一般都有很多的业务支持系统为其提供相应的管理和IT服务。
例如财务系统为财务人员提供财务的管理、计算和报表服务;
人事系统为人事部门提供全公司人员的维护服务;
各种业务系统为公司内部不同的业务提供不同的服务等等。
这些系统的目的都是让计算机来进行复杂繁琐的计算工作,来替代人力的手工劳动,提高工作效率和质量。
这些不同的系统往往是在不同的时期建设起来的,运行在不同的平台上;
也许是由不同厂商开发,使用了各种不同的技术和标准。
每一个应用系统在运行了数年以后,都会成为不可替换的企业IT架构的一部分。
随着企业的发展,业务系统的数量在不断的增加,老的系统却不能轻易的替换,这会带来很多的开销。
其一是管理上的开销,需要维护的系统越来越多。
很多系统的数据是相互冗余和重复的,数据的不一致性会给管理工作带来很大的压力。
业务和业务之间的相关性也越来越大,例如公司的计费系统和财务系统,财务系统和人事系统之间都不可避免的有着密切的关系。
为了降低管理的消耗,最大限度的重用已有投资的系统,很多企业都在进行着企业应用集成(EAI)。
企业应用集成可以在不同层面上进行:
例如在数据存储层面上的“数据大集中”,在传输层面上的“通用数据交换平台”,在应用层面上的“业务流程整合”,和用户界面上的“通用企业门户”等等。
事实上,还用一个层面上的集成变得越来越重要,那就是“身份认证”的整合,也就是“单点登录”。
另外,使用“单点登录”还是SOA时代的需求之一。
在面向服务的架构中,服务和服务之间,程序和程序之间的通讯大量存在,服务之间的安全认证是SOA应用的难点之一,应此建立“单点登录”的系统体系能够大大简化SOA的安全问题,提高服务之间的合作效率。
因此,在市场上提出了这样的需求:
网络用户可以基于最初访问网络时的一次身份验证,对所有被授权的网络资源进行无缝的访问。
从而提高网络用户的工作效率,降低网络操作的费用,并提高网络的安全性。
正是基于这种市场需求,本文力图通过对web单点登录系统的研究,了解相关系统架构和技术,并尝试开发出一套解决类似市场需求的web单点登录系统。
1.2国内外研究概述
在国内,较早使用SSO系统主要是一些大型企业,比如中国移动。
随着网络的普及与发展,企业内应用系统的增加,越来越多的企业开始使用SSO来整合企业的应用系统。
而国内提供解决方案的企业也蓬勃发展,出现了较多的SSO产品。
在国外,对于SSO的研究较国内要早的多而且深入的多。
成熟的大型商业系统或技术规范已经非常多了:
微软的.NETPassport(已整合到WindowsLiveID)[1]、SunMicrosystems等建立的自由联盟计划(LibertyIdentityWebServicesFramework)[2]、Microsoft和IBM联合开发的Web服务联邦语言(WS.Federation)以及结构化信息标准促进组织(OASIS)的安全服务委员会(SSTC)提出的安全断言标记语言(SecurityAssertionMarkupLanguage,SAML)[3]。
.NETPassport技术是通过其Passport来实现单点登录的,只要用户通过微软的Passport服务器的验证,就可以访问所有与Passport服务器合作的站点。
但由于微软在Passport验证技术方面不公开,使得在安全性方面有一定的隐患。
自由联盟计划和Web服务联邦语言都是通过建立联盟身份,来访问联盟中的其它系统的。
但由于Web服务是松耦合的,所以建立联盟身份并不是每个Web服务场景所必须的。
SAML主要用来在不同信任域之间交换安全信息,为认证和授权服务提供了标准的描述,基于XML具有跨平台性,提供了强大的断言(Assertion)机制,使得跨域的系统可以通过断言来进行验证,适用于Web服务的松耦合环境。
目前对基于SAML的Web服务单点登录模型学术界和工业界都有了一定的研究。
SAML规范中的Bindings部分定义了SAML如何与SOAP协议进行绑定,为SAML与Web服务的结合提供了标准。
除了大型的商业系统,国外还有很多成熟的开源SSO系统。
比如SourceID.NET,OpenSSO,CAS。
1.3本文研究内容及组织结构
本文的研究内容主要是基于现有web单点登录系统和技术,分析研究各种系统的结构和技术,并尝试开发出一套实现基本功能的web单点登录系统。
主要内容如下:
1.介绍单点登录系统的相关技术及规范,并分别从技术,可实施性等方面进行比较。
2.结合上一点的分析,概括出一种web单点登录系统的简易模型结构。
3.在第2点的基础上,模拟一种需求环境,开发出一套web单点登录系统。
组织结构如图1-1所示:
第二章单点登录系统相关技术与规范
2.1单点登录系统概念
SingleSign-On(SSO),中文名称为单点登录。
指在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。
它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。
用一种生活中的例子来对比介绍。
西安是一个旅游胜地,有很多著名的景点。
通常人们在进入景点之前都需要购买该景点的门票,才能进入欣赏风景。
当你游览各个景点时就显得很不方便,每个景点都需要重新购买单独的门票,既费时又费力。
于是西安旅游局发行了一种旅游年票,只需购买该年票,就可以随时进入西安市多个景点,并不需要在各个景点单独购票。
单点登录机制与上述情况类似。
当用户第一次访问应用系统1的时候,因为还没有登录,会被引导到认证系统中进行登录
(1);
根据用户提供的登录信息,认证系统进行身份效验,如果通过效验,应该返回给用户一个认证的凭据--ticket
(2);
用户再访问别的应用的时候(3,5)就会将这个ticket带上,作为自己认证的凭据,应用系统接受到请求之后会把ticket送到认证系统进行效验,检查ticket的合法性(4,6)。
如果通过效验,用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
如图2-1所示:
从上面的视图可以看出,要实现SSO,需要以下主要的功能:
1.所有应用系统共享一个身份认证系统。
统一的认证系统是SSO的前提之一。
认证系统的主要功能是将用户的登录信息和用户信息库相比较,对用户进行登录认证;
认证成功后,认证系统应该生成统一的认证标志(ticket),返还给用户。
另外,认证系统还应该对ticket进行效验,判断其有效性。
2.所有应用系统能够识别和提取ticket信息
要实现SSO的功能,让用户只登录一次,就必须让应用系统能够识别已经登录过的用户。
应用系统应该能对ticket进行识别和提取,通过与认证系统的通讯,能自动判断当前用户是否登录过,从而完成单点登录的功能。
上述是对单点登录系统的概述,对于本文所研究的web单点登录系统而言,众所周知,Web协议(也就是HTTP)是一个无状态的协议。
一个Web应用由很多个Web页面组成,每个页面都有唯一的URL来定义。
用户在浏览器的地址栏输入页面的URL,浏览器就会向WebServer去发送请求。
浏览器向Web服务器发送了两个请求,申请了两个页面。
这两个页面的请求是分别使用了两个单独的HTTP连接。
所谓无状态的协议也就是表现在这里,浏览器和Web服务器会在第一个请求完成以后关闭连接通道,在第二个请求的时候重新建立连接。
Web服务器并不区分哪个请求来自哪个客户端,对所有的请求都一视同仁,都是单独的连接。
这样的方式大大区别于传统的(Client/Server)C/S结构,在那样的应用中,客户端和服务器端会建立一个长时间的专用的连接通道。
正是因为有了无状态的特性,每个连接资源能够很快被其他客户端所重用,一台Web服务器才能够同时服务于成千上万的客户端。
但是我们通常的应用是有状态的。
先不用提不同应用之间的SSO,在同一个应用中也需要保存用户的登录身份信息。
例如用户在访问页面1的时候进行了登录,但是刚才也提到,客户端的每个请求都是单独的连接,当客户再次访问页面2的时候,如何才能告诉Web服务器,客户刚才已经登录过了呢?
浏览器和服务器之间有约定:
通过使用cookie技术来维护应用的状态。
Cookie是可以被Web服务器设置的字符串,并且可以保存在浏览器中。
当浏览器访问了页面1时,web服务器设置了一个cookie,并将这个cookie和页面1一起返回给浏览器,浏览器接到cookie之后,就会保存起来,在它访问页面2的时候会把这个cookie也带上,Web服务器接到请求时也能读出cookie的值,根据cookie值的内容就可以判断和恢复一些用户的信息状态。
Web-SSO完全可以利用Cookie结束来完成用户登录信息的保存,将浏览器中的Cookie和上文中的Ticket结合起来,完成SSO的功能。
2.2通用的标准解决方案
2.2.1通用安全服务应用程序接口(GSS-API)
"
GenericSecurityServiceApplicationProgramInterface"
简写GSS-API[4],译为通用安全服务应用程序接口,一个典型的GSS-API调用者是通讯协议本身,调用GSS-API,用可信性、完整性和机密性的安全服务来保护他的通讯。
例如Kerberos。
这就是GSS-API可以在不同的安全服务和应用程序被使用的原因,包括SSO。
GSS-API的目的是提供隐蔽特定的内在安全机制的一个接口。
这可以帮助不同应用程序之间有更好的互操作性。
一个典型的GSS-API调用者是通讯协议本身,调用GSS-API,用可信性、完整性和机密性的安全服务来保护他的通讯。
调用者接受一个本地GSS-API实现提供的一个令牌,并且把令牌传送给远程系统的对应方;
对方接收令牌并把其传送给他的GSS-API本地实现处理。
通过GSS-API这种方式实现的可用的安全服务在基于公钥和私钥的底层加密技术的多种机制上可实现的。
关于认证和密钥分配系统的一个经常遇到的问题是,由于它要求对应用系统本身做出改动,所以经常受到的冷遇。
考虑到这一点,对一个认证和密钥分配系统来说,提供一个标准化的安全API就显得格外重要。
能做到这一点,开发人员就不必再为增加很少的安全功能而对整个应用程序动大手术了。
因此,认证系统设计领域内最主要的进展之一就是制定了标准化的安全API,即通用安全服务API(GSS-API)。
德州Austin大学的研究者们开发的安全网络编程(SNP),对GSS-API接口进行了进一步的封装,使同网络安全性有关的编程更加方便。
GSS-API的设计假定和强调以下几个基本目标:
1.机制独立:
GSS-API定义了一个接口来使用密码技术实现强壮的认证和其他安全服务--在独立于特定的底层机制的通用层上。
例如,GSS-API提供的服务可以用密钥技术实现(例如,Kerberos)或者使用公钥技术实现(例如X.509)。
2.协议环境独立:
GSS-API独立于使用它的通讯协议组,允许在多种协议环境中使用。
在进行调用的协议和GSS-API的应用中间,加入一个面向特定的通讯协议(如RPC)的中介,可以保持GSS-API功能的起用和协议通讯的起用之间的同步。
3.协议联合的独立:
GSS-API安全上下文构造是独立于通讯协议相关的构造的。
这个特点允许单独的GSS-API实现可以被多种协议模块使用,以利于调用这些模块的应用程序。
同时GSS-API服务也可以被应用程序直接调用,完全独立于协议关联。
4.适应多种实现:
GSS-API客户不是被限制存在于实现GSS-API的系统定义的TCB(TrustedComputingBase)范围内;
安全服务被以一种既适应intra-TCB调用,又适用extra-TCB调用的方式说明。
2.2.2开放软件基金会(OSF)-分布式计算环境(DCE)
开放软件基金会(OSF)的分布式计算环境[5]。
DCE是一个被广泛接受的解决方案,用于开发和部署安全的、企业级的分布式计算应用,提供网络安全、透明的服务分配和跨平台通信的能力,允许在一个异构的环境中快速设计基于"
主/从"
或"
对等"
结构的应用。
它能方便地对网络提供最佳的性能和可靠的保护。
因为DCE是由主流操作系统厂商的行业协会所支持的,所以这个标准在很多计算平台上都得到了广泛的支持。
DCE核心功能现在已经被几乎所有的UNIX系统及其变种所支持,并且,在PC操作系统日益普及的今天,DCE核心服务也在PC机上变得越来越普遍。
DCE的认证管理服务是集成了基于DES私人密钥加密技术和MIT开发的Kerberos技术的身份验证。
这是一种企业级的安全解决方案,它使企业能为网络资源的使用提供安全。
保管理护和通过企业Intranet的用户和通过Internet的远程用户都可以有控制地访问这些资源。
DCE对于安全涉及到4个方面:
1.认证(authentication),
2.安全通讯(securecommunications),
3.授权(authorization),
4.和审计(auditing)。
2.2.3嵌入式认证模块(PAM)
PAM(PluggableAuthenticationModules)[6]是由Sun提出的一种用于实现应用程序的认证机制。
其核心是一套共享库,目的是提供一个框架和一套编程接口,将认证工作由程序员交给管理员,PAM允许管理员在多种认证方法之间作出选择,它能够改变本地认证方法而不需要重新编译与认证相关的应用程序,同时也便于向系统中添加新的认证手段。
PAM最初是集成在Solaris中,目前已移植到其它系统中,如Linux、SunOS、HP-UX9.0等,并在Linux中得到广泛的应用。
PAM的设计目标是:
1.管理员可以选择认证方式,从简单的密码到智能卡系统。
2.可以为不同的程序配置不同的认证机制。
如使telnet使用S/Key认证。
而本机的login缺省使用一般的UNIXpassword。
3.支持程序的显示方式的需求。
如login需要基于终端的显示,而dtlogin需要X显示,而`ftp'
和`telnet'
需要透过网络来认证。
4.支持为一个程序配置同时使用多种认证机制。
5.可是用户在使用多种认证机制时,不必为同一个密码敲入多次。
6.可是用户在认真时需要输入多个密码。
7.当底层的认证机制改变时上层软件不需要修改。
8.结构为systemauthentication提供一个pluggable_model。
9.必须能满足现有的服务需要。
PAM的功能包括:
1.加密口令(包括DES以外的算法);
2.对用户进行资源限制,防止Dos攻击;
3.允许随意Shadow口令;
4.限制特定用户在指定时间从指定地点登录;
5.引入概念"
clientplug-inagents"
,使PAM支持C/S应用中的机器--机器认证成为可能。
PAM为更有效的认证方法的开发提供了便利,在此基础上可以很容易地开发出替代常规的用户名加口令的认证方法,如智能卡、指纹识别等认证方法。
2.3现实解决方案
2.3.1Broker-Based(基于经纪人)SSO方案
这种技术的特点就是,有一个集中的认证和用户帐号管理的服务器。
经纪人[7]给被用于进一步请求的电子的身份存取。
中央数据库的使用减少了管理的代价,并为认证提供一个公共和独立的"
第三方"
。
例如Kerberos(如图2-2所示)、Sesame、IBMKryptoKnight(凭证库思想)等。
图2-2Kerberos图例
该方案采用一个中央数据库来管理用户数据,可能遇到的问题是如果中央数据库当机,会导致所有应用系统无法认证使用。
并且对于旧系统的改造也是使用该方案的一个挑战。
2.3.2Agent-Based(基于代理人)SSO方案
在一个基于代理人的解决方案中,有一个自动地为不同的应用程序认证用户身份的代理程序。
这个代理程序需要设计有不同的功能。
比如,它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。
代理人能也被放在服务器上面,在服务器的认证系统和客户端认证方法之间充当一个"
翻译"
一个基于代理人的解决方案的一个例子是SSH。
SSH的英文全称是SecureShell。
通过使用SSH,你可以把所有传输的数据进行加密,这样就能够防止DNS和IP欺骗。
这是一个为在网上进行安全连接的客户/服务器类型加密软件,实现了一个密钥交换协议,以及主机及客户端认证协议。
SSH的用户可以使用包括RSA算法的不同认证方法。
当使用RSA认证时,代理程序可以被用于单点登录。
代理程序可以在PC,便携机,或终端上运行,当被认证身份加入到代理程序中,如果该代理程序有新的子连结产生,则继承原有连结的认证。
远程系统往往需要一个SSH服务器,用以与代理程序通信。
利用个性化的安全代理来实现时,每个运行SSH的主机(不管是服务器还是客户端)必须有一个安全代理程序在上面运行。
例如,要获得主机密码和服务器密码,个性化代理参与如下的两部分:
1.密钥生成和存储:
当服务器需要生成主机密码和服务器密码时,它会要求本地的安全代理来完成这一工作。
本地安全代理或是自己生成密钥对,或是要求另一个安全代理来生成。
SSH协议并不区分这两种情况。
生成的密钥由安全代理保管,在需要时使用。
2.身份认证:
当客户端得到主机密码或服务器密码,它要传给自己的安全代理,由安全代理负责对密码进行认证。
作为认证结果,安全代理会返回"
成功"
失败"
SSH协议本身不关心有关密码的细节。
稍后,如果有新的公钥算法引入SSH,只需要替换安全代理的部分。
2.3.3Token-Based(基于令牌)SSO方案
现在被广泛使用的口令认证,比如FTP,邮件服务器的登陆认证,都可被称为"
single-factor"
口令的认证。
这是一种简单易用的方式,同时也是一种会带来很多安全隐患的方式。
比如:
易于猜测,很少进行更换,一个口令在多种应用当中使用等等一会危及安全的习惯。
再如,在明文传输的网络环境里,经常使用并很少更换的口令,更易于被窃取和造成危害。
RSA公司提出的一种称为SecurID的解决方案。
与"
不同是是它被称之为"
two-factor"
双因素的认证。
构成认证的第一个因素是PersonnelIdentificationNumber(PIN),即用户身份识别码,这是一串保密的数字,可由系统管理员订制。
第二个要素是SecurIDtoken,一个小型的数字发生器,这个发生器的时钟将与网络环境中提供身份鉴别的服务器(ACE)保持同步,并且与ACE上的用户数据库保持映射。
数字发生器每隔一段时间(比如一分钟)产生新的数字,PIN+同步时钟数字就是用户的登录代码。
解决方案中也有种被称为WebID的模块。
在Web服务器上安装一个ACE服务器的代理程序,用来接受SecurID。
当访问第一个需要认证的URL时,WebID会软件产生并加密一个标识,这个标识将在访问其他资源的时候被用到。
2.3.4AgentandBroker-BasedSSO方案
通过字面我们知道这是Agent与Broker的结合方案。
当Agent-Base的解决方案和Broker-Base的解决方案被相结合时,就结合前者的灵活性和后者的中央式管理两方面的优势。
Agent-Base的好处还