南方航空公司SSO解决方案

《南方航空公司SSO解决方案》由会员分享，可在线阅读，更多相关《南方航空公司SSO解决方案（42页珍藏版）》请在装配图网上搜索。

1、Consulting Services南方航空公司SSO解决方案第1章. 概述1.1. 工程背景1.2. 工程目标1.3. 工程原那么第2章. 功能需求分析单点登录Single Sign On下面简称SSO是目前的企业在进行应用整合过程中需要面临的重要问题。企业应用整合，目标是应用系统之间能够相互访问，整合成一个协作运行的整体；同时用户也可以通过一个系统框架或者企业内部门户，为用户提供统一的访问接口。因此，SSO所实现的“一次登录，到处运行是用户统一访问应用权限的前提，同时SSO实现企业资源统一管理，也是应用系统之间相互访问的根底。2.1. 应用类型分析SSO需要整合企业内部不同应用系统的验证

2、模式，因此需要分析应用类型的类型，以更好地分析实现SSO的需求问题。目前在企业内部已有的应用系统，根本上可以分为以下几种主要形式：2.1.1. 有自己验证模式Web应用程序这一类的应用系统是企业中基于Web界面开发的应用程序，有自己的用户权限管理和验证模式，一般通过HTML的FORM表单发送用户名和密码等验证信息，并通过Session 、Cookie或者证书保持验证信息。2.1.2. 操作系统集成验证的Web应用程序这一类的应用系统是企业中基于Web界面开发的应用程序，有或者没有自己的用户权限管理，一般通过Windows Server的集成验证，实现用户的验证。用户的个性化信息，存储在数据库或

3、者企业目录内。2.1.3. 有自己验证模式Win32应用或者Lotus NotesWin32应用使指在Windows 9X、2000和XP等操作系统平台上，通过Win32 API运行的应用程序。有相当一局部Win32应用有自己的用户权限管理和验证模式，在系统内部进行用户验证和权限控制。在Windows操作系统上Lotus Notes系统也属于这一类应用，Lotus Notes在windows平台上运行是也是依靠Win32 API作为底层的运行支持，而且Lotus Domino/Notes自己内部维护用户权限管理、身份验证和资源访问控制。2.1.4. 操作系统集成验证的Win32应用程序这里是指

4、通过Windows集成验证进行用户身份验证的Win32程序。有一局部此类应用系统自己维护用户权限管理和访问控制；还有一局部通过目录效劳管理管理和控制权限和资源访问。2.1.5. 将来开发的应用程序这一类应用的可塑性较高，无论采用何种运行模式，只要企业提供一个统一的登录验证和资源控制框架，这些应用遵循标准的协议和接口，就可以和企业统一的SSO平台集成。2.2. SSO系统需求分析2.2.1. 兼容以往的应用系统需要实施SSO平台的企业中一般都已经存在大量应用系统，这些系统都运行良好，甚至是不能中断地关键业务系统。虽然这些系统的验证方法五花八门，但是如果需要修改所有系统的验证模式，使之统一到企业标

5、准的验证框架上，是很不现实的做法。因此本工程中的SSO解决方案应当能够最大程度兼容企业中以往的应用系统，在不修改原有系统的源代码的根底上，实现企业内部统一的SSO。2.2.2. 提供统一的框架和接口SSO平台作为企业统一的验证和权限控制平台，应当提供一个统一的系统框架，为各种应用系统提供标准的验证协议和接口。首先，SSO系统提供统一的验证入口，各种应用系统的验证都通过这个入口进行验证。然后，SSO系统提供标准的用户权限信息和资源控制信息访问协议，让应用系统能够读取SSO的信息内容，作为跨系统、跨平台验证的依据。最后，SSO系统提供对象化的开发接口，使新的应用系统开发更为便捷，降低工程风险和实现

6、代价。由于目前大局部客户端都是在Windows 上面运行的，因此至少提供基于COM/DCOM的开发接口。2.2.3. 和其他企业的验证模式兼容企业之间、企业和政府之间的信息交换和功能互访，在Internet快速开展的根底上，已经越来越多的成为必要和经常性的业务。包括证券行业在内的很多行业，跨企业的信息交换和相互访问信息系统是日常工作中的必不可少的内容。要能够确认参加数据交换的参加者和业务系统访问者的身份，以及能够控制访问者能够访问的资源以及操作权限，是需要两个企业的验证系统之间能够相互兼容，互相验证对方的用户。为了使企业验证系统之间相互兼容，最好的方法是都遵循同样工业标准。因此，本解决方案应该

7、采用业界标准的协议和访问接口。2.2.4. 支持分布式部署国信证券是一个国内有多个分公司的大型企业，因此本系统应该支持分布在不同地区的分布式系统部署，使之能够满足大型企业在跨区域联合验证过程中，对性能、功能和管理的要求。第3章. SSO技术实现本解决方案将着重于实现企业内部统一的登录验证机制，技术上的目标不仅仅在于解决将来在统一验证系统架构下开发的应用程序的单点登录问题，而且还能够兼容企业现有的应用系统单点登录。3.1. SSO系统体系架构本系统解决方案整体的体系架构如下列图所示，划分为“访问接口层、“目录效劳层以及“目录接口层三个层次：3.1.1. 访问接口层在这一层内实现的，是为应用程序提

