级别： 中级 Dmitriy Fot, 软件工程师, IBM
Martin Oberhofer, 软件工程师, IBM
2009 年 11 月 04 日 IBM® InfoSphere™ Master Data Management (MDM) Server 供了管理主数据的功能，它严重依赖于 Web 服务和 XML。IBM WebSphere® DataPower® SOA Appliances 提供了保护 Web 服务部署安全的功能。在本文中，了解如何利用 DataPower 的一些功能增强 MDM Server 的安全性。
目标
在阅读本文之后，您应该能够：
- 理解联合部署 InfoSphere MDM Server 和 DataPower SOA Appliances 以保护主数据解决方案的价值
- 能够使用 DataPower SOA Appliances 创建 Web Service Proxy 和安全策略
- 创建和部署示例场景，展示 DataPower 如何执行保护 MDM Server 的安全策略
先决条件
本文是为希望更多地了解保护 InfoSphere Master Data Management Server 部署的 IT 架构师和 IT 专家撰写的。具备下列经验有助于理解本文；不过它们不是必要的，因为本文提供所有帮助您理解的知识：
- J2EE 开发经验和技巧
- 熟悉 MDM Server Web 服务
- 熟悉 MDM 和安全性架构
- 熟悉 DataPower SOA Appliances
系统需求
本文的例子将运行在分布式环境中，该环境至少包含两个通过 TCP/IP 网络基础设施连接起来的系统：
- 驻留 MDM Server 开发环境的笔记本电脑应该具有：
- 2GB 以上的内存。
- 10GB 空闲磁盘空间。
- 可以安装 InfoSphere MDM Server V8.5 和 IBM Rational® Software Architect 7.0 的任意操作系统。本文的场景还适用于该产品的以前版本，但没有进行测试过。本文将使用一个 MDM Server 服务展示 DataPower SOA Appliance 如何保护对该服务的调用。
- WebSphere DataPower Integration Appliance XI50 是 DataPower SOA Appliance 家族的一个示例。这个场景还适用于 WebSphere DataPower XML Security Gateway XS40，但不适用于 WebSphere DataPower XML Accelerator XA35。
简介
本文分为 4 个主要部分：
本文的最后部分是 测试。
什么是主数据管理？
详细介绍主数据管理（MDM）超出了本文的范围。本文简要地介绍该主题，解释为何准备使用或已经部署 MDM 系统的公司应该保护它们的 MDM 环境。（要获得主数据管理的全面介绍，请参阅 参考资料）。
主数据是企业的核心数据，它表示企业最有价值、最关键的信息资产，比如客户、产品、帐户、合同和位置。例如，丢失客户信息通常会给公司的声誉带来严重的影响。主数据管理由以下几部分组成：
- 信息体系结构
- 技术（用于部署 MDM 解决方案的软件产品）
- 运营 MDM 解决方案的流程和数据治理，其中包括组织变更导致的企业范围水平数据治理委员会，如果没有预先建立的话
- 人员
因此，MDM 对企业而言不仅仅是技术问题；它还影响到许多其他方面。本文介绍与技术相关的几个关键概念。MDM 软件可以从 3 个关键维度进行描述：
- 主数据域，比如客户、供应商、产品、帐户、合同或位置，以及跨域关系，比如客户-产品关系或产品-供应商关系
- 使用方法：
- 协作方法的特征是处理主数据时参与工作流的人员来自不同部门或担任不同的工作角色；New Product Introduction (NPI) 流程就是一个典型的例子
- 运营方法的特征是以实时、请求-响应的方式与 MDM 系统交互；创建或更新客户信息就是一个典型的例子
- 分析方法的特征是在 MDM 系统中执行分析（例如，查找上一周增加的新客户的数量）或者从 Data Warehouses（例如，通过派生和聚合的方式洞察到可盈利客户）或 Identity Analytics（例如，发现隐藏的或不明显的关系以应对诈骗）
获得分析洞察力
- 为主数据客户提供不同价值和具有不同部署复杂性的实现风格包括：
- Registry Implementation Style
- Coexistence Implementation Style
- Transactional Hub Implementation Style
通过使用 MDM 解决方案，公司能够解决许多业务问题，比如错过销售机会、不精确的客户和产品收入报告、供应链效率低或不遵从法规。从技术角度看，公司能够解决主数据质量问题，比如许多点对点连接问题和系统与安全性之间的复杂性问题。
主数据管理和安全性
在企业中引入 MDM 导致一个矛盾。矛盾的一个方面是，使用高质量、受管理和集中化的系统，让企业能够全方位查看主数据实例，从而显著提升主数据的价值。不过，矛盾的另一个方面是，主数据面临的风险明显变大了。现在，攻击者（外部或内部）仅需入侵一个系统就可以访问所有主数据。如果没有引入 MDM 系统，攻击者必须入侵多个系统（大型企业拥有许多系统）才能访问所有主数据实体。这些主数据的质量比较低，因为整理过程还没有完成，比如标准化和删除重复内容。
通过适当的、良好定义的安全策略可以阻止增加的风险。好消息是使用集中化系统管理主数据（比如 MDM Server）时，有一个地方可以实施安全性，从而降低成本和复杂性。要保护 MDM Server 解决方案的安全，必须对某些区域应用适当的安全措施，如 图 1 所示：
图 1. MDM 解决方案中与安全性相关的区域的高级概图
功能性区域至少包括：
- 分隔网络的防火墙 —— 内部和外部（1）
- 身份验证 —— 从和主 LDAP 储存库（2）
- 授权 —— MDM Server on WebSphere Application Server（3a 和 3b）
- 谁有权限调用某个服务？
- 谁有权限读/写主数据记录的属性？
- 审计 —— ESB and MDM Server on WebSphere Application Server（4）
- 数据屏蔽（例如，在开发和测试中使用的主数据，如果法规需要这样做的话）；这没有显示在图 1 中
- 空闲时数据加密（例如，备份）—— 文件服务器（5）
在 Enterprise Master Data Management: An SOA Approach to Managing Core Information（IBM Press，2008 年）一书的第 4 章中可以找到 MDM 解决方案的安全性架构的全面讨论（见 参考资料）。MDM Server 的服务可以作为 Web 服务获取（除了其他协议之外，比如远程方法调用），它不仅包括交换的数据，还包括使用 XML 结构的 SOAP/HTTP 或 SOAP/HTTPS 进行调用的协议层。因此，安全措施需要充分地应付 XML 攻击。在较高级别上，至少有以下 4 种类型的 XML 威胁：
- 单个或多个消息的 XML 拒绝服务（XDoS），实施攻击的技术包括递归元素、megatag、强制性解析和 XML 流
- 非授权访问，实施攻击的技术包括目录攻击和伪造消息
- 日期完整性和数据机密性攻击，实施攻击的技术包括消息和数据篡改、XPath、XSLT 和 SQL 注入，或窃取消息
- 系统损害，实施攻击的技术包括破坏内存空间或 XML 病毒
（以上提到的技术并未涵盖这 4 种类型攻击使用的所有技术）。要了解这些攻击的细节，请查看文章 “Bill Hines: The (XML) threat is out there...”（developerWorks，2006 年 3 月）。
好消息是，您可以使用 DataPower Appliances 保护 MDM Server 免受大部分这些攻击，比如 WebSphere DataPower XML Security Gateway XS40，它也适用于本文讨论的场景。
InfoSphere Master Data Management Server
IBM InfoSphere Master Data Management Server 是一个全面的、先进的解决方案，它能够支持多个主数据领域、使用方法和实现风格，从而支持主数据管理的所有关键业务需求。MDM Server 在最高级别上由 4 个主要部分组成：
- MDM Server 本身，它是一个部署在 J2EE 应用程序服务器（比如 WebSphere Application Server）上的 J2EE 应用程序，利用 WebSphere Application Server 提供的水平和垂直集群功能实现扩展性和高可用性
- 用于实现持久化的关系数据库引擎，比如 IBM DB2®
on Linux®, UNIX®, and Windows® 或 DB2 on z/OS®
- 基于 Web 的 UI，用于执行管理和数据维护等任务
- 通过模型开发新服务或改进现有服务的 MDM Workbench，可以通过 Rational Software Architect 工具获得
MDM 应用程序是纯粹的 J2EE，它是根据 SOA 原则开发的，在最高级别上包含以下功能：
- 包含 800 个以上业务服务的 SOA 服务界面，支持通过多种技术调用业务服务，其中 Web Services、JMS、CICS 和 Remote Method Invocation (RMI) 是最典型的例子。
- 提供超过 800 个开箱即用业务服务的 MDM 解决方案，支持主数据上的简单和复杂业务流程，比如交叉销售和提升销售或 New Product Introduction。这个数据模型基于一个经过验证的、全面的数据模型之上；业务服务是开放的，很容易通过 MDM Workbench 进行扩展。
- 包含严格的数据完整性功能的 MDM 业务服务，比如内置的、执行主数据完整性规则的复制防止功能，因为必须通过维护保证主数据的质量。另外，由于开放和基于标准的架构，业务服务可以轻松使用来自综合信息集成平台（比如 IBM InfoSphere Information Server）的其他数据完整性功能。
- 支持基于事件的业务规则的业务服务（比如通知），因为主数据必须是可操作的，这样才能实现主数据的智能开发。来自银行业的一个可能的例子是，由于根据主数据的变更检查到某人需要结婚，因此该客户可能需要抵押贷款。
- 在服务和属性级别上启用身份验证的业务服务，支持主数据的私密性和安全性，因为它需要保护和治理。
- MDM 数据治理 —— 内置在 MDM 业务服务中的功能，它支持在服务和属性级别上启用身份验证，因此实现数据的私密性和安全性。
Understand
IBM InfoSphere MDM Server security 系列文章（developerWorks）介绍了 MDM Server 安全特性。在这篇文章中 ，您可以了解到 MDM Server 如何与 LDAP 提供者连接，从而在基础的安全性场景中实现身份验证，等等。
WebSphere DataPower SOA Appliances
WebSphere DataPower SOA Appliances 是一个产品家族，它包含：
- WebSphere DataPower XML Security Gateway XS40
- WebSphere DataPower Integration Appliance XI50
- WebSphere DataPower XML Accelerator XA35
- WebSphere DataPower B2B Appliance XB60
- WebSphere DataPower Low Latency Appliance XM70
这些产品是支持全面的 IBM SOA 策略的关键要素，尤其在 ESB 领域。它们表示专门的、易于部署的网络硬件设备，用于简化作为 SOA 实现的一部分的 XML 和 Web 服务部署，并保证其安全。XML 处理能够增加硬件的吞吐量和处理速度。
快速采用 SOA 时，将面临以下关键挑战：
- 可用性：支持 Web 服务的复杂中间件不容易维护，因为它们是相互依赖的。所以，要同时实现可用性和可维护性并不容易。
-
安全性：如前所述，Web 服务大量使用 XML，而目前存在大量针对 XML 的攻击。
-
性能：从计算角度看，处理用 XML 表示的数据比处理用原生数据类型表示的数据需要更多的开销。因此，将 XML 数据转换成 CPU 能够理解的原生数据类型需要占用处理时间。随着需要在系统之间处理和交换的数据不断增长，将需要更多的计算能力和更快的计算速度。
DataPower SOA Appliances 解决了这 3 个挑战，图 2 展示了一个典型的用例。一个典型的用例是使用 De-Militarized Zone (DMZ) 将外部和内部客户端与后台系统分离开来。作为 DMZ 的一部分（包括一个 Reverse Proxy），防火墙是必需的，它可以使用 DataPower XS40 设备实现。如果有一个提供基于 XML 界面的后端应用程序（比如 Web 服务），那么可以使用 DataPower XI 150。
图 2. 一个典型的 DataPower SOA Appliance 用例
从更高级别看，DataPower SOA Appliances 提供以下功能：
- 可以存放在机架上的网络设备
- XML/SOAP 防火墙特性和在属性级别上带有数据验证的 XML 安全性
- 完全控制对 XML Web 服务的访问，包括服务虚拟化
- 消息代理以及将重要事务网络连接到 SOA 和 ESB 的能力
- 通过硬件加速为基于 XML、XSLT 和 XPath 的转换和 XML 模式验证实现高性能、多步和快速消息处理
- 为集中的 Web 服务提供策略和服务级别的管理
- 完全支持许多 Web 服务标准，比如 SOAP、WSDL、UDDI、WS-Security、SAML、WS-Federation、WS-Trust、WS-SecureConversation、WS-Policy、WS-SecurityPolicy、WS-ReliableMessaging XKMS、Radius、XML Digital Signature 和 XML-Encryption
- 支持许多传输协议，比如 MQ、SSL、HTTP、HTTPS 和 FTP
- 以非常快的速度和很高的伸缩性执行多种格式的消息转换，支持的格式包括文本、二进制文件、平面文件、CICS、CORBA 或 EDI
要进一步了解 DataPower SOA Appliances 的功能以及如何使用它们，请查看 参考资料。
对 MDM Server 和 DataPower SOA Appliances 有了基础了解之后，我们总结一下 DataPower SOA Appliances 在什么地方能够帮助您保护基于 MDM Server 的 MDM 解决方案。首先，它能够阻止基于 XML 的攻击。其次，您可以在需要防火墙构建 DMZ 时部署它们。最后，它能够为 MDM 解决方案实现强大的身份验证、授权和审计工具。现在，我们通过具体的场景和实现深入探索它们。
示例场景
为了演示 MDM Server 如何能够利用 DataPower Appliances 提供的安全性服务，让我们配置一个 Web 服务代理组件，它将对进入的 MDM Web 服务请求实施身份验证和授权策略。通过该组件，您能够：
- 通过在 DataPower 中提供一流的身份验证和身份映射，支持在企业范围之外部署 MDM。
- 支持可信上下文，这是保护 MDM 服务的好方法。您可以使用 DataPower 限制特定应用程序对 MDM 服务的调用。目前，MDM 允许任何经过授权的内部应用程序调用来自 MDM Server 的身份明确的服务。
- 支持策略驱动的身份验证。DataPower 可以实施用标准语言编写（比如 eXtensible Access Control Markup Language）或由其他工具分发的（比如 IBM Tivoli Security Policy Manager）授权策略。
- 在 MDM Server 之前部署一个 XML 感知防火墙，以保护 MDM Server 免受 XML 攻击威胁，比如 XDoS、XML 流和递归 XML 元素。
图 3 展示了本文描述的场景的总体流程：
图 3. 本文使用的示例场景的概图
下面列出了本文示例场景的流程：
- 步骤 1：MDM Client Application 向在 DataPower 设备中配置的代理组件的 URL 发送一个 MDM Web 服务请求。作为请求的一部分，这个客户端应用程序发送打包在 WS-Security Username Token 中的用户 id 和密码。
- 步骤 2：DataPower 设备接收请求，从令牌中获取用户凭证，然后在一个外部的、遵从 LDAP 的目录服务器中验证请求者的身份。
- 步骤 3：DataPower 设备通过计算用 XACML 编写的访问控制策略，检查是否允许用户调用所请求的服务。
- 步骤 4：DataPower Appliance 将用户的 id 映射到 MDM Server 识别的身份。记住，现在 MDM Server 使用一个 J2EE 角色 ServiceConsumer 向它的所有服务提供简单的授权。当攻击者通过 ServiceConsumer 角色的身份验证之后，他就有可能以任何身份执行任意事务。为了消除这个漏洞，您可以对 MDM Client Application 隐藏实际的 MDM 身份，并且在 MDM Server 之外执行服务授权。
- 步骤 5：如果用户通过身份验证并被授权调用 MDM 服务，那么最后一步将由 DataPower Appliance 完成。它创建一个 LTPA (Lightweight Third-Party Authentication) 令牌并将其插入到原始的请求中，以作为一个有效的服务调用者通过 MDM Server 的身份验证。为了生成令牌，DataPower Appliances 使用在步骤 4 中创建的身份和部署目标 MDM Server 的 WebSphere Application Server 的加密密匙。
- 步骤 6：DataPower 将包含注入 LTPA 令牌的 MDM 请求发送到后台 MDM Server。
- 步骤 6'：如果用户没有包含在 LDAP 注册表中或没有获得授权调用请求的 MDM 服务，那么将向 MDM Client Application 发送表示拒绝访问的响应。
- 步骤 7：WebSphere Application Server 通过检验 LTPA 令牌验证 Web 服务调用。
- 步骤 8：MDM Server 执行请求并向 DataPower Appliances 返回响应。
- 步骤 9：DataPower Appliance 将响应传递回 MDM Client
Application。
 |
