评论：
在 IBM Bluemix 云平台上开发并部署您的下一个应用。
现在就开始免费试用
概述
企业信息门户作为企业内部门户基础平台，一大主要用途是实现现有的业务系统、数据资源、人力资源的整合，实现信息（数据）的合理聚集；通过实现统一的用户和统一的访问入口来访问门户平台中整合的相关信息资源，真正实现资源的有效利用，更大发挥企业现有资源的使用价值，提高生产效率。
门户应用集成技术作为关键性的技术手段，实现门户网站与业务系统之间单点登陆，以及内容聚集。本文档通过归纳总结，将企业应用集成中可以使用的技术做出相应阐述，为实现门户与业务系统集成提供技术参考。
本文将结合实际情况，分析企业应用中，常用的集成技术的核心环节，以及每项技术适用范围。本文档提供技术性的参考，实际工作中将需要结合具体情况选择最适合的集成技术来解决实际的问题，技术在日益更新，文档也将实时将最新的集成技术归纳总结。文章并不涉及具体编码、配置的实现细节，只针对相关的集成技术做阐述，具体实现应当专注于具体的技术环节，同时根据环境与实际需求来做相应的调整。
回页首
名词解释
门户
这里专指利用门户产品构建的各种门户系统，包括 B2E 门户、B2C 门户、B2B 门户。
单点登录
用户仅需要在门户系统登录一次，就可以访问被授权访问的栏目或者其他应用，用户只需要记住一个帐号即可。通过提供安全登录访问和集中管理应用软件和数据的信息框架，实现用户只需登录一次，即可获得授权范围内所有企业应用程序的访问权。
portlet
Portlet 是特殊类型的 Web 模块，它们被设计成在门户网站的环境中运行，是独立地开发、部署、管理和显示小门户网站的应用程序。Portlet 不仅仅是现有 Web 内容的简单视图。portlet 是完整的应用程序，遵循标准模型－视图－控制器设计。Portlet 有多个状态和查看方式以及事件和消息传递能力。同时 Portlet 是可再用的 Web 模块，它们在门户网站服务器上运行并提供对基于 Web 的内容、应用程序和其他资源访问。
WSRP
通过定义一组公共接口，WSRP 允许门户在它们的页面中显示远程运行的 portlet，而不需要门户开发人员进行任何编程 , 使面向呈现的 portlet 应用程序可以被发现并重用而不用任何额外的开发和部署活动。
回页首
集成的基础统一用户目录
在门户集成项目实施中，首先要考虑的是用户目录的因素。用户目录是用于存储用户身份信息，可利用以下几种方式实现：基于 LDAP 协议，符合 X500 标准的用户目录服务产品；
定制用户注册表接口（如：基于关系型数据库系统实现、基于本地用户系统实现）；统一用户目录可以分为物理的统一和逻辑的统一。
物理统一用户目录
物理统一用户目录是要求门户与待集成的业务系统使用统一的用户目录注册表，物理统一的用户目录不仅仅包含有用户基本信息，同时包含相关的业务系统资源信息，与业务系统相关的账户信息。
为了保证可用性，统一用户目录一般分为中央目录服务器及分支目录服务器，门户系统试用中央目录服务器作为用户存储，各业务系统，可以试用中央目录服务器也可以试用分支目录服务器。
中央目录服务器和分支目录服务器通过目录复制技术进行数据同步，如可实现全局复制，也可以实现选择性复制。如图 1。
图 1. 物理统一用户目录
逻辑统一用户目录
一般情况下，由于历史遗留问题以及企业要求等各方面的原因，实现物理统一用户目录的情形不多，更多的是采用逻辑统一用户的方式。逻辑统一用户是指门户与待集成的业务系统不使用唯一的用户注册表，门户信息系统使用单独的用户信息，业务系统使用另外一套自己的用户注册表。建立逻辑统一的用户目录，必须建立门户用户目录与业务系统用户目录之间的联系，实现门户用户与业务系统用户之间映射技术主要包括：
Credential Vault （凭证保险库）
Credential Vault （凭证保险库）是由 WebSphere Portal 提供一项目服务，帮助 portlet 和门户网站用户来管理多个标识。凭证服务包含处理基本认证、LTPA 令牌认证和简单基于表单的用户标识／密码登录提问的对象。如图 2
图 2. 凭证保险库
GSO-Lockbox
利用 GSO-Lockbox，可以建立起一个用户身份信息和后台应用系统之间的对应关系。这需要依赖于门户应用（portlet 应用或 J2EE 应用）来维护这样的关系映射表（包含门户用户与业务系统帐户之间的关系）。
门户用户与待集成业务系统之间映射关系完成之后，可根据业务系统认证方式来选择实现单点登录。
用户目录信息同步
用户关系映射表建立后，需要随时可以对这种映射关系进行维护，通过定期强制密码更新策略让每一个用户维护自己业务系统的用户、密码是一种选择。更常见的选择是通过管理员进行统一的账户管理和密码的同步推送，这项需求可通过开发完成，或者借助于成熟的企业级安全产品，例如 TIM/TDI。如图 3 所示，利用 TIM/TDI 实现门户目录与应用系统直接用户目录统一管理和用户信息的同步及清理。
图 3. 试用 TIM/TDI 实现目录统一管理和信息同步
回页首
统一认证与单点登录
认证意味着用户标识自己以获取对系统的访问权。IBM WebSphere Portal 支持以下几种方式的认证：
WebSphere Application Server 的基于定制表单认证机制，这是 IBM WebSphere Portal 缺省认证方式；
第三方认证（通过外部安全性管理器，如 Tivoli Access Manager 或者 CA SiteMinder），第三方认证提供者确定提问机制和认证方法；
安全套接字层（SSL）客户机认证。
用户在未标识自己的身份而尝试访问受保护的资源时，Portal（门户信息系统将提示用户提供认证凭证。
WebSphere Portal 还支持与其它的应用系统实现认证的统一，即支持其它标准的、非标准的认证方式来实现单点登录和应用集成以下其它系统的认证方式均为 WebSphere Portal 能够支持的：
Form 方式，用户名和密码、CA 认证 (X.509v3)、Token 认证、WAP 身份认证、资源敏感的认证或者自行开发的认证等方式
门户与业务系统实现 SSO
门户与业务系统实现 SSO（单点登陆），通过在门户使用 portlet 技术实现，为业务应用提供访问连接，当用户点击门户站点页面中的连接，或者直接访问门户页面中的某第三方系统的业务模块 Portlet 时，自动将登陆到需要访问的业务系统，而无需再次进行用户认证。
单点登录的实现从技术上可以从不同的维度着手，一般分为“客户端 Web 应用 SSO（Client-Web App SSO）”方式和“Portal 后台应用 SSO(Portal-Back End SSO)”方式，每种方式均有相应的技术实现，如图 4 Portal 单点登录服务：
图 4. Portal 单点登录服务
在实际的项目中，常用的 SSO 的实现方式按照应用系统与 Portal Server 的交互程度分为三种。需要指出这些 SSO 的实现方式并没有优劣之分，不同的实现方式适应不同的应用环境。解决现实中遇到的不同问题。
真实单点登陆：
门户认证中心
利用门户系统建立统一的 SSO 认证中心，通过 SSO 中心认证后，应用系统利用 SSO API 同 Portal Server 通信，验证用户是否经过认证。新开发的应用系统大多使用这种 SSO 的实现方式。这种方式需要对应用系统的认证模块进行修改。多数情况下，使用信任关联拦截器（TAI）也是建立 SSO 认证中心的常见方式。
门户服务器实现了 Java 认证和授权服务（Java Authentication and Authorization Service（JAAS））体系结构。JAAS 提供了一种用来认证 subject 和提供细粒度访问控制的办法。JAAS 是标准 Java 安全性模型的一部分；它使应用程序不依赖于所使用的底层认证和授权机制。
JAAS 使用模块化的服务提供者接口来执行登录和注销操作。通过门户网站的 JAAS 登录模块建立的凭证包括 CORBA 凭证、用户和组专有名称、用户标识和密码以及 LTPA 令牌。在分布式 J2EE 环境中，portlet 可以使用 JAAS API 来访问启用了 JAAS 的后端应用程序。
认证中心的建立，可以利用 JAAS 安全模型实现，例如，通过实现 WebSphere 自带的 LTPA 令牌技术来实现门户及各应用系统的认证统一，利用 Portal 建立公共的 SSOToken 实现认证统一。也可以通过一些开源的认证模块来实现，如 CAS、OpenSSO 等。
LTPA
另外，IBM 的产品体系中，大部分产品已经可以通过配置的方式实现真实单点登录。如：IBM WebSphere Base 产品（例如 IBM Connections、Quickr、ECM 等）、IBM WebSphere Portal、IBM Lotus Domino Server 之间的用户身份认证和单点登录。IBM WebSphere Portal 与 IBM Domino 提供基于 cookie 的轻量级第三方认证机制（LTPA）。当 LTPA 机制用于由多个服务器组成的环境中时，它是通过使用 Domain Cookie 而启用的。这种经过加密的会话 cookie 被放置在用户浏览器中，并包含了一些信息，WebSphere 或者 Domino Application 服务器可以加密这些信息，并使用这些信息来说明用户已经通过该 cookie 所覆盖的 DNS（Domain Naming Service，域名服务）域中的认证。
伪单点登陆
通过 WebSphere Portal 认证或者 SSO 中心认证后，应用系统还要自己进行用户的认证。这种方式适用于那些无法修改认证模块的应用系统。这种情况可以利用应用系统比较基础的接口来实现，如 URL+User+Password、Form 表单代填等。主要有以下几种技术选择：
利用 WebSphere Portal 凭证库认证模块
portlet 通过获得一个 CredentialVaultPortletService 对象并调用它的 getCredential 方法来获得凭证。对于所返回的凭证，有两种选择：
使用来自被动凭证（passive credential）的密码或密钥，用特定于应用程序的调用来传送这些密码或密钥。使用被动凭证的 portlet 需要从凭证中提取出加密信息并与后端应用程序进行所有认证通信。
调用主动凭证（active credential）的认证方法。主动凭证对象向 portlet 隐藏了凭证的加密信息，没有任何办法可以从凭证中提取出这些信息。主动凭证提供另外的方法来执行认证。
后一种情况允许 portlet 通过基本认证、SSL 客户机认证、摘要认证或者 LTPA 来触发远程服务器的认证，而不必知道凭证值。使用主动凭证意味着门户网站代表 portlet 进行认证，而且这个 portlet 可以只使用开放连接。尽管这可能并不适合于所有情况，但它却是您应该首选的技术。
基于 Form 方式
这种方式是通过模拟用户凭证提交，将业务系统相关的用户凭证通过 Form 提交的方式，传递给业务系统认证模块。
这种方式适合待集成的业务系统认证方式采用 From 表单，当通过 portlet 技术封装 Form 表单包含有业务系统相关的用户凭证，以及资源 URL。通过将业务系统所需的用户凭证通过 Form（表单）提交方式，模拟用户登陆，业务系统将用户所需的资源通过 web 方式反馈用户。
适用于基于 B/S 的 Web 业务应用系统，并且用户认证方式提供 Form 表单认证服务功能。
URL
将用户凭证直接通过 URL 的方式发送给业务系统，业务系统的认证程序将截获的用户请求 URL 中获取用户凭证，从而实现门户与业务系统的单点登陆。或者将用户凭证存储在 HTTP 请求报头，业务系统认证程序通过解析 HTTP 请求头信息，获取用户凭证。
模拟会话
利用 WebSphere Portal 以及应用系统的接口，模拟应用系统的认证状态。
模拟证书
实现单点登陆的业务系统用户认证方式并不是基于 Form，也不是采用 HTTP Header。需要客户端（此是门户信息系统将被作为客户端，业务系统将作为服务器）提供客户电子证书，这需要通过 portlet 应用程序，或 J2EE 应用程序来实现模拟将电子证书发送给业务系统认证模块。
整合第三方软件的单点登陆
使用信任关联拦截器（TAI）的第三方认证。如 Tivoli Access Manager，CA SiteMinder 等。门户通过使用第三方认证服务器作为外部安全管理器单点登陆。通过定义访问控制规则，由第三方认证服务器来实现用户登陆业务系统的认证功能，将大大简化集成带来的烦琐工作。
通常第三方认证服务器（如 Tivoli Access Manager、WebSeal 或者 CA SiteMinder）会提供默认的验证机制采用内置共享库的形式支持通过用户名和密码客户方证书 RSA SecurID 令牌或 HTTP header( 报头 )。选择性将会更多，便于用户根据实际软件需求配置所需的方式。
认证方式包括
- Forms-based login
- HTTP basic authentication
- Digital Certificate (X.509v3)
- RSA SecurID Token
- WAP identity mechanism
- Resource-sensitive authentication
- Kerborse
还可以支持 Credentials Acquisition Service (CAS)，从而实现外挂的用户认证方式，如：
- 数据库的认证方式，如 Oracle，DB/2
- 其它 security tokens (Vasco DigiPass)
- 用户定义的认证方式，如使用用户访问代码 PIN 和 Code
- RADIUS
- Biometrics
回页首
利用门户实现企业应用集成
利用门户产品来实现企业应用集成，需要根据企业业务系统的现状，以及具体的业务需求，进行最合理的规划与设计。同时，还要兼顾企业的未来发展以及整体 IT 规划的考虑，企业应用集成包括的内容很复杂，涉及到结构、硬件、软件、数据、技术、接口以及流程等企业系统的各个层面。
页面前端集成展现（基于页面内容的集成）
iFrame Portlet
基于页面的集成整合可以通过 iFrame Portlet 的方式，这也是门户项目中常见的一种集成方式。IBM WebSphere Portal 提供 webPage Portlet 将待集成的业务系统页面实现与门户站点进行整合。
通过 iFrame Portlet 集成依赖于以下几种情况：
- 此方法只适合 B/S 的业务应用系统。
- 此种集成方式的前提是：门户系统和应用系统之间已经实现 SSO。由于应用系统的页面之间在门户页面中展现，故需要考虑 SSO 的自动实现。例如：
方式一：可以在用户登陆门户站点时，将登陆门户的业务系统账号统一保存在用户会话中。并且实现应用系统的认证环节，当通过 iFrame 方式实现页面集成时，通过将业务系统的用户凭证从用户会话提取，然后直接通过配置的 URL 展现即可。
方式二：对 Iframe Portlet 通过 Portlet 编程进行预处理，实现应用系统的认证。而不是在用户登陆 Portal 时加载。
- 业务系统界面需满足 VI 设计要求
为保证门户站点的整体风格，业务系统的展示页面将必须满足门户站点的 VI 设计要求。
- 需要应用系统提供具体的，可配置的 URL。
- 可选，为了更好的适应集成的需要，可能需要更改业务系统 URL 级接口或者修改认证模块。例如：业务系统修改认证模块，来满足集成的要求 ; 业务系统修改功能模块加入 URL 认证能力。
通过 iFrame Portlet 的方式进行集成，除了上述限制条件外，效果不一样会好。这主要是由于：
- 使用 Iframe 框架，可能会改变原有应用的 HTML 结构，导致某些脚本无法运行。
- 在一个页面中过多的潜入 IFrame，由于不同 IE 版本对于 IFrame 的处理能力各异，可能会出现不可预料的异常效果。
Web 应用聚合器 (Web Application Integrator)
Web Application Integrator 提供了一种方法，可轻松将现有 Web 应用嵌入 WebSphere 门户，从而带来更高的价值。该技术在感官上与传统的门户集成方式不同，传统的门户集成方式一般是把业务系统的局部或整体界面嵌入到门户页面中，而 Web 应用聚合器是指在业务系统的页面中嵌入门户的主题导航、显示风格等元素，以让业务系统的操作界面保持与门户系统一致。本方式可以使业务系统更多的利用门户的价值，并保持企业内所有系统具有一致的操作体验。Web 应用聚合器可通过以下方式实现：
- 在门户中创建一个标准的 Portal URL 页面，并将页面链接指定到需要集成的 Web 应用的页面。
- 使用 WebAppIntegrator portlet 为该 Web 应用页面生成一段 HTML 标记代码。