8、供集中认证效劳的验证接口模块。针对企业内部不同模式的应用系统，这一层分为3个功能模块：l SSO Web Access CASSO Web应用验证中心SSO Web应用验证中心是为基于Web的应用程序提供一个集中的验证框架，使基于Web的应用程序能够通过一个通用的接口，实现“单点登录、到处运行的功能。由于SSO Web应用验证中心是一个统一验证的框架，需要Web应用程序基于这个框架下指定的约束和标准，进行简单的开发或者改造，就可以完全实现SSO的功能。l SSO AgentSSO验证代理SSO AgentSSO验证代理是一个安装在客户端的验证代理工具，其作用是为了兼容以往开发的Web、Win3

9、2以及Lotus Notes应用程序的验证过程。以往开发的Web、Win32以及Lotus Notes应用程序的验证一般都是有自己一套的验证模式和过程，如果都要经过修改或者重新开发，才能利用SSO系统进行统一验证，付出的代价会非常大而且不现实。SSO Agent在用户登录到SSO系统以后，自动代替用户完成这些已有系统的验证过程，使用户感觉起来登录一次以后，就可以登录各种不同的系统，起到兼容原有系统的作用。l ADSI/LDAP InterfaceADSI/LDAP 接口ADSI/LDAP InterfaceADSI/LDAP 接口是基于业界标准目录访问协议的接口，也是微软Active Dire

10、ctory技术提供的，让应用程序实现SSO功能的标准接口。在将来开发的应用系统，只要利用ADSI/LDAP 接口访问的SSO系统目录信息，同步其验证信息，就可以实现SSO的统一登录。ADSI/LDAP 接口意义在于为将来的应用开发提供了符合业界标准标准接口，是将来新应用程序应当遵循的验证接口，使应用系统不仅仅用户的单点登录功能，还使应用系统之间的信息和功能交换可以较容易地实现。3.1.2. 目录效劳层目录效劳层是基于微软Active Directory目录效劳技术实现的。目录效劳层为企业统一验证和资源管理提供一个基准记录，在目录效劳器内包含了企业内用户和各种资源的信息以及访问权限信息，为各种应

11、用系统的验证过程提供一个参考标准，使企业内部有统一权限的管理根底，是实现SSO功能必不可少的局部之一。3.1.3. LDAP访问接口LDAP访问接口是为了和其他支持LDAP轻量级目录访问协议的目录效劳器以及用户管理系统进行交换的接口。这是因为企业在电子商务全面开展的过程中，和其他单位、客户和合作伙伴之间往往有相互访问的需要。通过标准的LDAP协议，使SSO系统能够和其他单位的目录效劳系统和人力资源系统等可以管理用户验证信息的系统进行交互，使企业之间的相互验证成为可能。3.2. 关键实现技术选型本章节对解决方案中关键的实现技术进行描述：3.2.1. 基于LDAP的目录效劳技术本节将论述LDAP协

12、议的目录效劳技术对于建立企业统一的平安验证和资源管理的意义。目录效劳是企业网络结构的一个必要和不可别离的局部，该结构是特别为分布式的网络环境而设计的。活动目录可以让公司有效地共享和管理网络资源和用户的信息。此外，活动目录扮演着网络平安性的主要权威的角色，它让操作系统准备好验证用户的身份并且控制他或她对网络资源的访问。同等重要的是，活动目录起到了把系统集成到一起的结合点并且稳固管理任务的作用。3.2.1.1. 目录效劳的重要性企业要实现SSO，就需要一个权限验证的基准系统，为各种应用系统的用户验证提供一个标准的参照。目录效劳就是这样的一个系统，通过一个多层的目录结构，对企业内的用户和各种资源的权

13、限信息统一存储，其他业务系统都必须以目录效劳的内容为标准，才不会各自为政，相互之间的验证可以兼容。3.2.1.2. LDAP协议LDAP协议是业界标准的目录效劳访问协议。只要遵循LDAP协议提供效劳，应用程序可以无需知晓目录效劳的具体实现过程，就可以和不同的目录效劳进行通信。因此，不同的目录效劳系统后台的实现可以采用各种不同的技术，从简单的文件数据库、结构化数据库到复杂的目录结构数据库，都可以用同样的协议访问。同时，标准的协议使不同企业之间的目录效劳能够相互访问，实现跨企业、跨平台的互相验证。3.2.2. Active Directory与其他LDAP目录效劳系统比照Active Direct

