有关ALSB security控制的,编写https接口模块会用到。
时间：2006-06-05
作者：Paul Done
浏览次数：
本文关键字：AquaLogic Service Bus, service bus, enterprise service bus, ws-policy, web services, pki, proxy service, AquaLogic Service Bus, Paul Done, ALSB, 服务总线, 企业服务总线, 代理服务
摘要
服务总线支持以一种统一的方式来定义服务的非功能性方面，比如服务安全性。服务总线允许从服务实现中分离出安全性考虑因素。因此，无需将安全性策略编写到单个服务中。这将产生可重用性更好的更具灵活的系统，而这对于SOA环境中的安全性来说是至关重要的。本教程演示了一个使用BEA的AquaLogic Service Bus 2.0将安全性策略集中式地应用到服务的例子。例子展示了如何将基于WS-Security的消息级安全性应用到SOAP Web服务。教程使用了一个指定Web服务客户端必须签名SOAP请求并提供受信任的证书的安全性策略。例子展示了可以应用到ALSB代理的Web服务的许多基于WS-Security的策略中的一种，并说明了在ALSB以及底层的WebLogic Server中为这些Web服务配置安全性的步骤。教程假设读者对Java、J2EE和Web服务有很好的理解，并具有使用BEA WebLogic Server和AquaLogic Service Bus产品的经验。
简介
AquaLogic Service Bus (ALSB)是用于在面向服务架构(SOA)环境中管理和代理服务和发送服务消息的企业服务总线(ESB)产品。主机环境总是包含有远程Web服务和更为传统的基于消息的联网系统。ALSB充当一个中间层，它接收消息，并对其进行处理以确定接下来将消息发送到何处，以及是否和如何转换消息内容。ALSB通过一种传输协议接收消息，比如HTTP(S)、JMS、File或FTP，然后再通过同一种或另一种传输协议将消息发送出去。ALSB用于封装现有的“业务服务”，并为之提供统一的外观，即，一组“代理服务”。通过提供这种外观，许多服务特征都可以被抽象出来并在一个地方应用，比如安全性策略、服务位置透明性、数据格式、传输协议和消息传递模型（异步、同步）。然后就有可能在版本控制、日志记录、监控、报告、审计、错误处理和客户端应用程序访问等方面集中式地管理这些服务。该架构可以帮助公司最大限度地对现有服务进行控制和重用，并提供一个用于随时间逐步增加新服务的高效模型。
ALSB可以用于对它所代理的服务应用安全性策略。这些安全性策略可以满足针对Web服务机密性、完整性、身份验证和访问控制的任何安全性需求组合。ALSB支持传输层安全性（如SSL）和消息层安全性（如WS-Security），甚至需要的话，还支持对同一服务实例的两种安全性的组合。WS-Security是一组由OASIS管理的规范，它指定了如何对Web服务消息内容（例如，SOAP头部和/或主体）进行加密和签名，以及服务消费者如何对服务提供者进行身份验证（如：通过SAML、X.509）。通过采用消息层安全性策略而不是传输层安全性策略，SOA中的Web服务中间层（比如，ALSB之类的企业服务总线）就可以代理和发送消息而不必对流经它的消息进行解密和重加密。WS-Policy是另一个由OASIS管理的规范，它支持对Web服务指定通用属性和断言。WS-Security规范采用WS-Policy规范作为其语法以支持为Web服务指定安全性特征。
关于本教程
在本教程中，为了演示如何使用ALSB保护Web服务，例子使用了一个简单的Echo代理服务。当被调用时，该Echo服务复制请求的主体文本，并将该文本发送回响应的主体。因此，该代理服务实际上并没有转到一个“后端”业务服务。这种设计思路使得可以尽可能简单地将WS-Security结合到ALSB中。在现实用例中，代理服务总是从一个“后端”业务服务接收消息并将消息发送给它。此外，在此教程中，我们使用的是一个自签名的证书而不是由著名证书授权方签名的证书，以及使用单个的WebLogic管理服务器而不是托管服务器集群。
例子创建并使用了一个定制的WS-Policy文件，而不是使用WebLogic Server用于WS-Security的三个开箱即用的WS-Policy文件。Web服务的WSDL和WS-Policy文件指定由客户端对服务请求但不对服务响应进行签名。具体的示例策略文件并没有说明加密应该用于请求或响应。在教程的结尾部分，包括有一组可选步骤，描述了在调用Web服务时，如何基于由客户端应用程序所传递的证书的细节为代理Web服务设置访问控制。图1显示了教程例子的基本结构：
图1. 本教程中所使用的例子的架构（单击图像查看大图）
下面几节描述了配置ALSB以及创建和调用受保护的代理服务所需的步骤。
初始ALSB配置
首先，需要安装AquaLogic Service Bus及其主机WebLogic Server实例，并配置一个域。
- 使用默认的安装设置安装ALSB 2.0（包括WebLogic Server 9.0）。
- 使用Domain Configuration Wizard (config.sh)创建一个新域（base_domain），它被配置为自动支持AquaLogic Services Bus。
创建密钥和密钥库
WS-Security依赖于PKI来支持消息加密、签名，通常还有身份验证。在这个例子中，客户端应用程序使用了一个来自其identity keystore的私钥来签名一个消息，而ALSB服务器使用其trust keystore来帮助其确定消息是否已经被更改了，以及提供的证书是否可信。因此，私钥-公钥对以及客户端应用程序关联的证书需要在一个新的identity keystore中创建，而且证书必须被添加到一个ALSB可用的新的trust keystore中。
- 使用包含在WLS/ALSB附带的JDK中的Java “keytool”实用工具，在域的根目录下新的Identity keystore中为示例用户Bob创建一个新的私钥-公钥对。下面是具体的代码：
> keytool -genkey -keyalg rsa -keystore wsidentity.jks -alias bob -keysize 1024 -keypass weblogic -storepass weblogic -validity 3650 What is your first and last name? [Unknown]: bob What is the name of your organizational unit? [Unknown]: IT What is the name of your organization? [Unknown]: BEA What is the name of your City or Locality? [Unknown]: LONDON What is the name of your State or Province? [Unknown]: LONDON What is the two-letter country code for this unit? [Unknown]: UK Is CN=bob, OU=IT, O=BEA, L=LONDON, ST=LONDON, C=UK correct? [no]: yes - 将这个自签名的证书导出到一个base-64编码的文件bob.pem中：
> keytool -export -alias bob -file bob.pem -keystore wsidentity.jks -storepass weblogic -rfc - 导出Bob的自签名证书到一个新的trust keystore中，WebLogic Server将使用该密钥库确定对WS-Security和/或SSL客户端的信任：
> keytool -import -alias bob -file bob.pem -keystore
trust.jks-storepass weblogic
配置服务器密钥库
一旦创建了密钥和密钥库，就必须使用这些密钥库来配置服务器。
- 从域目录下启动ALSB/WLS服务器（例如，运行.startWebLogic.sh）。
- 从一个浏览器运行WebLogic Admin Console（例如http://localhost:7001/console），并配置WebLogic Server使用新的证书trust keystore而不是默认的demo trust keystore（选择服务器的Keystores选项卡，并输入密钥库设置）。注意：WebLogic Server不允许服务器仍然使用demo identity store，因此，在本例中，也指定了新的identity store，即使服务总线或应用服务器并没有直接将其用于Web服务消息层安全性。图2所示的屏幕快照显示了示例设置（“passphrase”项是“weblogic”）：
图2. WebLogic密钥库配置（单击图像查看大图） - 使用WebLogic Admin Console，对于默认的安全性领域(myrealm)，选择添加一个新的Provider，然后通过选择图3中所示的New按钮，选择添加一个新的Credential Provider：
图3. 凭证映射提供者列表（单击图像查看大图）例如，将名称设置为WSPKICredentialMapper，并确保将类型设置为PKICredentialMapper，如图4所示：
图4. 创建新的凭证映射提供者（单击图像查看大图）保存了之后，选择编辑特定于提供者的设置来指定将定制的identity keystore作为该凭证映射方的密钥库，如图5所示。注意：在该例子中，“passphrase”项是“weblogic”。
图5. 提供者配置（单击图像查看大图） - 保存并激活更改之后，重启WebLogic Server以启用新的密钥库设置。
注意：严格地说，如果ALSB/WebLogic Server不必签名或加密Web服务响应的话（正如本例中的情况），就不需要指定PKI凭证映射方。但是，我们提供了这些额外步骤，以便可以在日后提供Web服务响应签名/加密功能。
创建ALSB安全性代理服务
在ALSB以及底层的WebLogic Server中正确配置了密钥库之后，就可以在ALSB中创建代理服务以及关联的安全性策略。
- 从浏览器运行ALSB Admin Console（例如http://localhost:7001/sbconsole），并创建一个新项目（例如demo）。
- 使用ALSB Admin Console创建一个新的代理服务提供者（例如SecureProxyServiceProvider）来保护代理服务，如图6的屏幕快照所示：
图6.代理服务提供者定义（单击图像查看大图） - 使用ALSB Admin Console创建一个新的资源类型为“Proxy Service Provider”的安全性配置凭证，它定义了先前在WebLogic Server identity keystore中所设置的密钥对的别名。该密钥库资源随后可以被任何需要对客户端应用程序的SOAP响应进行加密或签名的ALSB代理服务使用（本例并非如此）。如图7所示，选择资源类型：
图7.代理服务提供者配置，第1部分（单击图像查看大图）指定提供者目的，如图8所示：
图8.代理服务提供者配置，第2部分（单击图像查看大图）指定提供者类型，如图9所示：
图9.代理服务提供者配置，第3部分（单击图像查看大图）检查提供者设置，并按下Finish按钮，如图10所示：
图10.代理服务提供者配置，第4部分（单击图像查看大图） - 使用ALSB Admin Console添加下面的示例定制WS-Policy文件（SigningPolicy.xml)）。该策略文件指定了消息的主体、特定于WLS的头部，而时间戳头部应该由消息的发送方签名。该策略还声明，客户端应该在消息中包含一个期限设为300秒的时间戳头部：
<?xml version="1.0"?> <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wssp="http://www.bea.com/wls90/security/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part" wsu:Id="signMessage"> <wssp:Integrity> <wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <wssp:CanonicalizationAlgorithm URI="http://www.w3.org/2001/10/xml-exc-c14n#"/> <wssp:Target> <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" /> <wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part"> wls:SystemHeaders() </wssp:MessageParts> </wssp:Target> <wssp:Target> <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" /> <wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part"> wls:SecurityHeader(wsu:Timestamp) </wssp:MessageParts> </wssp:Target> <wssp:Target> <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" /> <wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part"> wsp:Body() </wssp:MessageParts> </wssp:Target> </wssp:Integrity> <wssp:MessageAge Age="300"/> </wsp:Policy>该策略文件可以用于将一个Web服务策略应用到一个或多个代理服务。如果对同一组服务支持许多不同的安全性约束，那么完全可以定义多个不同的策略文件。但是，对于要对所有服务统一应用一个安全性策略的情况，就可以使用该安全性策略定义。如果需要的话，该策略还可以包括加密和身份验证实施元素。
- 使用ALSB Admin Console，为一个假想的“Echo”Web服务添加下面的示例WSDL文件(EchoServiceSecure.wsdl)，并在保存后选择Edit References for the WSDL，关联其策略文件依赖性到前一步骤所添加的策略文件中。WSDL文件定义了一个Echo Web服务，并声明WS-Policy文件只应该被应用于服务输入消息：
<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="http://MyNamespace" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:impl="http://MyNamespace" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" > <wsp:UsingPolicy wsdl:Required="true" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"/> <wsdl:message name="EchoRequest"> <wsdl:part name="in0" type="xsd:string"/> </wsdl:message> <wsdl:message name="EchoResponse"> <wsdl:part name="out0" type="xsd:string"/> </wsdl:message> <wsdl:portType name="Echo"> <wsdl:operation name="DoEcho" parameterOrder="in0"> <wsdl:input name="EchoRequest" message="impl:EchoRequest"/> <wsdl:output name="EchoResponse" message="impl:EchoResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="EchoSoapBinding" type="impl:Echo"> <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="DoEcho"> <wsdlsoap:operation soapAction=""/> <wsdl:input name="EchoRequest"> <wsp:Policy> <wsp:PolicyReference URI="file://SigningPolicy.xml"/> </wsp:Policy> <wsdlsoap:body use="literal" namespace="http://MyNamespace"/> </wsdl:input> <wsdl:output name="EchoResponse"> <wsdlsoap:body use="literal" namespace="http://MyNamespace"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="EchoService"> <wsdl:port name="Echo" binding="impl:EchoSoapBinding"> <wsdlsoap:address location="http://localhost/services/MyEchoService"/> </wsdl:port> </wsdl:service> </wsdl:definitions>注意：在代理服务被用于转到一个现实业务服务的情况中，该WSDL文件总是源自来自现实业务服务的WSDL文件，从后者生成该代理服务的接口。
- 使用ALSB Admin Console，基于所添加的WSDL文件的WSDL端口创建一个代理服务（例如EchoProxyService），并引用先前所创建的代理服务提供者。确保选中了Process WS-Security Header复选框，如图11所示：
图11. 代理WS-Security头部配置（单击图像查看大图）保留该代理的默认Echo管道，以便允许该服务回送直接复制自请求的响应。图12显示了代理服务示例的设置详情：
图12. 代理设置详情（单击图像查看大图）注意：对于这个特定的代理，实际上不需要定义代理服务提供者，因为服务器不需要对其发送回客户端应用程序的响应消息进行签名或加密（如WS-Policy文件所声明的）。要确认签名的Web服务请求是可信的，ALSB只能参考先前的步骤中所配置的WebLogic Server的trust keystore。
- 从一个浏览器输入新的ALSB代理服务的WSDL文件的URL（例如http://localhost:7001/EchoProxyService?WSDL），确保WSDL文件包括WS-Policy设置，以向客户端应用程序指明SOAP请求必须被签名。
创建示例客户端应用程序
现在既然创建了ALSB代理Web服务，就需要创建一个示例客户端应用程序，并运行它来测试该服务。对于本例，使用了WebLogic Server用于生成Web服务客户端的工具包。但是，任何兼容WS-I和WS-Security的Web服务工具包都可以使用。
- 创建一个Ant build文件（例如，build.xml），它基于远程Web服务的WSDL调用WebLogic Server的“clientgen” Ant任务来生成SOAP存根。例如，build文件中包括了下面的内容：
<taskdef name="clientgen" classpathref="CLASSPATH" classname="weblogic.wsee.tools.anttasks.ClientGenTask" /> <clientgen wsdl="http://localhost:7001/EchoProxyService?WSDL" destDir="src" packageName="test" classpathref="CLASSPATH" generateAsyncMethods="false"/> - 使用一个文本编辑器或IDE，创建一个带有main方法的简单Java类，它使用WebLogic Server的JAX-RPC实现来调用ALSB Echo代理Web服务，使用前面步骤中所生成的存根类。然后该文件将被编译。由于JAX-RPC标准还未覆盖WS-Security元素，一些用于创建客户端应用程序的API是特定于供应商的。下面是一个可以使用的示例测试客户端源代码：
package test; import java.util.*; import java.security.cert.*; import javax.xml.rpc.*; import weblogic.security.SSL.*; import weblogic.xml.crypto.wss.*; import weblogic.xml.crypto.wss.provider.*; import weblogic.wsee.security.bst.*; import weblogic.wsee.security.unt.*; public class EchoServiceClient { public static void main(String[] args) { try { // Point to the private/public key-pair identity keystore // that will be used by the client for signing List credProviders = new ArrayList(); CredentialProvider cp = new ClientBSTCredentialProvider( "/opt/bea/domains/base_domain/wsidentity.jks", "weblogic", "bob", "weblogic"); credProviders.add(cp); // Get a handle on the Web service stub EchoService echoService = new EchoService_Impl( "http://localhost:7001/EchoProxyService?WSDL"); Echo echoStub = echoService.getEcho(); // Associate the key pair credentials with the Web // service stub Stub baseStub = (Stub)echoStub; baseStub._setProperty( WSSecurityContext.CREDENTIAL_PROVIDER_LIST,credProviders); baseStub._setProperty( WSSecurityContext.TRUST_MANAGER, new TrustManager() { public boolean certificateCallback(X509Certificate[] chain, int validateErr) { return true; } }); // Call the Web service and display the result String result = echoStub.doEcho("Hello from the client application"); System.out.println("Service result is: " + result); } catch (Exception e) { System.err.println("Unable to invoke service: " + e.getMessage()); e.printStackTrace(); } } } - 从命令行运行test.EchoServiceClient Java应用程序以使用签名的消息调用ALSB Echo服务，并显示服务响应。如果成功的话，客户端应用程序会向控制台打印下面的消息：
Service result is: Hello from the client application
注意，客户端应用程序需要在其类路径中包括WebLogic Server的webserviceclient.jar。
已完成的工作
到目前为止，我们已创建了所需的PKI密钥、证书、密钥库，已经使用这些PKI工件将WebLogic Server和ALSB配置为支持WS-Security：定义了一个WS-Security策略文件，随后它可以被应用于一个或多个服务；使用该安全性策略文件创建了一个代理Web服务。最后，为该代理服务创建并调用了一个测试Web服务客户端，它对发送到ALSB的SOAP请求进行签名，还包括了客户端的证书。
这些配置任务中的大部分只需对整个环境执行一次。要使用相同的安全性策略保护更多被代理的业务服务，每个附加的代理服务只需将其WSDL定义修改为引用现有的WS-Security策略文件。
访问控制配置（可选）
下面的步骤只有在需要向ALSB代理服务应用访问控制时才需要执行。我们将创建一个用于附加用户的密钥对(Alice)，帮助测试访问控制设置是否配置正确。在本例中，访问控制将被指定为许可Bob访问该服务而阻止Alice访问服务。ALSB Access Control设置将基于包含在由客户端应用程序所提供的证书中的识别名(distinguished name，DN)元素。
- 在域的根目录中的现有identity keystore中为附加的示例用户Alice创建一个新的私钥-公钥对：
> keytool -genkey -keyalg rsa -keystore wsidentity.jks -alias alice -keysize 1024 -keypass weblogic -storepass weblogic -validity 3650 What is your first and last name? [Unknown]: alice What is the name of your organizational unit? [Unknown]: IT What is the name of your organization? [Unknown]: BEA What is the name of your City or Locality? [Unknown]: LONDON What is the name of your State or Province? [Unknown]: LONDON What is the two-letter country code for this unit? [Unknown]: UK Is CN=alice, OU=IT, O=BEA, L=LONDON, ST=LONDON, C=UK correct? [no]: yes - 导出该密钥对的自签名证书到一个base-64编码的文件alice.pem：
> keytool -export -alias alice -file alice.pem -keystore wsidentity.jks -storepass weblogic -rfc - 导出Alice的自签名证书到一个现有的trust keystore：
> keytool -import -alias alice -file alice.pem -keystore trust.jks-storepass weblogic - 使用WebLogic Admin Console，导航到域配置页面，选择WebService Security选项卡，然后选择__SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__配置，然后选择Token Handler选项卡。从token handlers列表中，选择default_x509_handler项。在页面的底部，选择“UseX509ForIdentity”作为token handler属性，然后将其置改为true（参见图13的屏幕快照）。设置该属性将指示WebLogic Server的WS-Security实现尝试使用x509口令来识别客户端，使用由客户端应用程序所传递的口令。
图13. 代理设置详情（单击图像查看大图） - 使用WebLogic Admin Console，导航到“myrealm”Security Realms页面，选择Providers | Authentication，然后选择DefaultIdentityAsserter项。选择该项的Provider Specific选项卡，并设置下述字段值：Default User Name Mapper Attribute Type = CN，Active Types = Authenticated User & X.509，以及User Default User Name Mapper = true（参见图14中的屏幕快照）。这将指示WebLogic Server映射证书的识别名(distinguished name，DN)中客户端应用程序的公用名(common name，CN)到WebLogic Server的Security Realm（例如，“bob”、“alice”）中一个已知的用户名。
图14. 代理设置详情（单击图像查看大图） - 重启WebLogic Server，支持加入新的安全性设置。重启之后，再次检查Admin Console中的Active Types设置以确保其包含值“X.509”（检查上述屏幕快照中所显示的页面）。
- 使用ALSB Admin Console，选择Security Configuration部分，创建两个新的用户，“bob”和“alice”。这些用户旨在与先前所创建的密钥对的CN相符合。
- 使用ALSB Admin Console，选择Security Configuration部分，然后选择Access Control。对于代理服务(EchoProxyService)，对Transport Authorization Policy选择View Policies，并添加一个新条件“Allow access to everyone”，然后对Service Authorization Policy选择View Policies，并添加一个新条件“User bob”。该配置指定任何人都可以使用HTTP/HTTPS连接到代理服务URL（可用于支持WSDL，让任何人查看服务），但是只有用户“bob”（而不是“alice”）可以运行该Web服务的操作。
- 要测试访问控制是如何运行的，再次运行测试客户端。使用“bob”的证书应该可以成功调用服务，客户端应用程序应该会向控制台打印下述消息：
Service result is: Hello from the client application
- 在测试客户端的源代码中，将密钥对的别名从“bob”改为“alice”，重新编译客户端，并再次运行。这时对ALSB代理服务的调用应该会产生一个SOAP故障，该故障被客户端应用程序接受，它说明了访问控制失败。应该会显示类似于下面的错误消息：
Unable to invoke service: SOAPFaultException FaultCode
http://schemas.xmlsoap.org/soap/envelope/}Server] FaultString
[BEA-386000: com.bea.wli.sb.security.AccessNotAllowedException:
access not allowed for subject Subject:
Principal = class weblogic.security.principal.WLSUserImpl("alice")
结束语
本教程展示了如何保护Web服务来强制客户端应用程序签名Web服务请求并提供受信证书。只需通过修改在服务的WSDL文件中指定的安全性策略，就可以轻松地修改服务的安全性，使其对Web服务请求也实施消息加密，对响应实施消息签名和加密。在企业服务总线中而不是在每个“后端”业务服务消息生产者中应用这类安全性，将带来以下好处：
- 可以以同样的方式保护所有的业务服务，即使某些用于创建和提供其中的一些Web服务的技术实际上不支持WS-Security（或者甚至是更基本的安全性机制或协议）。
- 可以使用各种安全性策略和协议（例如，使用HTTP、HTTPS/SSL、WS-Security进行基本的身份验证）公开同一个业务服务，以支持多种不同类型的客户端。此类客户端应用程序可能只具有处理一种类型的安全性协议的技术。此外，还可能会出现这种需求：对于同一组业务服务，要对不同类型的消息消费者应用不同的安全性策略（例如，同一局域网中相交互的另一部门，或者公司中通过Internet、B2B和电子商务交互的远程部分）。对于单一的业务服务，可以通过为每个策略定义不同的ALSB服务代理来定义多个安全性策略，以支持不同的客户端应用程序，并将所有的代理服务转到同一个“后端”业务服务。
- 与基于传输的安全性不同，WS-Security支持一个消息调度程序，它通过探查某些或全部未加密的SOAP消息头部，从而无需解密整个消息就可以做出Web服务路由决策。
服务总线为机构提供了一种集中式地声明和实施其服务安全性策略的强大方式，而无需要求单个开发人员以一种一致的方式在所有已开发的Web服务和子系统中硬编码安全性策略逻辑。
参考资料
- ALSB 2.0 Securing Inbound and Outbound Messages——BEA产品文档
- WebLogic Server 9.0 Configuring Web Services Security——BEA产品文档
- WebLogic Server 9.0 Security Policy Assertion Reference——BEA产品文档
- Java Key and Certificate Management Tool (keytool) - java.sun.com文档
- OASIS Web Services Security (WS-Security) Home Page
- dev2dev上的BEA WebLogic Server产品中心
- dev2dev上的BEA AquaLogic页面
原文出处:http://dev2dev.bea.com/pub/a/2006/04/securing-service-bus.html
| 作者简介 | |
| Paul Done 是BEA设在欧洲的Architecture and Advanced Services咨询团队成员。Paul帮助客户交付构建于BEA的WebLogic Server、AquaLogic和Communication Platform技术之上的解决方案。 | |
1799
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