|
为 MDM Server Web 服务创建代理
要在本文使用的 WebSphere DataPower Integration Appliance XI50 中创建一个 Web 服务代理，必须通过两个步骤。首先，必须导入 MDM Web 服务描述；其次，必须配置代理。在接下来的两个小节中将详细描述这两个步骤。
导入 MDM Web 服务描述
|
查找 MDM Server 的 WSDL 和 XSD
MDM Party 服务的 WSDL 和 XSD 可以在 MDM Server 的 PartyWSEJB 模块中找到。如果 MDM Server 安装在 WebSphere Application Server 上，那么就可以使用 WebSphere Integrated Console 查找 Web 服务声明。您需要登录到控制台，然后选择以下菜单选项：Applications >
Enterprise Applications > MDMServer >
Publish WSDL files。
|
|
您需要创建的主要 DataPower 组件是 Web Service Proxy，它在将 MDM Web 服务请求发送到后台 MDM Server 之前处理它。但是在创建新的 Web Service Proxy 之前，您首先要让 DataPower Appliances 可以使用服务描述。MDM Server 将其 Web 服务描述分发到几个相互关联的 WSDL 和 XSD 文件中。本文将描述一个例子，它使用来自 MDM Server 的 Party 域的服务。因此，本文使用 Party 服务描述构建 Web Service Proxy。图 4 显示了加载到 DataPower Appliances 的所需的 WSDL XSD 文件：
- AccessDateValue.xsd
- Business.xsd
- BusinessIntf.xsd
- Common.wsdl
- Common.xsd
- CommonIntf.xsd
- Extensions.xsd
- Hierarchy.xsd
- Party.xsd
- PartyBinding.wsdl
- PartyBusiness.xsd
- PartyIntf.xsd
- PartyPort.wsdl
- PartyService.wsdl
图 4. 来自 MDM Server 并加载到 DataPower Appliances 的 WSDL 和 XSD 文件
创建代理
要使用 DataPower WebGUI 创建新的 Web Service Proxy，您必须：
- 作为有权限访问底层域的开发人员登录到 DataPower WebGUI。
- 单击 Web Service Proxy 图标，然后单击 Add 按钮添加一个新的 Web 服务代理，您可以随意命名它（本例使用的名称为 MDM8_WSProxy）。
- 使用代理选择希望保护的 MDM 服务的 WSDL 文件。在这个例子中，WSDL 文件是本地的：//PartyService.wsdl。在添加新的服务声明时，关闭 WS-Policy References；否则，将在创建代理时收到一条警告消息。
- 添加新的或使用现有的 HTTP Front Side Handler 定义应该对 MDM 服务请求使用哪个 DataPower 端口。在大部分情况下都使用 HTTP 调用 Web 服务。因此，您的处理程序必须能够接收使用 POST 发送的 HTTP1.1 请求。
- 指定后台 MDM Server 的主机名和端口号。
Web Service Proxy 的最初配置窗口最终类似于 图 5：
图 5. 新的 Web Service Proxy 的最初配置
为 MDM Server 构建安全策略
为了实现本文设立的安全性需求，您必须创建一个新的 Authentication, Authorization and Audit (AAA) Policy. AAA Policy 是用于实现安全性需求的强大、灵活的机制。本文的例子使用 AAA Policy 实现：
- 使用外部 LDAP 目录验证进入的 MDM 请求
- 基于来自请求头的用户凭证和调用的 MDM 服务授权请求，其中以 XACML 表示的策略用作进行授权决策的根据
- 将已授权用户的凭证映射到 MDM Server 使用的凭证
- 使用可以通过 MDM Server 验证的令牌替换请求中的安全令牌
通过使用在 DataPower 中配置的 Web Service 代理（如 图 6 所示），位于客户端调用 MDM 服务和 InfoSphere MDM Server 之间的 DataPower 可以实施身份验证或授权等策略。因此，当调用 MDM 服务时，DataPower 会在将调用路由到 MDM Server 之前实施正确的安全策略。
图 6. 在示例场景中使用的策略组件
要创建 AAA Policy，转到 DataPower 对象列表并找到 AAA
Policy。然后以任意名称添加一个新的策略（本文的例子使用的名称为 MDM8_AAAPolicy）。
身份验证
本文的示例场景使用 DataPower Appliance 对使用 LDAP 目录服务器的 MDM 请求执行身份验证。为了实现这一需求，您应该正确地配置用户身份的验证和授权。对于身份验证，您可以使用嵌入到 SOAP 消息的头部并由客户端应用程序发送的 WS-Security Username 令牌。客户端应用程序负责构建正确的 WS-Security Username 令牌并将其包含到 Web 服务调用中，Web 服务调用使用加密的通信通道（比如 SSL）保护密码。清单 1 显示了嵌入到 MDM Web 服务请求中的 WS-Security Username 令牌：
清单 1. 带有 WS-Security Username 令牌的 MDM Web 服务请求示例
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd">
<wsse:UsernameToken>
<wsse:Username>ivan</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
token-profile-1.0#PasswordText">secret</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
<p388:SearchPerson
xmlns:p388="http://www.ibm.com/xmlns/prod/websphere/wcc/party/port">
<control>
<requestId>1</requestId>
<requesterName>ivan</requesterName>
<requesterLanguage>100</requesterLanguage>
</control>
<personSearch>
<givenNameOne>%</givenNameOne>
<lastName>Carlos</lastName>
</personSearch>
</p388:SearchPerson>
</soapenv:Body>
</soapenv:Envelope>
|
为了确保 DataPower Appliances 接受这种类型的令牌，您应该在 AAA Policy 配置屏幕的 Identity 选项卡下选择 Password-carrying UsernameToken Element from
WS-Security Header 复选框。要支持基于 LDAP 身份验证，您需要在 AAA Policy 配置屏幕的 Authenticate 选项卡下选择 Bind to Specified LDAP Server 身份验证方法，如 图 7 所示。此外，还需要填充特定 LDAP 服务器的其他 LDAP 参数（Host、Port、LDAP DN Prefix、LDAP DB Suffix 和 LDAP Search 属性）。
图 7. 配置用于在 LDAP 目录服务器中执行身份验证的 AAA Policy
事务授权
这个小节描述如何配置 AAA Policy，DataPower 将通过它基于 MDM 服务名执行身份验证。该功能基本上与 MDM Server 提供的事务授权等效，请参见文章 “理解 IBM InfoSphere MDM Server 安全性，第 3 部分: 使用 LDAP 实现事务授权”（developerWorks，2008 年 11 月）。但有一个根本区别。本文展示的授权机制是基于策略的。这意味着可以在使用标准语言（比如 XACML）的策略中声明授权规则，然后将其分发到 DataPower Appliances 进行实施。可以手动地将策略创建为一个或几个 XML 文档，或使用专门的策略管理软件（比如 IBM Tivoli® Security Policy Manager）创建策略。使用软件创建策略时，策略管理和实施都可以从 MDM Server 操作。
|
IBM Tivoli Security Policy Manager
IBM Tivoli Security Policy Manager 是一款用于集中管理安全策略的比较新的 IBM 产品。Tivoli Security Policy Manager 允许策略创建者创建访问控制策略并将其附加到特定的服务。然后，Tivoli Security Policy Manager 将策略分发到可以实施它们的目标。Tivoli Security Policy Manager 支持 DataPower Appliances 作为分发目标。
|
|
用于 MDM 事务授权的 XACML 策略
为了实现基于 XACML 的授权，您必须先编写一个策略。XACML 是一个灵活的标准，并且允许策略创建者构建复杂的访问控制策略。但在这个场景中，您没有必要利用 XACML 的所有功能，而是构建一个非常简单的策略。除了用于声明访问控制策略的方式和格式之外，您还需识别两件事情：
在本文的例子中，访问控制主体就是调用 MDM 服务的用户，这毫不奇怪。本例将被调用的 MDM 服务定义为资源（等效于 MDM 事务 —— 这就是为何它被称为事务授权）。在这个例子中，我们定义了一个简单的策略，它为用户 dmitriy 和 ivan 提供两种不同的访问级别（参见 下载 小节中的 resources.zip 文件中的 MDM8-tx-policy.xml）。根据策略，用户 ivan 可以调用任何事务，而用户 dmitriy 仅能调用以下事务之一：SearchPerson、GetPerson、AddPerson 和 UpdatePerson。为了使用 DataPower Appliances 实施该策略，您需要将策略文件上传到应用程序，然后创建一个 XACML Policy Decision Point (PDP) 组件，它将使用策略文件计算访问控制决策。
创建 XACML Policy Decision Point
为了使用 DataPower 的 WebGUI 创建一个 XACML PDP，您需要在 DataPower 对象列表中找到 XACML Policy Decision Point。在配置 PDP 时，要确保它拥有一个唯一的名称（在本例中为 MDM8_TX_PDP），并使用您刚才创建的策略文件。图 8 展示了一个 XACML PDP 配置的例子：
图 8. 配置 XACML Policy Decision Point
在 AAA Policy 中的授权
创建了 XACML PDP 之后，您需要配置 AAA Policy 以在授权时使用它。为此，您需要完成以下步骤：
- 在 AAA Policy 配置屏幕的 Resource 选项卡上选择 Local Name of Request Element。这样就声明了 DataPower Appliances 必须使用 MDM 服务的名称作为资源授权。
- 在 AAA Policy 配置屏幕的 Authorize 选项卡上选择 Use XACML Authorization decision 作为授权方法。此外，还需要选择在 Policy Decision Points 列表中最新创建的 XACML PDP。
SOAP 到 XACML 转换
最后，您需要定义 Web 服务请求如何转换成 XACML 请求。XACML 标准（见 参考资料 获得详细信息）要求根据 XACML 请求和响应模式定义所有授权请求。否则，XACML 引擎（在本例中嵌入到 DataPower）将不知道如何计算请求。因此，您需要定义一个 XSLT 样式表来将进入的 SOAP 包转换成 XACML 请求。在这个例子中，在一个称为 MDM8-soap-to-xacml.xsl 的文件（见 下载 小节的 resources.zip 文件中的 MDM8-soap-to-xacml.xsl）中声明该样式表。它的实现非常简单，并且很容易重用。这个样式表比较有趣的细节是，它使用一些由 DataPower XSLT 扩展提供的变量。
清单 2. 用于将 SOAP 包转换成 DataPower 扩展变量的 XSLT 代码片段
<Subject>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>
<xsl:value-of select="dp:variable('var://context/WSM/identity/username')" />
</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>
<xsl:value-of select="dp:variable
('var://context/WSM/resource/extracted-resource')"/>
</AttributeValue>
</Attribute>
</Resource>
|
例如，在 清单 2 给出的 XSLT 代码片段中，如果应用到 清单 1 中的 MDM 请求将生成 清单 3 中的 XACML 请求：
清单 3. XACML 请求的代码片段，基于清单 2 提供的 XSLT转换
<Subject>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>dmitriy</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>SearchPerson</AttributeValue>
</Attribute>
</Resource>
|
当 XACML PDP 遇到类似于清单 3 中的请求时，它将对其应用底层策略并返回一个响应，该响应简单回答是否允许访问。如果访问被拒绝，那么 DataPower Appliance 就向 MDM Client Application 发送访问被拒绝的响应，而让 MDM 保持不变。将 AAA Policy 指向转换样式表是实现事务授权的最后配置步骤，如 图 9 所示。选择并配置参数，比如 XACML 版本和转换脚本的位置等。
图 9. 在 AAA Policy 中配置的事务授权
在后台 MDM Server 上的身份验证
本场景的最后一个步骤是在后台 MDM Server 上的身份验证。本文的目标之一是演示 MDM Server 安全性可以完全在外部提供者（比如 DataPower）中实现。我们的 DataPower 配置关注用户身份验证和基于策略的用户请求授权。但是即使是在这个场景中，MDM Server 仍然需要特定级别的安全。您至少需要确保 MDM Server 与正确的 安全提供者交流。换句话说，您需要在 MDM Server 上验证 DataPower Appliances 的身份。为此，您必须完成以下步骤：
- 选择身份验证机制。由于 MDM Server 是一个 J2EE 应用程序，所以它能够利用底层 J2EE Application Server 基础设施的身份验证功能。本文的场景使用 WebSphere Application Server 和 IBM Lightweight Third-Party Authentication (LTPA) 机制。
- 在 MDM Server 上配置身份验证需求。部署 MDM Server 时必须进行某些更改，以确保它理解 LTPA 身份验证（见 LTPA 侧栏）。
- 将进入 DataPower Appliances 的请求的身份映射到 MDM Server 期望的身份。身份映射不是必要的，但如果用户和服务授权发生在服务提供商范围之外，通常建议使用它。它允许将后台服务器使用的身份与客户端应用程序分离，这可以增强安全性。
- 根据 MDM Server 所需的身份验证机制配置 DataPower Appliances。对于 LTPA 和 Web 服务，您需要确保 DataPower Appliances 生成正确的 LTPA 令牌，并在将令牌发送到后台 MDM Server 之前把它们插入到服务请求中。
在 MDM Server 和 WebSphere 中的基于 LTPA 的身份验证
|
Lightweight Third-Party Authentication
Lightweight Third-Party Authentication (LTPA) 是 WebSphere Application Server 安全中的一种身份验证机制，它定义特定的令牌格式。当您对 Web Services 使用 LTPA 方法时，将生成 <wise:BinarySecurityToken> 安全令牌。
|
|
为了确保 MDM Server 接受并验证 LTPA 令牌，必须对 MDM Server 部署进行一些更改。这些更改可以在部署 MDM Server 之前或之后进行。文章 “IBM WebSphere 开发者技术期刊: 通过 WebSphere Application Server V6 实现 Web 服务安全，第 4 部分：使用 LTPA 令牌”（developerWorks，2006 年 7 月）描述了如何配置部署在 WebSphere Application Service 上的Web 服务，以使用 LTPA 令牌。对于 MDM Server，配置过程是一样的。在本文的例子中，我们仅为 MDM PartyServices 更改部署描述符（见 下载 小节的 resources.zip 文件中的 WebSphere 绑定文件 ibm-webservices-ext.xmi 和 ibm-webservices-bnd.xmi）。
LTPA 身份验证的另一个方面是加密密匙共享。本文的例子想让 DataPower Appliances 生成正确的 LTPA 令牌，并且仅当设备和 WebSphere Application Server 共享一组加密密匙才有可能。为了确保成功，我们从应用程序服务器导出密匙，然后再将其上传到 DataPower Appliances 中。要从 WebSphere Application Server 6.1 导出 LTPA 密匙，您可以查看 WebSphere Application Server Information Center 的 “Exporting Lightweight Third Party Authentication keys” 部分提供的说明（见 参考资料）。在密匙导出之后，可以像其他文件一样上传到 DataPower Appliances。
身份映射
如前所述，身份映射给该场景添加了一个额外的安全层。当客户端应用程序和后台服务器使用不同的身份集，并且仅有中间安全组件或 ESB 知道如何在彼此之间映射时，客户端上的恶意用户就很难绕过中间组件并威胁后台服务器。
在 DataPower Appliances 上实现身份映射的唯一方法是创建一个 AAA 信息文件，并将其附加到 AAA Policy。AAA 信息文件是一个包含 AAA Policy 配置的不同方面的 XML 文档。开发人员不需要知道该文件的格式，因为可以使用 DataPower WebGUI 进行所有更改。本文的例子使用 AAA 信息文件定义身份映射规则。为了创建一个 AAA 信息文件，需要转到 AAA Policy 配置屏幕的 MapCredentials 选项卡，然后选择 AAA Info File 作为映射方法。然后单击 +（添加）按钮，并通过一系列屏幕设置 AAA Policy 的不同方面。AAA 信息文件不仅可用于身份映射，还可以用于身份验证和授权。本文的例子不需要它们。本文唯一需要的配置是声明进入的身份（见 图 10），以及如何映射它们（见 图 11）。注意，我们使用 IBM WebSphere Application Server 使用的身份作为映射目标，它将被加密到 LTPA 令牌中。本文的 下载 小节附带了该场景使用的一个示例 AAA Info File（见 resources.zip 文件中的 MDM8_AAAInfoFile.xml）。
图 10. 在 AAA 信息文件中的身份声明
图 11. 在 AAA 信息文件中的身份声明
生成 LTPA 令牌
在配置好身份映射并且 MDM Server 可以使用 LTPA 令牌之后，还有最后一个步骤需要完成，即配置 DataPower Appliances 以生成 LTPA 令牌，并将令牌插入到所有进入的 MDM Web 服务调用中。这可以在 AAA Policy 配置屏幕的 PostProcessing 选项卡完成，如 图 12 所示。为此，您需要执行以下步骤：
- 对 Generate LTPA Token 选择 on。
- 对于 LTPA Token 版本，选择 WebSphere version 2 for IBM WebSphere Application Server 6.1 或更新版本。
- 指定 LTPA 密匙文件，它已经从 WebSphere Application Server 导出。
- 输入 LTPA 密码，该密码必须与从 WebSphere Application Server 导出密匙使用的密码一样。
- 对 Wrap Token in a WS-Security Security Header 选择 on。如果该选项为 on，DataPower 将把 LTPA 令牌打包到 WS-Security BinarySecurity Token，并将其插入到一个 Web 服务请求中。在本例的场景中，这个选项十分重要。由于更改了 MDM Server 配置，所以它仅接受嵌入了 LTPA 令牌的请求。
图 12. 在 AAA Policy 中配置 LTPA 令牌生成
将安全策略附加到代理组件
|
AAA Policy
AAA Policy 还可以通过 Web Service Proxy 配置屏幕的 Proxy Settings 选项卡上的选择列表添加到 Web Service Proxy。但在撰写本文时，这个配置选项还没有完全可用。该选项应该出现在 DataPower 固件的下一个发布版中。
|
|
在创建了 AAA Policy 之后，就可以将它添加到一个或多个 Service Proxy 组件中。为此，转到 Web Service Proxy 配置屏幕，并将一个新的 AAA Action 拖放到代理的请求规则中。可以在代理配置屏幕的 Policy 选项卡上找到请求规则配置，如 图 13 所示。根据该配置，DataPower Appliances 将对所有进入的 Web 服务请求实施 AAA Policy。
图 13. 附加到 Web Service Proxy 的 AAA Policy
测试运行
为了演示示例解决方案的安全性功能，我们将执行几个 MDM Web 服务调用，并分析得出的结果。我们首先看看 清单 1 中的请求。如您所见，这个请求包含用户 ivan 的用户凭证。清单 4 显示了临时的 SOAP 包，它是由 DataPower Appliances 在实施安全策略之后，在将安全策略发送到 MDM Server 之前构建的。您可以看到，它包含的是嵌入的 LTPA 令牌，而不是原始的 Username 令牌。
清单 4. 由 DataPower Appliances 修改并发送到 MDM Server 的 SOAP 包
<soapenv:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:BinarySecurityToken
wsu:Id="SecurityToken-ff960367-3c49-4913-b0a7-9f8358943297"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-
message-security-1.0#Base64Binary"
ValueType="wsst:LTPA"
xmlns:wsst="http://www.ibm.com/websphere/appserver/tokentype/5.0.2"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd">
Ac1aDJ17IJSJ5aaaG390MM6Ys9eOzxiVmaXDVA5pe3qV89602u3Ssmraa3oykgNzHhvEOZa2GHbRMj2
K3RJWLuD8KB3eH1s8uMLfvNo9hS4Yj9hFKzC8oi1vzTdEwhwMcde6VXXXH+SsZJ4p0YpEKClg7rcukb
feJ+/cOjfZNkcWwCNtj9TginFPWx5iwDBRZ8fmX+8LHd3ZEepS8U1+WZ2CpYqNDYZr+6h19lINyDvBj
hiOStn6bKbAf+u/mHJ7Yd2ISoZHfXnyQ2Nr60FcWuv7uvbc+g5JJ9ZjQhFqLtWcyd4/5ehRoOIXA3tT
x1Vc/7ajy11SKwwaNrOzsNtyEl2qoOglAeTDYR8LZgjW7WSln+kwdM+ZN3jrfgC0FClw
</wsse:BinarySecurityToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
<p388:SearchPerson
xmlns:p388="http://www.ibm.com/xmlns/prod/websphere/wcc/party/port">
<control>
<requestId>1</requestId>
<requesterName>ivan</requesterName>
<requesterLanguage>100</requesterLanguage>
</control>
<personSearch>
<givenNameOne>%</givenNameOne>
<lastName>Carlos</lastName>
</personSearch>
</p388:SearchPerson>
</soapenv:Body>
</soapenv:Envelope>
|
清单 5 显示了执行这个 MDM 请求的最终结果：
清单 5. 成功执行 MDM 事务之后的 MDM Web 服务响应
<
<soapenv:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header />
<soapenv:Body>
<p388:SearchPersonResponse
xmlns:p388="http://www.ibm.com/xmlns/prod/websphere/wcc/party/port">
<result>
<control>
<requestId>1</requestId>
<requesterName>ivan</requesterName>
<requesterLanguage>100</requesterLanguage>
<requesterLocale>en</requesterLocale>
</control>
<serviceTime>P0Y0M0DT0H0M7.203S</serviceTime>
<status>
<processingStatus code="0">SUCCESS</processingStatus>
</status>
<searchResult>...</searchResult>
<searchResult>...</searchResult>
</result>
</p388:SearchPersonResponse>
</soapenv:Body>
</soapenv:Envelope>
|
为了达到实验的目的，让我们将原始请求中的 Username 令牌更改为 清单 6 所示的令牌（用户 miguel 没有获得授权通过我们的 XACML 策略调用任何事务）：
清单 6. 带有新的身份的 Username 令牌
<wsse:UsernameToken>
<wsse:Username>miguel</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
token-profile-1.0#PasswordText">secret</wsse:Password>
</wsse:UsernameToken>
|
您将收到一个失败响应，如 清单 7 所示，这意味着授权策略已经成功实施：
清单 7. 在实施访问控制策略之后来自 DataPower Appliances 的失败响应
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body>
<env:Fault>
<faultcode>env:Client</faultcode>
<faultstring>Rejected by policy. (from client)</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
|
结束语
本文展示了如何使用和配置 DataPower SOA Appliance 来保护管理核心业务实体（SOA 环境中的主数据）的 MDM Server。通过使用前沿的 DataPower SOA Appliance，您可以轻松保护 MDM Server 部署，以及正确、一致地应用身份验证、授权和审计策略。
致谢
作者对同事兼导师 Ivan Milman 为本文提供建议和反馈表示感谢！
下载 | 描述 | 名字 | 大小 | 下载方法 |
|---|
| 本文样例文件 | resources.zip | 4KB | HTTP |
|---|
参考资料 学习
获得产品和技术
讨论
作者简介 | 
| | Dmitriy Fot 是德克萨斯州奥斯丁市 Advanced Architecture for Information Management 部门的软件工程师。自从加入德国 IBM Boeblingen Lab 的 Center of Excellence for MDM 团队之后，Dmitriy 一直从事 Master Data Management 领域的工作。他的经验包括涉及 MDM Server 和其他 IBM 或非 IBM 系统的许多集成项目。在加入 IBM Austin Lab 之后，Dmitriy 开始将重点转向信息安全，并参与访问控制、策略安全和数据库安全领域的几个项目。 |
| 
| | Martin Oberhofer 于 2002 年初作为软件工程师加入位于美国的 IBM 硅谷实验室。他担任 Enterprise Information Integration and Master Data Management 的架构师，目前与全球各地的大型企业合作，致力于改变信息架构基础，解决与信息紧密相关的业务问题。他擅长的领域包括主数据管理、企业信息集成、数据库技术、Java 开发和 IT 系统集成。他研究的主要领域是将主数据同步和分发到运营 IT 环境中，尤其是与 SAP 应用系统交互主数据。他向客户和主要系统集成人员提供 Enterprise Information Architecture and Solution 专题讲座。他担任 Lab Advocate，为 IBM 大客户提供信息管理方面的专业建议。他拥有德国 University of Constance 的数学硕士学位。 |
对本文的评价
| 