14、ory是微软公司实现的目录效劳系统，内置在Windows 2000 Server及以上的效劳器操作系统中，为用户提供了稳定和廉价的目录效劳功能。比照其他基于LDAP协议的目录效劳系统，Active Directory其实也是一个提供全部标准目录效劳的系统，并且在此根底上，针对Windows平台的特点，进行了一定的扩展，使之功能更为强大。Active Directory和其他基于LDAP技术有以下的优势，是本工程中选择其作为目录效劳层的重要因素：3.2.2.1. 和客户端整合的优势由于Active Directory是和Windows平台紧密集成的目录效劳，Windows客户机、效劳器系统的验证

15、机制都可以自然地和Active Directory相互集成。由于目前世界上的PC机用户绝大局部都是使用Windows平台的，客户端的机器在登录网络时默认就是使用Windows验证机制，因此比照其他需要额外增加组件或者开发的目录效劳系统来说，更有自然整合的优势。因此，在本工程中选择Active Directory，更多的表达了系统整合和部署方面的优势。3.2.2.2. 廉价的目录效劳系统Active Directory内置在Windows 2000 Server平台内，无需其他额外的费用就可以提供目录效劳，比照其他商业化的目录效劳产品，具有相当明显的价格优势。3.2.2.3. 性能和功能优化Ac

16、tive Directory在微软的产品开展策略中，是Windows平台现在和将来统一的目录效劳，是用户验证和资源管理的根底。因此微软公司对Active Directory 进行了大量的优化，使其性能相当优秀。目录效劳的特点是被读取的操作最多，相对目录内容的增删改操作较少，因此Active Directory特别对目录的读操作进行了性能优化。同时，Active Directory充分考虑了分布式部署、多层次部署的优化，使其能够在全球化的企业中进行复杂的部署。对于大型的企业来说，Active Directory更容易进行大规模部署。3.2.2.4. 扩展的效劳接口LDAP协议是为了跨平台的目录访

17、问实现的一种协议，因此在协议制订时，在开发、功能和通用性方面有一定的平衡。因此在Windows平台上的开发并未得到最优化。因此微软公司专门为Active Directory开发了在Windows平台上的扩展接口ADSIActive Directory Service Interface，通过对象化的开发模型因为ADSI是一种COM接口、以及扩展的功能提供比LDAP更强大的功能，使基于目录效劳的功能开发更为方便和快捷，因此在Windows平台上，基于Active Directory的应用开发非常容易。3.3. SSO Web Access CA技术实现SSO Web Access CA下面简称W

18、eb CA是一个基于Web的认证中心，所有用户只需要在Web CA中认证一次，即可访问所在企业内部和以及通过LDAP连接的其他企业的应用效劳。对于应用程序，就无需管理用户和编写大量的认证、注册代码，通过Web CA提供的接口，可以简单而平安的实现用户的统一认证。同时应用系统也可将原有的用户认证纳入到统一认证中。对于用户，实现“一点认证，全网通行。无需大量的记录用户名和密码。同时，统一认证还充分的支持漫游认证，即用户所属的企业与被访问的应用系统可以不属于同一个企业或者一个地理区域。这些对用户来说是非常方便的。3.3.1. Web CA在SSO中的作用Web CA在企业中是一个提供第三方验证的授权

19、中心，通过对用户提供基于验证票证或称证书的授权，使用户能够访问基于Web的应用系统。其地位如下列图所示：3.3.2. 认证过程相关术语：1. 企业目录：放置用户权限信息的目录效劳器，如AD效劳器2. Web CA认证中心：为用户和应用系统发放验证票据数字证书的第三方验证效劳器。3. 票据证书：基于Cookie和数字证书技术的授权凭证，用于审核用户和应用的合法性；4. Primary Ticket根本票据：Web CA证书证明用户身份合法性的票据证书，具有一定的时效性，过期失效；5. CA Ticket效劳验证票据：Web CA证书证明用户可访问应用系统功能合法性的票据证书，具有一定的时效性，过

20、期失效；3.3.2.1. 过程1(登录)l 适用情况1. 用户首次登录SSO系统。2. 用户已登录SSO系统，但已在非活泼的情况下已超时，SSO系统已设定用户失效。l 认证流图如下图1 用户认证流程示意图1. 用户向应用系统请求认证或使用应用系统提供的效劳。2. 应用系统发现该用户没有CA Ticket验证票据，确定用户还没有登录，把用户定向至Web CA认证中心。3. 认证中心先判断应用系统是否合法，发现用户没有Primary Ticket，显示登录页面。4. 用户在登录页面中输入用户名和密码，确认登录。5. 认证中心从目录数据库中读出帐号信息，并验证其正确性。6. 认证中心为用户颁发一个P

21、rimary Ticket。7. 认证中心生成一个针对应用系统的CA Ticket，返回给SP A1。8. 应用系统缓存用户的CA Ticket并为用户提供内容的效劳或返回身份验证结果信息。3.3.2.2. 过程2(登录后使用其它的SP效劳)l 适用情况1. 用户已登录SSO系统，访问一个新的应用系统；2. 用户已登录SSO系统，在未超时的情况下，访问一个已经访问过的应用系统；l 认证流图如下1. 用户向应用系统请求认证或使用应用系统提供的效劳。2. 应用系统发现用户没有自己的CA Ticket，应用系统把用户定向到所属的认证中心。3. 认证中心判断应用系统是否合法，发现用户已经有Primar

