Portal+SSO实现应用系统集成方案.doc

Portal+SSO集成解决方案1. 基本概念1.1 Portal概念portal是一种web应用，通常用来提供个性化、单次登录、聚集各个信息源的内容，并作为信息系统表现层的宿主。聚集是指将来自各个信息源的内容集成到一个web页面里的活动Portal的功能可以分为三个主要方面：1. Portlet容器：Portlet容器与servlet容器非常类似，所有的portlet都部署在portlet容器里，portlet容器控制portlet的生命周期并为其提供必要的资源和环境信息。Portlet容器负责初始化和销毁portlets，向portlets传送用户请求并合成响应。2. 内容聚集：Portlet规范中规定portal的主要工作之一是聚集由各种portlet应用生成的内容，我们将在“如何创建Portal页面”部分对此做进一步讨论。3. 公共服务：portlet服务器的一个强项是它所提供的一套公共服务。这些服务并不是portlet规范所要求的，但portal的商业实现版本提供了丰富的公共服务以有别于它们的竞争者。在大部分实现中都有望找到的几个公共服务有： o 单次登录：只需登录portal服务器一次就可以访问所有其它的应用，这意味着你无需再分别登录每一个应用。例如一旦我登录了我的intranet网站，我就能访问mail应用、IM消息应用和其它的intranet应用，不必再分别登录这些应用。Portal服务器会为你分配一个通行证库。你只需要在mail应用里设定一次用户名和密码，这些信息将以加密的方式存储在通行证库中。在你已登录到intranet网站并要访问mail应用的时候，portal服务器会从通行证库中读取你的通行证替你登录到mail服务器上。你对其它应用的访问也将照此处理。 o个性化：个性化服务的基本实现使用户能从两方面个性化她的页面：第一，用户可以根据她的自身喜好决定标题条的颜色和控制图标。第二，用户可以决定在她的页面上有哪些portlets。例如，如果我是个体育迷，我可能会用一个能提供我钟爱球队最新信息的portlet来取代股票和新闻portlets。Portal的三个特点（各人感觉很有助于理解Portal）：        1.  Personalization （个性化）：用户自己定制自己所需页面        2.  Single sign on（单点登陆）：一处登陆，处处通行        3.  Content aggregation（内容聚合）：不同来源的信息整合到一个页面中现有Portal技术可概括为以下四种：        企业信息门户（EIP，EnterpriseInformationPortal）        依据主题将大量的内容进行组织，并利用这些信息将用户连接起来。        协作门户（CP，CollaborativePortal）        为用户团队提供协同工具，建立虚拟项目工作区并辅助团队协同工作。        专业门户（EP，ExpertisePortals）        将用户依其能力、专业知识及对信息的需求进行连接。        知识门户（KP，KnowledgePortals）1.2 SSO概念SSO（Single Sign-On）直译为一次登录，用户只使用一个用户名和口令，就可以访问所有的资源，这对系统管理和维护来说是非常重要的。单点登录有效地解决了用户使用网络时的多帐号、多密码、多次登录问题，方便了用户。2.1 单点登录的一般模型单点登录模型，一般由三部分构成，分别是：用户、身份提供者和服务提供者，如图1所示。(1)用户是指通过浏览器来使用应用服务的个体。(2)身份提供者是指对个体进行身份验证的服务提供者。(3)服务提供者是指为用户进行应用服务的具体应用服务提供者。2.3 单点登录的工作流程单点登录有三个主体：使用Web浏览器的用户、服务提供者和登录服务器。登录服务器保存着用户的认证信息以及用户的个人信息，服务提供者在得到用户允许的前提下可以到登录服务器上获取用户个人信息。单点登录协议流程如图2所示。       简单的 SSO 的体系中，会有下面三种角色：       1 ， User （多个）       2 ， Web 应用（多个）       3 ， SSO 认证中心（ 1 个）我们将采用如下几种方式实现SSO：1、   统一LDAP验证集成：  我们将四套业务系统的所有用户信息一起放到LDAP服务器内，由ldap统一对四套系统的用户进行验证。这样做比较有利于用户及权限的管理，但是也存在弊端。如果这四套系统用户信息放在不同平台的不同数据库中，而且这四套系统除OA外，各有不同的用户组群，放在一起反而不利于管理。  2、   基于Portal系统LDAP的凭证保险库法 我们采用Portal系统独立存在的LDAP，由这个LDAP验证Portal系统用户的合法性，一旦验证通过，用户就登录进Portal系统。然后用户在给定权限的各个业务系统Portlet中存储在各个业务系统中的用户信息，Portal系统会统一管理这些信息，然后自动到各个业务系统的用户信息库中校验，一旦通过校验，该portlet就能显示业务系统的授权信息。通常我们是在portlet中放入一个Iframe，用户在Portal系统中通过portlet中的这个Iframe来访问具体业务系统中的授权信息。  3、   基于OA系统LDAP的凭证保险库法：基本上等同于第二种方法，不过更简单。domino OA系统是企业内部每个人都使用的业务系统，而且它已经有一套成熟的LDAP，我们不必再为Portal创建LDAP服务器，我们可以直接使用OA系统的，所以有点麻烦的是，在使用Portal系统的时候，OA必须是开着的，即使你不使用OA，因为认证的时候是到OA的LDAP服务其中验证的。其他方面则与第二种方法完全相同。2. 技术方案对比2.1 IBM: Websphere Portal3. 首先要启用安全性，让portal使用IDS的用户进行认证然后再将portal和应用系统集成，这分两种情况：1.应用系统也使用同一个IDS中的用户，这种情况可以实现真正的SSO，也就是只在portal上做了一次登录，然后把凭证传递给应用系统就可以了。这里的应用系统又可以分为两类：（1）使用was或domino等ibm的中间件产品，也就是支持ltpa的，并且应用是基于j2ee标准的安全性来做认证的，那只需要配置was和portal之间的ltpa就可以SSO了，不需要单点登录了。但这种情况似乎非常少，除非应用都是ibm的产品（2）应用虽然使用了同一个IDS用户库，但没有使用j2ee安全性进行认证，通常我们的应用也是这么干的。那么就要改造应用系统的认证模块，使用J2EE的标准安全性来做认证。或者借助TAM eb，CAS这一类具有认证中心的产品，来为portal和应用做统一认证。由于涉及到对系统的改造，实施起来可能就比较麻烦了，新开发的系统使用这种方式倒是很省事。2.应用系统使用自己的用户库，和IDS不统一，这种系统往往是使用待登录的方式来实现SSO。基本的思想是，使用一种安全的密码管理机制来存放用户在各个系统中的密码等用户凭证，并与主用户库建立映射关系。用户登录门户以后，进入应用系统前，由门户帮用户做一次登录的操作。这种密码管理机制可以通过websphere portal提供的凭证保险库，或者TAM eb的GSO来实现。这种方案比较麻烦的是用户在各个系统中凭证变更的管理，IBM也提供IDI,TIM这些产品，可以解决这些问题，不过实施起来也是有点难度的。前面同一用户库的第二种情况也可以看作非统一用户库的特例，也可以使用代登录的方式实现SSO，这样就不用改造应用系统了。4. 项目中几种常用的SSO方法5. 一、LTPA Token（LTPA方式）    适用于：IBM WebSphere Portal 与WAS或者Domino等IBM的中间件产品之间的SSO Re2j&   前提：两者指向同一个LDAP服务器或者用户信息完全相同的不同LDAP#ecoEzV,P/B8?E3b3R二、CookieBased方式"WTf&d9%E-"qq    适用于：SUN PORTAL 或ORACLE PORTAL与其它应用系统之间的SSO'i:_.r;VGDx8r    前提： 用户登陆UID必须一致。'?v|.Z!Z"jGT)MY+b%I$Q三、Credential Vault(凭证保险库服务)7jBSEp0Z  适用于：UID与PORTAL登陆UID不相同的外部应用系统8f'z:KcYHH$Z  前提：用户首次使用或者用户修改密码的情况下用户portlet里再录入一次正确的应用系统的登陆密码；sA1c0Uportal爱好者 e;aWU四、Tivoli Access Manager/Tivoli Identity Manager(统一验证授权机制)aa+tf+"'chD       独立的Tivoli的安全解决方案Websphere6.1+DB2+Ldap方式第一，Oracle版本不是受Portal6.1.0.0支持的正确保本号将导致配置Oracle失败；例如：10.2.0.0，但是Portal6.1.0.0支持的版本号是：10.2.3。必须将Oracle升级到合格的版本，才可以配置。Ø IBM整合了它最领先的各种中间件技术在IBM Websphere Portal中，包括Lotus、Websphere、Tivoli以及DB2，每一种被使用的技术在各自的领域均是毫无疑问的领导者Ø IBM具备最领先、完整的门户架构理念，并在IBM Websphere Portal中封装了与理念相对应的各种服务Ø 包括个性化访问控制、集群管理、安全、虚拟门户创建在内的门户基础服务（Portal Infrastructure）Ø 包括协作、文档以及内容管理、门户程序整合、各种后台应用系统门户程序访问等等门户拓展服务（Portal Services）Ø 包括肤色、外观、多语言以及移动设备支持的门户展现服务（Presentation）Ø IBM Websphere Portal中内置最领先的协作功能（文档管理、内容管理、虚拟团队空间、及时消息服务、WEB会议系统等等），并提供大量开箱急用的门户程序（Portlet）和诸如Domino、IBM Workplace创新应用等等其它领先协作应用整合，甚至于提供门户系统和第三方的协作应用进行整合5.1 BEA:Weblogic Portal软件选择：技术架构：实施步骤：优势：劣势：5.2 Microsoft:Moss SharePoint Portal 5.3 Oracle Portal 6. 技术方案选型7. 技术要求包括：8.9. 1. 平台框架和基础结构10. 提供开放的、可扩展的框架11. 支持J2EE，支持跨平台运行12. 整个系统的开放架构，可与现有和以后的业务系统进行集成，如OA系统等。13. 支持各种流行数据库，如DB2、Oracle、MS SQL Server等。14. 2. 对多个数据格式和不同设备的支持15. 支持HTML、WML、cHTML数据格式16. 支持不同设备包括PC、手机和PDA的接入17. 能够根据接入设备的类型自动调整显示内容18. 3个性化功能19. 个性化定制，管理员可以定制页面访问权限、页面可用门户程序（Portlet）、并能锁定某些门户程序（Portlet）位置20. 用户在权限许可范围内可自主定制页面主题和外观、页面框架、门户程序（Portlet）和位置21. 个性化规则引擎，按用户特性和业务规则个性化页面22. 智能推荐引擎，按业务逻辑和用户浏览历史分析个性化页面23. 4内容管理和发布功能24. 提供与门户系统紧密集成的网站内容管理和发布模块，通过门户程序（Portlet）方式来对网站内容发布、管理，支持网站信息发布管理工作流程控制，并内置工作流引擎25. 可以灵活定义内容模板和页面设计、栏目，并提供内容预览发布功能26. 每个栏目能发布成门户程序（Portlet）方式27. 支持LDAP和门户用户完全集成，实现单点登录28. 通过使用已定义的日期和时间在“活动”站点上进行发布，以及设置它的到期日29. 5文档管理和编辑功能30. 内置丰富的文档管理，方便用户共享工作中的相关文档和文件夹31. 支持文档和文件夹的分类管理，权限控制和版本控制32. 支持250多种文档格式的存储，查看和编辑，用户在授权范围内，客户端可以在不安装字处理软件的情况下对文档进行查看和编辑，并保存相关改动33. 对文档内容和META DATA自动进行索引处理，支持多语言全文搜索34. 6虚拟门户支持35. 支持创建和管理多个虚拟门户，可以提供多达100个虚拟门户36. 每个虚拟门户具有不同的主题、外观和页面、用户和组、URL地址和搜索引擎37. 可以实现分级、分权限管理38. 7安全认证机制39. 内置LDAP服务器，也支持其他LDAP服务器40. 支持第三方的代理（PROXY）认证41. 支持JAAS规范，实现门户应用和后台应用的单点登录42. 全面的用户和用户组管理，ACL资源管理控制，支持以角色的方式对资源进行授权43. 8多语言支持44. 具有简体中文、繁体中文、英文、法文、德文、西班牙文和意大利文等多语言版本45. 能够自动判断客户端的语言设置调整显示内容46. 支持中文到英文网页的双向自动翻译47. 9开箱即用门户程序（Portlet）48. 内置丰富portlet，包含Domino，Exchange邮件portlet等49. 提供portlet builder，通过简单定制，无需编程就可以生成连接SAP, People Soft, Domino应用的portlet50. 提供一体化的IDE开发工具51. 拥有公开的portlet目录提供portlet下载途径，并不断的进行更新52. 10协作功能53. 内置与Lotus Domino/Notes集成的各种开箱即用门户程序（Portlet）54. 提供网上聊天和网络会议功能55. 提供用户感知和协作功能56. 提供协作中心，方便查找用户和好友57. 11搜索引擎58. 支持对Web内容、页面、内容管理、文档管理和Notes数据库等信息的索引和检索59. 支持第三方搜索引擎，如web爬虫、索引器60. 提供对文件和附件的索引及检索，支持HTML, XML, Microsoft Office (Word, PowerPoint, Excel), PDF, Lotus SmartSuite等文件格式61. 可以定义规则过滤器62. 支持全文检索、条件检索、模糊匹配等。63. 技术方案实施1.后台单点登陆： 用户浏览器先后台服务器(WPS)，WPS再去访问各种资源，比如RDBMS数据库、Notes数据库、业务系统等等。WPS有Credential   Vault、JAAS支持。 2.浏览器单点登陆： 浏览器登陆WPS以后，就可以直接访问后台各种Web业务系统。 方式1.WPS有iframe   portlet，在这个portlet中需要配置后台Web业务系统的URL,登陆URL,   用户名、口令等信息。浏览器访问iframe   portlet后，   iframe   portlet在浏览器端自动提交form表单，这样浏览器就能直接访问Web业务系统了。 方式2.浏览器单点登陆部署在Websphere上面的J2EE应用 IBM使用专有技术实现(加密的LtpaToken   cookie，里面有登陆用户的LDAP   dn或者userid) 方式3.浏览器单点登陆部署在Websphere上面的J2EE应用、Domino应用 IBM使用专有技术实现(加密的LtpaToken   cookie，里面有登陆用户的LDAP   dn) 方式4.浏览器通过Tivoli   Access   Manager单点登陆： 方式4.1.浏览器请求都要通过Tivoli   Access   Manager作为代理服务器访问后台资源。Tivoli   Access   Manager作为安全代理和http代理协助浏览器访问后台Web资源。原理是代理。 方式4.2.浏览器访问一次Tivoli   Access   Manager获得一个认证id，以后直接访问其他Web服务器时候提供该认证id就能访问了。原理是通行证。 3.自己编写一套简单的单点登陆系统 方式1.使用java语言编写J2EE单点登陆 方式2.使用C语言编写Web   Server插件进行单点登陆我们的目标是，SSO 提供登录到汉和 Portal 的能力，并允许使用那些用户凭证访问 Domino 环境、Domino、Sametime、QuickPlace 以及其他基于 Domino 的工具；允许用户访问自己权限以内的所有企业及应用，即：运行在普通应用程序服务器上的各种业务系统。例如，运行在WebLogic或者Tomcat上的jsp应用程序，运行在IIS上的asp,aspx系统，以及php系统。二、              SSO的实现 以汉和平台为例，改企业现在存在一下四套业务系统，包括Lotus Notes 开发的OA系统，一套基于WebLogic的jsp系统，两套基于IIS的asp系统，我们就以集成这四套系统为例，简单介绍SSO的实现：   第二部分、Portal 与 OA 的SSO  一、              SSO是如何工作的? Portal 和 Lotus Domino 之间的单点登录是通过一种称为轻量级第三方认证(LTPA)的机制来实现的。WebSphere 应用服务器（还包括 WebSphere Portal 和其他任何运行在 WebSphere 环境中的应用程序）和 Domino 都使用LTPA。当 LTPA 机制用于由多个服务器组成的环境中时，它是通过使用 Domain Cookie 而启用的。这种经过加密的会话 cookie 被放置在用户浏览器中，并包含了一些信息，WebSphere 或者 Domino Application 服务器可以加密这些信息，并使用这些信息来说明用户已经通过该 cookie 所覆盖的DNS（Domain Naming Service，域名服务）域中的认证。  LTPA cookie 包含以下信息： ·         Cookie名称：总是设置为 LtpaToken。 ·         域：设置为 Internet 域，该域由参与单点登录的所有服务器所共享（例如：）。 ·         Cookie 到期：设置为当浏览器的寿命终止时删除该 cookie。 ·         安全：设置为开状态，以强制使用安全套接字层(SSL)。有一个 LTPA 配置有一个设置参数，使它创建只通过 SSL 发送的 cookie。 ·         Cookie值：这被设置为 LTPA 标记，接下来会对其进行描述。  LTPA标记是一个加密的字符串，它包含以下信息： ·         用户数据：一般被设置为用户 ID，但也可以是任何用于惟一标识用户的用户信息。 ·         过期时间：与 Cookie 过期不同，这个字段用于强加一个时间限制，时间限制从登录进来的那一刻算起，而不受浏览器活动或者不活动所影响。这个时间限制是一个可配置的 LTPA 设置，缺省情况下为30分钟。  二、              SSO 的集成效果： 我们可以把整个OA系统作为一个整体，即一个Portlet集成进Portal系统，也可以根据OA内不同的文件数据库(.nsf)俺功能拆分为各个不同的功能单元，每个功能单元作为一个单独的portlet集成进Portal系统 三、              怎样实现OA 与Portal 的SSO？    Portal 与OA 的SSO可以通过配置ltpa的方法实现。通俗一点讲就是：用户登录Portal后，Portal系统会把用户登录信息加密成ltpa并存放到某一位置，当用户继续访问OA中的授权资源时，OA系统会自动读取改位置的ltpa，读到并解密后拿到OA系统中验证，如果验证通过，则显示给用户他要的授权信息。所以要配置Portal 与 OA 之间的SSO 非常容易，只要先将OA系统服务器的ltpa导出并存为.key文件，然后导入Portal系统所在的服务器（WebShpere Application Server）中就可以了。 第三部分 Portal系统与普通应用程序的SSO  一、              概述 WebSphere Portal 提供了 Credential Vault （凭证保险库）功能。Credential Vault 通过 Basic Authentication Header 将用户名和密码传递给后端应用程序。为了使 Domino 服务器接受通过这个头部传递进来的凭证，必须将服务器会话验证配置为Single-Server 模式。在 Multi-Server 模式中，该服务器将会只接受通过 LTPA 机制传递的凭证。因此，为了与 Domino 应用程序一起使用用于 SSO 的 Credential Vault，您必须将 Domino 服务器会话验证配置为 Single-Server 模式。 要使用 Credential Vault，用户需输入一些凭证，输入一次就够了。随后，这些凭证被存放在一个经过加密的数据库表中，每当用户访问该 portlet 时，这些凭证便被传递给后端应用程序。 二、凭证保险库实现SSO原理  1普通业务系统的登录过程： 系统首先提供一个界面让我们输入我们在应用程序中的用户信息   2用户输入用户名和密码后，点击“登录”按钮，该页面提交到form所对应的Action（check_login.jsp）处理，我们看check_login.jsp的代码：    <% String username=request.getParamenter(“username”);  String password=request.getParamenter(“password”);    接下来提交到数据库验证用户信息的合法性，如果合法，定位到授权信息页面；否则，重定位回到登录页面login.jsp。 %> 3  Portlet开发中是如何解决这个问题的？ 其实起关键作用的还是check_login.jsp页面，它需要获得用户名和密码两个键值，然后拿着两个参数到后台数据库去验证。常规登录方式中这两个参数是通过login.jsp来获得的。事实上，只要portlet能为该页面提供这两个键值，也就是先了登录的自动化。而portlet要实现这两个参数的提供是非常简单的，所以实现单点登录也就非常简单了。我们可以复制一个check_login.jsp文件，例如check_portal_login.jsp,这个页面的两个参数是portlet提供的。剩下的事完全交给业务系统去处理，页面流转和全县控制都不用我们管了。  三、开发Portlet实现SSO的方法 1、JSP 取值传送URL法。 顾名思义，我们开发一个使用系统专用槽的portlet，使用凭证保险库相关接口在PortletView.jsp中取出用户存储在凭证保险库中的键值，然后以URL的方式传送到Iframe内。例如： PortletView.jsp中的部分代码： <% String userId =viewBean.getUserId(); String password=viewBean.getPassword(); if( userId.length()>0 ) String url = http:/hostname:8080/check_portal_login.jsp; url+=”?username="+userId+"&password="+password;  %> <Iframe src="<%=url%> " align="left" width=100% frameborder=no marginheight="2" scrolling="auto" marginwidth="2"  height=600></Iframe> 如果用户已经在凭证高先库中存储了键值的话，该portlet的view页面被初始化时，Iframe中将显示用户成功登录后的授权信息，也就是实现了SSO。 2、Class 取值写Session法。 顾名思义，我们在Portlet的控制类中取得用户存储在凭证保险库中的键值对，并在PortletView的doview()方法中写入Session 基于的是IBM 提供的一整套解决方案。 概念性的内容1.安全及单次登录(SSO)服务 使用IBM Tivoli Access Manager(TAM)作为系统的前置安全服务器，对所有访问其安全域内的应用系统提供统一的认证和单次登录(SSO)服务。2. 目录及用户服务 使用IBM Tivoli Directory Server(ITDS)作为企业级的目录服务器。LDAP目录服务器为应用系统提供和组织的基本信息查询、用户认证等服务。3. 门户展现服务 使用IBM WebSphere Portal Server(WPS)作为企业级门户Portal服务器。WPS为应用提供了统一的门户界面展现和内容聚集的服务。SSO（Single Sign-On）直译为一次登录，用户只使用一个用户名和口令，就可以访问所有的资源，这对系统管理和维护来说是非常重要的。单点登录有效地解决了用户使用网络时的多帐号、多密码、多次登录问题，方便了用户。 SSO理论基础SSO并不是J2EE（或.Net）中的标准实现，而是各家中间件提供商在提供J2EE（或.Net）应用服务器时提供的一种认证信息共享的机制，所以各家厂商提供的实现方式不一样, 在这些系统中，其实现方法方向分为两种: 一种是建立在PKI，Kerbose和用户名/口令存储的基础上,一种是建立在cookie或session的基础上。IBM的WebSphere是通过cookies记录认证信息，BEA的WebLogic通过session共享技术实现认证信息的共享，国内深圳金蝶的apusic采用的和BEA的技术基本一致。在这两种方式中，各有不足，前者需要安装专门的客户端，因而面向的用户对象是有限的，而后者授权方式只能方便地支持本产品系列的应用，而对第三方的认证和权限系统不能很方便的集成。SSO的前提条件1、所有应用系统共享一个身份认证系统所有服务器必须共享用户注册表（用户数据库），用户注册表可以是LDAP数据库，也可以采用用户自己实现的用户注册表。要注意的是在某些情况下是不能使用自己实现的用户注册表的，例如，Domino不支持用户自己实现的用户注册表，所以WebSphere和Domino之间实现SSO时只能采用LDAP数据库作为公有的用户注册表。统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（token），返还给用户。另外，认证系统还应该对token进行效验，判断其有效性。2、所有应用系统能够识别和提取token信息要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对token进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。3、单一的用户信息数据库并不是必须的有许多系统不能将所有的用户信息都集中存储，应该允许用户信息放置在不同的存储中。事实上，只要统一认证系统，统一token的产生和效验，无论用户信息存储在什么地方，都能实现单点登录。4、统一的认证系统并不是说只有单个的认证服务器认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别的单点登录。如：当用户在访问应用系统1时，由第一个认证服务器进行认证后，得到由此服务器产生的token。当他访问应用系统2的时候，认证服务器2能够识别此token是由第一个服务器产生的，通过认证服务器之间标准的通讯协议（例如SAML）来交换认证信息，仍然能够完成SSO的功能。5、对应用系统的修改不可避免并不是任何系统都能够使用SSO，只有那些符合SSO规范，使用SSO API的应用系统才具有SSO的功能。简单地说就是要修改已有的应用系统（在本项目中，已有的业务系统要实现单点登录，如果步具备相应的条件，则必须进行修改），屏蔽已有的应用系统的用户认证模块，使用系统提供的SSO API来验证用户，以及对用户的操作进行授权。实现单点登录的两种方式SSO都要有一个单一的登录点，由此登录点将创建的会话（认证标志）token传递给应用系统。SSO需要建立一个统一的认证、权限信息库。根据认证、授权实现的位置可以分为两种实现方式：1、Agent的方式即在后端为每个Web应用系统（或者其他系统）都安装一个Agent，由Agent来接管该系统的身份验证和访问控制，目录服务器中会存放自己的用户信息，以及这些用户与其他系统的用户对应信息。这些Agent能够通过配置，轻松的接管了后面的系统的身份验证和访问控制。对于不同的系统，Agent不同，这些Agent能够通过配置，轻松的接管后面系统的身份验证和访问控制。可以通过一个统一的LDAP，存放企业内部的用户信息，然后通过策略服务器，控制后端所有系统的URL访问权限，这样也实现了单点登录。使用这种方式，其安全性较高，用户信息都保存在各系统中，但是这种方式需要在各个系统中都安装Agent，降低了系统的灵活性。2、Proxy的方式即具有一个Proxy Server，由它来接管对于后端系统的访问，提交请求和读取数据，然后再返回给调用者。同时调用者可以存放用户信息以及用户的对应关系。Proxy Server会通过存储的用户对应关系和用户名和密码，自动完成后端系统的登录，然后就象一个浏览器一样，提取数据，返回数据给后端系统。后台系统不用做任何修改，身份认证和访问控制仍然由各个系统自己管理。该方法的优点是：后端系统不用做任何改动。即便是没有Portal，其他系统还可以照常使用。缺点是：需要在策略服务器中存储用户名称和密码，密码会多处存放，同步困难；用户可以绕开Portal，直接访问后端系统。Proxy Server可能是单点故障。缺点解决：目前有密码同步产品；Proxy Server也大多支持集群。由以上两种方式可以看出，哪种方式的编程量都不是很大，大多可以通过配置来实现，而且功能也很强大，可以根据系统实际情况进行选择。基于Agent方式的单点登录实现流程在每个Web应用系统都安装一个Agent，由Agent来接管该系统的身份验证和访问控制的方式实现,如下图所示.图 基于Agent方式的单点登录实现过程1、用户访问应用系统。由登录点将SSO token（针对不同的C/S，B/S应用可能还需要传递用户名，口令）传递给应用系统，应用系统利用SSO token来进行用户已认证的验证。2、当用户试图通过浏览器存取受保护的应用资源时，系统提供安装在不同应用上的SSO Agent来截取用户对资源的请求，并检查请求是否存在会话标识符，即token。如果token不存在，即用户没有在自己的服务器登录，请求就被重定向，传递给单点登录服务器（使用重定向就可以处理各服务器跨域的情况）。在单点登录服务器上会话服务负责创建会话token，然后认证服务将提供登陆页面以验证用户。在用户身份验证之前，会话服务创建了会话token。token为随机产生的会话标识符，该标识符代表了一个确定用户的特定会话。创建会话token后，认证服务把token插入cookie中，在用户的浏览器中设定cookie。在token被设定的同时，该用户将会看到一个登陆页面。Cookie是由Web服务器创建的信息包，并传递给浏览器。Cookie 保存类似用户习惯等Web服务器产生的信息。它本身并不表明用户通过了认证。Cookie是特定于某个域的。在身份服务器的实现中，cookie由会话服务产生，并由认证服务设定。而且，身份服务器的cookie是会话cookie，存储在内存中。会话token由会话服务创建并插入Cookie。会话token利用安全随机数发生器产生，并包含系统服务器特有的会话信息。在存取受保护的资源之前，用户由认证服务验证，并创建SSO token。3、单点登录服务器检查到用户已经单点登录（如果用户没有单点登录则要求用户登录，登录标志存储为客户端浏览器的Cookie），找到该用户在相应应用系统上绑定的账号。这些认证信息就被发给认证提供者（authentication provider）（LDAP服务器，RADIUS服务器等）进行验证。4、一旦认证提供者成功验证了认证信息，用户就被认为是通过了认证。身份服务器会从用户的token中取出会话信息并将会话状态设为有效。单点登录服务器根据生成的用户token，重定向回应用系统。此后，用户就可以访问这些受保护的资源。5、应用系统接收统一格式的用户token，取得用户在本系统上的登录账号，将用户在本系统上状态置为登录，返回用户请求访问的页面。如果用户在访问应用系统之前已经在单点登录服务器上登录过，第二步到第四布对用户来说就是透明的，用户感觉只是向应用系统发出了访问请求，然后得到了页面反馈。基于Proxy方式的单点登录实现流程基于proxy的实现方案如novel iChain的实现。这种方案需要通过DNS将多个系统的域名配置在一个承担SSO的Proxy上。当用户输入系统地址打开页面时，会首先链接到这个Proxy，再由Proxy转发到实际系统。原有系统因为用户没有登录，那么会返回登录页面，这时候iChain会截获这个登录页面，用自己的登录页面代替。用户在iChain提供的页面中输入用户名和密码，随后iChain根据LDAP（Novel的LDAP可以说是这行的老大了）中的信息查询出原有系统的用户名和密码，通过一次Http Post将用