22、y Ticket。4. 认证中心生成应用系统的CA Ticket，返回给应用系统。5. 应用系统为用户提供效劳。注意：在该认证过程中，Web CA认证中心不需要再访问用户数据库。3.3.2.3. 过程3(用户漫游)l 适用情况企业在多个区域分布式部署了多个Web CA验证中心，为各自区域内的用户和应用系统提供验证效劳。用户B1属于认证中心B的用户。B1还未登陆，B1访问属于认证中心A的应用系统A1。l 认证流图如下1. 用户B1访问应用系统A1。2. 应用系统A1发现该用户没有自己的CA Ticket，把用户定向到认证中心A。3. 认证中心A先校验应用系统的合法性，再发现用户没有Primary

23、 Ticket。4. 认证中心A显示登录页面 ，输入用户名、密码，并选择区域,确认登录。5. 认证中心 A从用户数据库中读取数据，再发现用户不属于认证中心A的区域。6. 认证中心A判别用户为非区域中心用户，将其指向企业一级验证中心。7. 企业一级验证中心将用户信息交给用户所在的区域的认证中心B。8. 认证中心B从用户数据库中读取数据，发现用户存在。9. 根据用户认证中心B给企业一级验证中心颁发Primary Key及CA Ticket。10. 将Primary Key、CA Ticket企业一级验证中心转至认证中心A。11. 认证中心 A给用户频发Primary Key。12. 认证中心A为应

24、用系统A1生成将企业一级转发的CA Ticket。13. 应用系统A1允许用户访问。3.3.2.4. 过程4(登录后使用其它应用系统效劳(漫游)l 适用情况用户B1属于认证中心B的用户。B1已经登陆，B1访问属于认证中心A的效劳商SP A2。l 认证流图如下1. 用户B1访问应用系统A2。2. 应用系统A2发现该用户没有自己的SP Ticket，把用户定向到认证中心A。3. 认证中心A先校验应用系统A2的合法性，发现用户拥有Primary Ticket， 认证中心A生成应用系统A2的SP Ticket。4. 应用系统 A2允许用户访问。3.3.3. 统一认证的特点l 基于Web的标准方式认证单

25、点认证不要求用户安装特别的客户端，单点认证支持标准的浏览器如Netscape Navigator2.0版本以上 和Microsoft Explore3.0版本以上。l 用户认证只需填写用户名和密码系统提供后备认证功能，用户在遗忘密码后，有一个后备途径可以恢复或更改密码。l 应用系统不需要对用户进行验证所有的验证都在Web CA认证中心进行。应用系统把用户输入的帐户信息作为输入参数调用认证中心的认证效劳，认证中心校验了用户的密码后把用户的ID返回给应用系统，并且根据应用系统的请求，可以把用户的局部Profile信息提供给应用系统进行个性化效劳。l 不同应用系统的单点登陆用户只需要登陆一次，即可访

26、问所有应用系统网站。l 隐私保护系统在处理认证过程中，不会将用户的隐私信息泄漏给应用系统。应用系统只能获得最根本的信息：用户帐号名和用户ID。3.3.4. 平安性保证l 用户标识唯一性每个用户对应于一个64位长的唯一标识ID。l 数据加密敏感的数据，例如用户的密码，采用3层DES加密算法，总长56*3=168位的键进行加密后保存在认证数据库里，防止用户密码的泄露。l 审核对认证数据库的数据进行跟踪审核。所有对数据的修改都写入到审核日志，以保证认证数据的完整性和平安性。l 双向验证当应用系统注册效劳后，获得一个唯一标识ID，和唯一的加密的键。当应用系统向认证中心发出验证请求时，认证效劳器对应用系

27、统的ID进行校验，只有合法的应用系统才能通过校验和使用认证效劳，这样就保障了用户的数据的平安。l 平安传输用户登陆时输入的用户名和密码以SSL方式向认证效劳器发出。l 防止破解功能如果一个用户连续输入几次密码都不对，认证效劳器自动的将该用户帐号阻塞几分钟。该措施是为了防止一些黑客和破解程序使用字典数以千万次不断的猜想用户的密码。3.4. SSO Agent技术实现SSO Agent是一个安装在客户端的程序，只要用户登录SSO系统以后，SSO Agent能够自动为用户登录Web、Win32和Lotus Notes应用程序，使用户在使用过程中，不用屡次反复输入用户名和密码，实现“一次登录，到处运行

28、。SSO Agent的作用在于能够最大程度兼容企业内原来就有各种应用程序，使用户能够不修改原有的应用系统，就能够实现统一的SSO。3.4.1. SSO Agent登录过程用户利用SSO Agent实现单点登录的过程如下列图所示：1. 用户通过SSO Agent登录SSO系统，SSO Agent和SSO系统的目录效劳器通信，确认用户身份的合法性；2. SSO Agent从目录效劳器获取用户登录各种应用系统的验证信息，如用户名、密码、需要识别的应用程序的窗口类、窗口内各个控件的类和需要进行的操作等，缓存在SSO Agent内；同时SSO Agent驻留在客户端内存内，监控机器上正在运行的应用程序类

29、型；3. 当用户访问应用程序时，SSO Agent即可通过驻留在内存上的监控程序，获知用户需要访问应用系统，如果和缓存中的信息吻合，那么启动自动验证功能；4. SSO Agent根据设定信息，通过Win32 API直接在应用程序窗口内填写用户名和密码，并且自动点击发送按钮，使验证过程自动完成；5. 当用户注销在SSO系统的登录状态时，SSO Agent去除缓存在本地的验证信息；3.4.2. SSO Agent关键技术说明SSO Agent是一个已经成功开发和在客户实际应用中部署的客户端代理程序，下面根据SSO Agent已有功能，说明其关键的实现技术。3.4.2.1. Win32及Lotus

30、Notes监控及自动登录实现Win32和Lotus Notes都是通过标准的Win32 API在Windows操作系统上运行的，因此可以通过Windows API函数跟踪在内存中运行的窗口句柄，以及窗口和窗口中各种控件基于的类。这就为SSO Agent监控应用程序的运行和自动写入验证信息打下根底。如下列图就是各种不同应用系统中的控件类：SSO Agent通过驻留在内存中的钩子函数，监控内存中正在运行的窗口然后在SSO Agent能够根据应用程序的窗口中的控件类，识别出验证时需要填写的文本框如：用户名、密码框和需要自动点击的按钮。如下列图是窗口内需要填写用户名的文本框：下面是密码框：最后是需要自

31、动点击的按钮控件：可以看到SSO Agent能够很好地识别和管理针对不同Win32和Lotus Notes应用程序中的类以及需要实施的自动填写和点击策略。3.4.2.2. Web应用程序监控及自动登录实现SSO Agent包含了一个名为“IEHelper.dll的IE Addin组件，作为监控Internet Explorer正在访问的网址以及网页中内容的“钩子。IE Helper直接挂接在Internet Explorer上，当IE启动时，IEHelper也随之启动。用户通过IE访问基于Web的网站时，系统跟踪到IE正在访问的网址以及网页中需要用户填写用户名、密码以及需要点击的发送按钮。如下

32、列图：IEHelper能够支持基于所有HTML 格式进行验证信息发送的识别和自动信息写入。当基于Web的应用系统使用集成验证模式时，即在登录系统使，不是使用HTML页面发送验证信息，而是通过IE弹出Win32验证窗口时，那么不使用IEHelper进行识别和填写，而是由Win32识别局部完成，因此能够很好地兼容各种类型的Web应用程序。3.4.2.3. 识别策略的生成与管理SSO Agent如何识别出各种应用系统、以及如何填写验证信息、填写什么验证信息是通过识别策略实现。识别策略包含几个局部的内容：1. 应用类型2. 应用识别信息3. 验证信息获取方法4. 填写策略管理员的可以通过管理工具，指定

33、应用程序的识别策略的内容，并发布到目录效劳器内，统一登录的根据。3.4.2.4. 平安性保证l 身份确认只有用户登录到SSO系统时，SSO Agent才会把用户的验证信息下载到本地，才开始代替用户自动验证，因此能够保证用户身份确认。l 验证信息集中存储用户各种应用的识别和验证信息都集中存放在目录效劳器内，在本地的信息通过加密后缓存在内存中，只要用户关机或者注销登录后，就会失去，保证了信息不被窃取。l 自动登录过程快由于SSO Agent自动登录应用系统的过程是通过API函数自动完成的，因此过程非常快，用户完全感觉不到窗口弹出和发送的过程，难以进行跟踪。第4章. 微软与其他厂商解决方案比照4.1

34、. 微软解决方案的优势l 微软的SSO解决方案是一套完整的体系微软在其Active Directory目录效劳的根底上，实现了统一的验证体系。微软在效劳器端和客户端的软件产品中，都贯彻了这一标准的验证体系，比照某些厂商多种不同的验证体系并存，更容易为企业提供统一的规划和实施策略。l SSO实现的代价更低微软的目录效劳体系是内置在效劳器产品内的，减少了其他厂商需要额外购置的费用。和微软解决方案一向秉承易于开发、周期短、本钱低的优点，基于微软的SSO应用开发本钱更为低廉。因此微软的SSO解决方案更有优势。l 和客户端软件集成的天然优势目前客户端软件在微软产品一支独秀的前提下，用户常用的操作系统、O

35、ffice软件、Wen浏览器和客户端软件都是基于微软的平台开发，因此和微软SSO整合的优势不言而喻。l 能够兼容以往的应用系统本解决能够解决兼容以往应用程序的问题。而其他应用系统那么需要所有的应用系统遵循其提供的框架、标准或者接口进行开发，才能实现SSO。4.2. Oracle SSO解决方案分析4.2.1. Oracle SSO Server产品背景根据Oracle官方网站介绍，Oracle 9iAS Single Sign-On的解决方案是用来整合Web应用单点登录的应用需求，其核心技术就是Oracle 9i AS SSO Server。这个技术最早推出是在Oracle 9i AS Sv1

36、这个版本，但是在这个版本，这个功能只是作为Oracle 9i AS Portal的一个组件功能，到了Oracle 9i AS Sv2，SSO Server变成Oracle 9i AS的根底组件，不需要再和Oracle 9i AS Portal一起安装。原文如下：The core of Oracle SSO technology is the Oracle9iAS SSO Server. This technology was originally introduced in Oracle9iASv1 as a component of Oracle9iAS Portal, but in Ora

37、cle9iASv2 the SSO Server is an infrastructure component, and does not require Portal to be installed. 按照官方网站的介绍，Oracle SSO Server提供了一个多个Web应用程序的身份认证框架，减少了应用程序的开发时间新Web应用无需再编写登录处理、身份认证，减少Web应用程序的系统管理员维护，而且由于用户无需再记住多套密码从而提供了系统的平安。原文如下：Oracle9iAS SSO provides an authentication framework which can be hi

38、ghly useful when deploying multiple web applications. SSO improves the user experience, reduces application development costs since applications do not need their own authentication mechanisms, reduces system administration costs, and improves system security since problems associated with multiple

39、passwords are eliminated.按照Oracle SSO Server的设计情况，将需要整合的Web应用分为两类，分别是Partner应用下简称伙伴应用以及External应用下简称外部应用。以下分别介绍其划分原理：伙伴应用与Oracle SSO框架紧密集成，由SSO Server验证用户的身份，并且将验证过的用户身份传递伙伴应用程序。伙伴应用程序可以被设计或者修改成将身份的验证工作委托给9i SSO Server，并且接收SSO Server传递过来的验证用户身份。通过这种手段，可以简化伙伴应用程序的管理，并且减少开发的工作以及后续的管理工作的工作量。原文如下：Partne

40、r applications are those which work within the SSO framework. Specifically, they are designed (or have been modified) to delegate responsibility for user authentication to the Oracle9iAS SSO Server. They accept the user identity presented to them by the Oracle9iAS SSO Server. Since partner applicati

41、ons take advantage of the authentication services of the Oracle9iAS SSO Server, they do not need to implement their own authentication modules. User administration is simplified for partner applications, since there is no need to manage passwords for these applications. Deploying an application as a

42、 partner application thus can reduce both development and ongoing administrative expenses.外部应用程序指还需要记录用户帐号、密码的应用程序，这类应用不委托由Oracle SSO Server进行用户验证，因此，此类程序无需要进行特别的开发或者修改，还会有自己的一套用户身份验证的程序以及用户/密码的管理程序。由于此类程序的验证登录Web页面也千差万别，为了实现单点登录，每个外部应用程序都必须在SSO Server中进行客户化的应用参数化设置。另外，用户修改账号信息或者管理员进行用户管理的时候都需要执行一些特

43、定的处理动作或者是一些特定开发的程序比方：用户注册。原文如下：External applications are those which retain their own usernames and passwords, and do not delegate responsibility for authenticating users to the Oracle9iAS SSO Server. These applications have not been developed or modified to work within the SSO framework. A typical

44、external application might be one developed or deployed by a third party, such as a portal website which requires username and password for access to custom services like email. Since external applications do not take advantage of the Oracle9iAS SSO Server authentication mechanism, they must impleme

45、nt their own authentication modules and manage their user passwords. Because different external applications may have different web forms for entry of usernames and passwords, supporting external applications may require application-specific customization of the Oracle9iAS SSO Server. Users or syste

46、m administrators may be required to take some specific action when installing or changing usernames and passwords, such as entering this information via a special registration page. Setting up such registration pages may require development of application-specific functionality within the Oracle9iAS

47、 SSO Server. Oracle SSO Server在Oracle 9i AS Sv2后，还提供了一个组件模块Mod_osso，可以通过这个组件将Oracle9i Server集成SSO Server，这样运行在Oracle Server上的各种程序都可成为伙伴应用。这是Oracle推荐的做法，让所有基于Oracle Server的应用程序都参与到Oracle的SSO Server。原文如下：Mod_osso is a new feature introduced in Oracle9iASv2. It is an extension to the Oracle Server whic

48、h enables the Server to be an SSO partner application. Applications running underneath the Server, such as servlets, can then obtain a users authenticated identity from mod_osso in the form of an Apache header. Mod_osso therefore allows applications to participate in the Oracle9iAS SSO framework wit

49、hout requiring that the applications embed specific partner application logic. It is the recommended way for applications running on Oracle9iAS to participate in Oracle9iAS SSO.Oracle SSO Server还可以集成其他第三方的SSO效劳器，在目前所能找到的官方技术资料中，有Siteminder from Netegrity, Inc，是否支持其他的SSO效劳器目前还没有得到确认。在这里不做特殊论述，如果需要，请联

50、系Oracle公司的技术支持。4.2.2. Oracle SSO Server运作机理分析Oracle SSO Server包含有两个组件，分别是SSO Login Server以及SSO API。下面先分别介绍这两个组件的功能，然后按照前面讲解的两种Oracle整合的Web应用分类，分别介绍伙伴应用以及外部应用的SSO运作过程。4.2.2.1. Login Server 登录效劳器当用户第一次Web应用程序伙伴应用，登录效劳器完成以下的工作内容：n 通过用户名以及密码验证用户的身份；n 将验证过的用户身份传递给不同的应用程序；n 通过加密的Cookie来申明此用户是一个已经验证过的正确身份在

51、后续的用户登录，登录效劳器通过此Cookie来确认用户是否已经验证过身份，如果不存在Cookie，那么执行已上的登录过程。另外为了提供平安的访问，Cookie支持通过SSL进行传输，另外cookie有一个过期时间，并且Cookie也不存放到浏览器端的硬盘，因此关闭浏览器，Cookie也就无效了。详细资料，请查阅参考资料1中的第二章第1小节。4.2.2.2. SSO API 程序接口SSO API共分两类，分别完成以下的功能：n 完成Web应用与SSO Server的通讯，关键就是接收SSO Server传递过来的用户身份；n 管理员管理Web应用与SSO Server的关联关系；详细资料，请查

52、阅参考资料1中的第二章第1小节，另外在参考资料1中提供了PL/SQL以及Java使用SSO API的例程。4.2.2.3. 伙伴程序的SSO如右图所示，典型的伙伴程序的SSO验证过程如下：用户直接访问伙伴程序的页面；如果是第一次访问伙伴程序，那么伙伴程序自动将请求重定向到登录效劳器的登录页面 伙伴程序的必须编写这段代码逻辑，现有的程序需要经过改造才能完成此功能；登录效劳器的验证过程如本章的第一小节登录效劳器的运作过程描述。合法的身份，登录效劳器会将请求重新重定向到用户访问的伙伴程序页面，并且通过URL的参数将加密的用户身份信息传输给伙伴程序页面伙伴程序解密用户身份并且建立自己应用程序的Sess

53、ion会话信息 伙伴程序的必须编写这段代码逻辑，现有的程序需要经过改造才能完成此功能从以上的运作过程，我们可以知道伙伴程序需要同时满足以下两个的需求就可以与SSO Server协同工作：n 实现身份的验证l 需要身份验证的页面，都需要加上身份验证的判断逻辑检查是否存在验证过的会话信息l 如果还未验证过，那么将页面的请求重定向到登录效劳器的登录页面l 如果页面是无需身份验证就可以使用，那么无须进行修改n 实现一个登录处理的页面l 这个页面根据登录效劳器传输回来的加密用户信息，解密并且建立用户的已验证过的会话信息。l 将请求重新定向到用户所访问的本伙伴应用的页面4.2.2.4. 外部程序的SSO如

54、右图所示，典型的外部应用的第一次SSO验证过程如下：Oracle9i AS Portal根据外部应用程序在效劳器中的配置信息，生成对应的外部应用程序超连接，在Portal的Portalet中显示用户在Portal中点击了此超连接根据此超连接，由Portal调用登录效劳器，登录效劳器此时检查登录效劳器上是否有此合法用户登记的本外部程序的访问账号，如果没有，那么登录效劳器重定向用户输入外部效劳器的账号和密码用户在浏览器中输入账号和密码，同时，用户可以选择是否将此外部应用的账号和密码记录到SSO Server中的密码数据库中如果用户选择，记住此密码，那么用户/密码信息记录到Oracle SSO Se

55、rver中；接着登录效劳器执行以下的处理：登录效劳器根据SSO Server中预先配置的外部应用程序的登录页面以及用户的身份密码信息，模拟用户在外部应用程序登录页面输入信息，生成这个登录页面的页面信息；将页面信息送回用户前端的浏览器中，并且马上发送这个登录信息到外部应用程序，完成模拟用户访问外部应用的输入账号/密码的过程客户端浏览器自动将外部应用的登录页面投到后台的外部应用，完成外部应用的身份验证过程根据参考资料1中第二章第三小节的介绍，当用户第二次点中Portal中外部程序的连接，系统将重新根据用户记录在SSO中的外部应用的用户名以及密码，再一次重新生成用户的登录页面，模拟用户的手工登录。如

56、果用户没有将账号/密码记住在SSO Server，用户还需要再执行以上的登录过程。4.2.3. Oracle SSO Server的优缺点根据以上Oracle官方资料的分析，我们可以得到以下的结论。Oracle SSO Server是一种基于Token 传递的Token就是登录效劳器的Cookie和Agent 在对外部应用程序的SSO方面，SSO Server记录用户在外部应用程序的账号以及密码，模拟用户的手工登录的SSO解决方案。Oracle SSO Server对于解决Oracle 9i AS中Web应用程序的整合起到内置的支持作用的。从系统整体的SSO方案上看，Oracle SSO Se

57、rver存在以下的缺点：n 目前的Oracle 9i AS SSO Server解决方案，只能解决Web Application的整合问题，无法解决企业内部的其他C/S应用的SSO；n Oracle 9i AS SSO Server是基于应用级的SSO解决方案，不是采用验证协议来整合应用，而是通过应用级的程序框架来实现SSO；n Oracle 9i AS SSO Server对外部应用的整合能力是和Oracle 9i AS Portal紧密集成的，只有通过Portal的Application超连接进行SSO整合；n 从其外部应用SSO的运作机理来看，用户如果在浏览器本身的地址栏输入外部应用的网

58、址是无法进行SSO整合的，另外如果用户不将外部应用的账号密码存储的SSO Server的Database，即使在Portal里面再一次点击外部应用程序，也需要用户重新输入一次账号/密码；n 从其对于外部应用SSO运作机理上看，只能进行Form-Base的外部应用整合模拟用户在外部应用的登录Form填写账号/密码；Oracle SSO Server是无法支持基于浏览器系统集成验证方式 这种验证方式是浏览器获得效劳器的状态 status为 401.1 - Unauthorized时，浏览器知道用户还没有验证，会自动弹出浏览器的系统登录窗口，供用户输入账号/密码，然后将用户/密码送回给 Server

59、验证身份； -Authorization的外部应用，比方Exchange、Domino等邮件系统的Web客户端；n 从其整合伙伴应用的运作机理来看，对于整合一些较为简单的伙伴应用来讲是没有问题的；但是如果复杂一点的伙伴应用，比方财务系统，即使经过了中心登录效劳器Login Server的身份验证，系统可以认为你是个合法的用户，但是这个合法用户却是不一定能够访问这个财务系统的，因此在这种体系下，财务系统本身还是需要有访问财务系统的账号子集列表，不能只依赖SSO Server的身份验证，并且还必须有子系统的身份验证以及子系统的账号/角色/授权管理的子系统支撑，然后通过特定的代码来实现子系统的账号和

60、Login Server账号/授权信息的同步，这类的系统要求应该讲在企业内部来讲应该是非常多的；n 对于一些是采用cgi方式的外部应用，或者是已经编译成servlet的外部应用，这些应用如果没有源代码，是没有方法通过修改程序的方式来到达整合成伙伴应用的模式，而只能使用整合成外部应用的方式，而Oracle SSO Server对于整合外部应用的模式是有较多的限制的。4.2.4. 参考资料1Oracle9i AS Single Sign-On Application Developers Guide 2Oracle9i 3 Oracle 9i AS Daily Feature Oracle官方网页

61、介绍4 Oracle官方网站文档5 搜索Oracle SSO Server共有5400项4.3. IBM SSO解决方案分析4.3.1. IBM SSO产品背景根据IBM官方网站的资料，IBM在SSO方面有不同的解决方案，不同的解决方案用于解决不同的需求。在我们此次技术交流中，着重讨论的SSO解决方案有: Websphere Portal SSO解决方案以及IBM Tivoli Access Manager SSO解决方案。其他的解决方案在此处不加以讨论。根据IBM Tivoli Access Manager的官方网站以及IBM Tivoli Access Manager产品幻灯片介绍，Acc

62、ess Manager的设计目标主要完成以下两大功能：n 整合Web 应用构造一个平安企业平安门户n 实现Web应用的单点登录原文的信息如下：What is IBM Tivoli Access Manager for E-business ( Policy Director ) ? A Secure Applications Portal for the Web Let The Right People In, To Access The Right Applications and Data Cost Effectively Manage Security Policy Definition

63、 and Enforcement ( Web, Java) Single Sign-on to Web based applications从原文信息中看到的Portal功能，但从IBM网站介绍方面可以知道，本身Tivoli是不提供的，是通过IBM WebSphere Portal来实现。另外从下列图的资料介绍，我们可以知道SSO是通过WebSEAL来提供Web 应用程序的单点登录。在参考资料3一文的1.4章节中，IBM重点探讨了Tivoli Access Manager和Websphere Portal的集成对WebSphere的增值，WebSphere允许和Tivoli Access Manager等身份认证效劳器整合，IBM认为，使用两者结合的解决方案对用户是有价值的：n Tivoli Access Manager的平安管理模式比WebSphere内置的平安模式更加有价值；n 在大量的情况下，Tivoli Access Manager除了可以保证WebSphere Portal应用的平安外，还可以保护其他Web应用资源的平安原文如下：Intuitively, it makes sense to implement W