 | Level: Intermediate Antonio Gallo (agallo73@yahoo.it), IT Specialist, Banca d'Italia
Maria Gallo (maria.gallo@it.ibm.com), Software Developer, IBM
Michele Crudele (michele.crudele@it.ibm.com), Software Architect, IBM
14 Feb 2008 As part of a
series
exploring a real case scenario, this article covers the security-related aspects
concerning certificate-based XML standard encryption. Get insight into XML standards
and WS-Encryption. Step-by-step instructions show you how to configure IBM®
WebSphere® DataPower® SOA Appliances and its extension functions to
promote a public key infrastructure (PKI), thus protecting the privacy of sensitive
data contained in portions of XML documents in transit. You should have a basic understanding of XML
and security-related concepts to follow along with this article.
Introduction
Part 1
of this series introduced the healthcare reservation system and described the
scenario that's going to be implemented throughout this
series.
Figure 1 illustrates the complete architectural picture that this series is based
on.
Figure 1. Reservation system
In this scenario, you look at how remote medical offices completely delegate the
reservation service to a central system that fills their reservation slots and
periodically sends back an updated agenda in the form of a SOAP message. Each
message contains, in its body, a serviceProviderId that
univocally identifies the office this message must be sent to. This article
focuses on WebSphere DataPower SOA Appliances and analyzes the role it plays to
promote a PKI.
Let's begin by breaking down the process in a general overview. When getting a
SOAP message for a specific medical office, WebSphere DataPower SOA Appliances:
- Parses the message.
- Gets the
serviceProviderId.
- Dynamically selects the service provider's certificate according to the
retrieved
serviceProviderId and encrypts the message
using this certificate.
- Sends the resulting SOAP message to the enterprise service bus (ESB) using the
specified endpoint bindings.
The following sections present detailed steps about how:
- The SOAP envelope is encrypted.
- The key-certificate pairs are generated for test purposes and uploaded to
WebSphere DataPower SOA Appliances.
- WebSphere DataPower SOA Appliances is configured as a Web service proxy to
forward encrypted messages to the ESB.
- The certificate is dynamically selected at run time using some WebSphere
DataPower SOA Appliances' extension functions and, thus, used to perform the
encryption.
Looking for a way to
encrypt confidential data
Usually when you want to send some sensitive data, you have two chances to secure
the communication. One option is to use Secure Sockets Layer (SSL), which secures
the whole communication. However, HTTP-based security simply isn't enough. HTTP
and its security mechanisms only address point-to-point security. When messages
might cross multiple hops, you must use more complex solutions that maintain a
secure context over a multi-point message path. There are two possibilities that
can help solve this:
- WS-Security
- XML standard encryption
Both solutions provide message-level security, incorporating security features in
the SOAP message and working in the application layer, thus ensuring end-to-end
security. While WS-Security encryption is the Web services security standard for
encrypting SOAP messages, XML encryption is the standard that you can use to
encrypt an XML message, or even just part of it. To better understand the
differences between these two types of encryption, let's compare these approaches
in terms of the scenario that's going to be addressed.
Suppose the agenda that's being transmitted by the central reservation system
contains all the information about the calendar of the reserved slots wrapped
inside an sdoWrapper service data object
(xmlString) and is represented in an XML-like format,
as shown in Listing 1.
Listing 1.
SOAP Message
<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 />
<soapenv:Body>
<p374:sendUpdatedAgenda xmlns:p374="http://Asynch_Library/AsynchResSystemExport">
<sdoWrapper>
<xmlString />someConfidentialContent </xmlString >
<sdoWrapper/>
<serviceProviderId >ASL1<serviceProviderId >
</p374:sendUpdatedAgenda >
</soapenv:Body>
</soapenv:Envelope>
|
Because the message is confidential, some information is required to identify the
service provider to which the message is intended; the
serviceProviderId has been added for this purpose. To
protect this data, we decided to encrypt the whole
sdoWrapper service data object. This choice guarantees
better flexibility if more sensitive information is added to the
sdoWrapper object. However, keep in mind that using
XPath expressions also makes it possible to just encrypt some part of a service
data object of an XML message.
Both XML standard encryption and WS-Encryption follow a two-step approach for
encrypting data:
- Generate a shared secret key using the public key contained in the trusted
party's certificate (asymmetric encryption).
- Use the key that was previously generated to encrypt the sensitive data within
the SOAP message (symmetric encryption).
In this way, you use asymmetric encryption to just generate and protect the key
to be shared, while you use the symmetric encryption to perform encryption of the
data, thus speeding up the performance. When receiving the encrypted message, the
trusted party uses its private key to decrypt the session key and then uses it to
decrypt the message. This mechanism ensures that only the trusted party can
perform the decryption of the message, being the only one owning the right private
key. In Listing 2 you can see the result of applying WS-Encryption to the SOAP
message described above to encrypt the service data object.
Listing 2. WS-Encryption
<?xml version="1.0" encoding="UTF-8" ?>
-<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-wssecuritt-secext-1.0.xsd">
<xenc:EncryptedKey xmls:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:EncryptedMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
-<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
-<wsse:SecurityTokenReference>|
<wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis
-2004-wss-x509-token-profile-1.0#x509v3SubjectKeyIdentifier"EncodingType=
"http://docs.oasis-open.org/wss/2004/01/oasis-2004-wss-soa-message-security
-1.0#Base64Binary">EOStvn5dTJTROjuM2rn9Ov9dQlQ=
</wsse:KeyIdentifier>
</dsig:KeyInfo>
-<xenc:ChiperData xmls:dsig="http://www.w3.org/2000/00/xmldsigc#">
<xenc:ChiperValue >AIWDQKgc09cBkwjXNPQ8NleT5ZMvuLqQJZUijEXsvvBzhclT
czzDbFGTh67n9NMlpoiu)0p)xcfDATfgJuWQ+KKLN7DsErt543lkvuHTP+lllCV=OPPmhjkoik
jRT4589JCdxzT432LLp098B00 </xenc:ChiperValue>
</xenc:ChiperData>
</xenc:EncryptedKey>
</wsse:Security>
</soapenv:Header>
-<soapenv:Body>
-<q0:sendUpdatedAgenda >
-<xenc:EncryptedData Id="G248054f8-1bD" Type="http://www.w3.org/2001/04
/xmlenc#Element"xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/
xmlenc#tripledes-cbc"/>
-<xenc:ChiperData >
<xenc:ChiperValue >DDY/AI0WDQppKgcyc09cBkwjXNPQ8NleT5234ZMvudcLqQJ4
cDFGTh67+sTr23KYXAsw0M+kc2opDsErt543lkvuHTP+lllCV=OPPmhjkoikZMvudcLqQJ4
ZUijE1111+XsvvBz3wh34hedcls2FTss$+sTr23KYXAsw0M+kzPSRt4ZMvud+sTr23KYXAs
jRT4589JCdxzT432LLp098B00 </xenc:ChiperValue>
</xenc:ChiperData>
</xenc:EncryptedData>
<serviceProviderId >ASL1<serviceProviderId >
</q0:sendUpdatedAgenda >
</soapenv:Body>
</soapenv:Envelope>
|
Note that by using WS-Encryption, all the information related to the generated
shared key is contained in the message's header, while the encrypted data are
contained in the message's body. As far as the generated key is concerned,
the root element of this structure is EncryptedKey,
which contains the dsig:KeyInfo and
dsig:KeyValue elements, both belonging to the same XML
digital signature (dsig:) namespace. The encrypted data, instead, are contained
within the EncryptedData element belonging to the XML
encryption (xenc:) namespace. Both the EncryptedKey and
the EncryptedData sections contain detailed information
about the algorithm that's used, respectively, to asymmetrically encrypt the key
(rsa_15) and symmetrically encrypt the data (tripledes-cbc). The
CipherValue element, instead, contains the encrypted
values of both the key and the sensitive data. Using standard XML encryption to
encrypt the sdoWrapper service data object produces the
result shown in Listing 3.
Listing 3.
Standard encryption
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenv="http://schemas.XMLsoap.org/soap/envelope/"
xmlns:q0="http://Asynch_Library/AsynchResSystemExport">
-<soapenv:Body>
-<q0:sendUpdatedAgenda >
<xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#triplesdes-cbc"/>
-<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<xenc:EncryptedMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"
-<xenc:ChiperData>
<xenc:ChiperValue >AIWDQKgc09cBkwjXNPQ8NleT5ZMvuLqQJZUijEXsvvBzhclT
czzDbFGTh67n9NMlpoiu)0p)xcfDATfgJuWQ+KKLN7DsErt543lkvuHTP+lllCV=OPPmhjkoik
jRT4589JCdxzT432LLp098B00 </xenc:ChiperValue>
</xenc:ChiperData>
</xenc:EncryptedKey >
</dsig:KeyInfo >
-<xenc:ChiperData xmls:dsig="http://www.w3.org/2000/00/xmldsigc#">
<xenc:ChiperValue >AIWDQKgc09cBkwjXNPQ8NleT5ZMvuLqQJZUijEXsvvBzhclT
czzDbFGTh67n9NMlpoiu)0p)xcfDATfgJuWQ+KKLN7DsErt543lkvuHTP+lllCV=OPPmhjkoik
jRT4589JCdxzT432LLp098B00 </xenc:ChiperValue>
</xenc:ChiperData>
</xenc:EncryptedData>
<serviceProviderId >ASL1<serviceProviderId >
</q0:sendUpdatedAgenda >
</soapenv:Body>
</soapenv:Envelope>
|
The main thing to stress here is that this is quite different from straight
WS-Encryption. By using standard XML encryption, all the security-related
information, including the encrypted key and the encrypted data, are contained
within the SOAP message's body (the encrypted key is no longer embedded within the
SOAP header). Moreover, being a SOAP message in an XML-like format, you can always
use XML standard encryption to encrypt the body or part of the body of a SOAP
message. This approach is particularly useful when you need to transfer all
the security-related information about the algorithm used to perform
encryption, the encrypted shared key, the encrypted data, and so on, in the SOAP
message's body.
In this sample, the SOAP messages (described above), after getting encrypted,
come to an ESB that performs protocol switching and routes these messages to some
Java™ Message Service (JMS) clients, all registered on the same topic. The
encryption guarantees the data confidentiality on the topic, because only the
service provider owning the right private key can perform decryption correctly
and, thus, understand the data. In this scenario, it's clear that adopting the
WS-Encryption approach to encrypt the data isn't a good choice. In fact, being the
key related information provided in the SOAP message's header, this piece of
information will get lost as soon as the message is converted to a JMS format.
However, using standard XML encryption, the security information doesn't get lost,
because being embedded in the message's body means it's preserved and simply
transformed into a JMS payload. The JMS clients then get the message in an XML
text format and decrypt it using a standard API. Having to encrypt these SOAP
messages, we decided to leverage WebSphere DataPower SOA Appliances' functionality
to perform standard XML encryption to avoid the programmatic burden of having to
encrypt and decrypt the SOAP message on the central reservation system.
 |
Leverage WebSphere
DataPower SOA Appliances functionality to encrypt confidential data
To sign a portion of an XML document, you need a private key and a public
certificate. In most cases, a trusted certificate authority provides you certificate/key
pairs. If you want to self-generate certificate/key pairs for test purposes, you can
decide to either:
- Generate it directly with WebSphere DataPower SOA Appliances using the Crypto
Tools.
- Generate it through the Java keytool, and later upload it to WebSphere
DataPower SOA Appliances.
You explore both of these options in the following section. If you already have a
private key and public certificate you want to use, skip ahead to the
Upload certificates to the WebSphere
DataPower SOA Appliances box section.
Build a certificate using the
WebSphere
DataPower SOA Appliances crypto facilities
WebSphere
DataPower SOA Appliances provides crypto
facilities that allow you to generate a self-signed certificate and a private key.
You can later download these from WebSphere
DataPower SOA Appliances through the File Management utility. To
build a certificate, perform the following operations:
- Log in to the WebSphere
DataPower SOA Appliances device. The URL to the device is typically
https://servername:9090/, but you may need to verify this with your
WebSphere
DataPower SOA Appliances administrator.
- Enter the user ID and password.
- Select the domain,
then click Login.
- In the Control Panel, click the Administration tab in the left
navigation pane.
- At the bottom of the Administration tab, select Crypto Tools.
- In the Generate Key area, fill in the Common Name and
Object Name fields. The object name represents an alias for the certificate
and must be provided each time the certificate is to be used, such as to perform
encryption.
- Make sure all the radio buttons under the
Password Alias text field are set to on.
- Provide any optional
information about the certificate/key pairing as shown in Figure 2.
Figure 2. Using the Crypto
Tools to generate a certificate/key pair
- Click Generate Key. WebSphere
DataPower SOA Appliances generates a self-signed certificate and a
private key, and stores both in the temporary folder. They can be
downloaded later from WebSphere
DataPower SOA Appliances through the File Management utility.
It's important to stress that both the certificate and the private keys are
generated in a .pem format, so they must be converted through the Open-SSL tools
before importing them into any Java keystore.
Upload the existing certificate using
the WebSphere DataPower SOA Appliances Crypto facilities
When you want to use WebSphere DataPower SOA Appliances only to encrypt the data and want to use a
Java-based application to perform the decryption (which is the case we're using
for this article series),
it's better to generate the certificate/private
key pair using the keytool and then upload only the certificate to WebSphere DataPower SOA Appliances. In
this case the decrypting application needs no conversion for the certificate and
private key. You can import the certificate in WebSphere DataPower SOA Appliances
and later use it for
the encryption.
Coming back to the scenario proposed in this article, suppose
that each service provider has its own certificate and publishes it to the
reservation system that has the responsibility of uploading it to WebSphere DataPower SOA Appliances. For
the sake of simplicity, this sample uses self-signed certificates, but it's clear
that in a real environment each service provider should have its certificates
issued by a certificate authority like VeriSign.
To generate self-signed certificates, you just need to have a Java Development
Toolkit installed on your machine. This lets you easily switch to the
java/bin path and run the keytool command, providing the necessary
information about each service provider in a way similar to those in Listing 1
for a generic sanitary service provider named ASL1.
Listing 4. Sample command
keytool -genkey -alias ASL1_cert -key alg RSA -validity 365 -keystore signer.jks
-storepass signer -dname "CN=AS L1, OU=Development, O=Health Care,
L=Rome, ST=N/A, C=IT" -keypass ASL1_key
|
In this case, ASL1_cert is the certificate's alias; signer.jks is
the keystore that's created and contains the RSA key pair; signer
is the keystore's password; and ASL1_Key is a general password provided for
the certificate. When you've completed the above step, you can export the public
certificate of alias ASL1_cert so you can upload it later in
WebSphere DataPower SOA Appliances.
Listing 5. Sample command
keytool -export -alias ASL1_cert -keystore signer.jks
-storepass signer -file ASL1.cert
|
In this sample, you use eight service providers: ASL1 through ASL8. You generated
a self-signed certificate for each one following the above steps and clearly
modified both the alias and the provider's information to be stored within the
certificate. Then you uploaded these certificates to WebSphere DataPower SOA Appliances.
Upload certificates to the WebSphere
DataPower SOA Appliances box
To upload some certificates to the WebSphere DataPower SOA Appliances box:
- Log in to the WebSphere DataPower SOA Appliances device. In the Control Panel, click the Keys and
Certs Management icon.
- In the window that opens, select Certificates, then click
Add (see Figure 3).
Figure 3. Keys and certificates
management
- In the next window that's displayed, click Upload .
- Browse to the
location of the certificate on your machine, and press OK (see Figure 4).
Figure 4. Crypto certificates
- Enter
ASL1_cert as the certificate name that's used as the
certificate object's alias for later operations.
Configure the WebSphere DataPower SOA Appliances
as Web service proxy
Now you're ready to instrument WebSphere DataPower SOA Appliances to perform standard XML
encryption. In your configuration, WebSphere DataPower SOA Appliances acts as a
Web service proxy, getting
SOAP messages from the central system, performing encryption, then forwarding
these messages to an ESB. In this section you can find step-by-step instructions
about how to configure the device as a Web service proxy so that
WebSphere DataPower SOA Appliances:
- Listens for SOAP messages at a specified Uniform Resource Identifier (URI).
- Forwards these messages to the ESB using the binding
information specified in the Web Services Description Language (WSDL) file (deployed on the ESB machine).
- Applies an encryption policy to perform standard XML encryption of the
incoming message.
Let's start from the beginning:
- In the Control Panel, click the New Web Service Proxy icon. The Web
Service Proxy configuration page appears.
- In the Proxy Name field, enter
ESB_Proxy.
- Click Upload to
upload a WSDL (see Figure 5).
Figure 5. Web service proxy
- Select Export1_AsynchResSystemExportHttp_Service.wsdl as the file to
be uploaded, and press OK.
Note: The Export1_AsynchResSystemExportHttp_Service.wsdl file contains the
binding information and is generated on the ESB. Detailed
information is provided in the next article of this series.
You can download a
sample with default configuration. For WebSphere DataPower SOA Appliances to correctly parse the
Export1_AsynchResSystemExportHttp_Service.wsdl file, you have to also
upload the xenc.xsd, xdig.xsd, and AsynchResSystemExport.wsdl files. The first two files contain the XML encryption
and XML digital signature namespaces used to perform encryption, while
the last one contains the interface definitions of the service deployed on the
ESB and that WebSphere DataPower SOA Appliances must invoke after performing encryption of the
sensitive data. To do this, use the File Management utility to
upload these files in the local folder before the creation of the Web service
proxy. This guarantees WebSphere DataPower SOA Appliances will succeed in parsing
Export1_AsynchResSystemExportHttp_Service.wsdl when it's uploaded during the
proxy creation phase.
- After the file is uploaded and successfully parsed, you should see some new
text fields show up filled with the endpoint values contained in the uploaded WSDL
file. This information instruments WebSphere DataPower SOA Appliances regarding the ESB host
name to be contacted, its port address, and the URL of the service to be
invoked. You should leave this data unchanged (see Figure 6).
Figure 6. WSDL endpoint
settings
- To work as a proxy and, thus, forward messages to the ESB,
WebSphere DataPower SOA Appliances must listen on a port at a specified URI. To
provide this information,
click the + icon under Local Endpoint Handler to display a drop-down
list.
- Select HTTP Front Side Handler, as shown in Figure 7.
Figure 7. Create HTTP handler
- A new window appears. Enter
ESB_Handler as the
Name, and provide
an available port.
- Click Apply. The result is shown in Figure 8.
Figure 8. Configure HTTP front
side
- The screen redraws, and you see a summary of the provided info on the Web
Service Proxy window. Click Apply, then click the Save
button to save the performed changes.
- Click on the Policy tab on the Web service proxy.
- Select the Request rule, and double-click it. A policy window appears
at the bottom of the page, as shown in Figure 9.
Figure 9. Configure policy
- Click the Encrypt action, and drag it on the policy window.
- Double-click the Encrypt action. In the window that appears, select the
Advanced tab.
- To perform standard XML encryption on a part of the SOAP message's body (the
sdoWrapper service data object), you have to select
the Standard XML Encryption and the Selected Elements(Field-Level) check boxes.
Figure 10. Configure encrypt
action
- The Document Crypto Map input appears. Click + to create a new
Document Crypto Map. A new configuration window appears.
- Enter
Encr in the Name field, then click the XPath Tool button. The
XPath Tool window appears (see Figure 11).
Figure 11. Configure Document
Crypto
- Click Upload to upload the soa_msg.xml file (as shown in Listing 1) from the
class file folder.
- Click the Compare Local Name Only radio button. This
creates a shortened XPath expression.
- Select the sdoWrapper field in the displayed schema file. Click the
field Name, not the field content.
Figure 12. Select sample XML
document
- Click Done to accept the XPath expression shown. The window
closes.
- Click Add to add the XPath expression to the list of expressions used
by this map. See the Document Crypto Map in Figure 13.
Figure 13. Document Crypto Map
- Click Apply to complete the configuration of the Document Crypto Map. The
Encrypt configuration window opens (see Figure 14).
Figure 14. Configure encrypt
action
- The encryption algorithm list box lets you choose the symmetric algorithm
to be used to encrypt the service data object contained within the SOAP
message's body. You should also note the Use Dynamically Configured Recipient
Certificate check box in the middle of the page. Setting its value to on
causes the encryption in this step to use a dynamically configured recipient
certificate. If a dynamically configured recipient certificate is provided (for
instance through a stylesheet, as described in the following section), it
takes precedence over what is defined in Recipient Certificate. So you can
leave this text field empty (none) and later check that a valid certificate is
selected at run time.
|
Configure a
stylesheet to select the certificate at run time
Now you're ready for the last step in the scenario. Each SOAP message is
destined to a specific service provider identified by a serviceProviderId
field contained in the SOAP message's body. You uploaded to WebSphere DataPower SOA Appliances several
certificates identified through a naming convention of type
serviceProviderId_cert, where serviceProviderId can be ASL1 up to
ASL8 (eight is the number of service providers in the example). For each
incoming SOAP message, WebSphere DataPower SOA Appliances must be aware of the certificate to use to perform
the encryption. Therefore, now you need to implement a mechanism to parse the SOAP
message's request, get the serviceProviderId, and use it to locate the right
certificate.
As explained in the previous section, enabling the Use Dynamically
Configured Recipient Certificate option in the encryption page automatically
triggers WebSphere DataPower SOA Appliances to perform the encryption, leveraging
a certificate provided at run time: If a value has been specified for the context
variable var://context/transaction/dynamicCertName, and it refers to a
valid certificate, this certificate is used in the encryption step. Otherwise the
default value specified in the recipient certificate is used if it has been
provided. Figure 15 illustrates this.
Figure 15. Encryption rule
To complete the WebSphere DataPower SOA Appliances configuration, perform the following steps:
- Create the stylesheet, as shown in Listing 4.
Listing
6. WebSphere DataPower SOA Appliances namespace and extension element prefix
<xslt:stylesheet version="1.0"
extension-element-prefixes="dp"xmlns:tns="http://www.w3.org/1999/xhtml"
xmlns:dp="http://www.datapower.com/extensions"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<dp:set-variable name="'var://context/transaction/dynamicCertName'"
value="concat('cert:', concat(/*[local-name()='Envelope']/*
[local-name()='Body']/*[local-name()='sendUpdatedAgenda']/*
[local-name()='serviceProviderId'],_cert))" />
</xsl:template >
</xsl:stylesheet>
|
This stylesheet declares a WebSphere DataPower SOA Appliances-specific namespace (dp:) for functions and a dp
extension element prefix. These elements must always be defined each time
you want to use WebSphere DataPower SOA Appliances-specific extension functions. The extension functions,
when used within stylesheets, represent a powerful way of enriching the
cryptographic, integration, and acceleration WebSphere DataPower SOA Appliances
functions available
via a simple Web UI. In this scenario, you invoke the dp:set-variable
extension function to set the context variable
var://context/transaction/dynamicCertName according to the value
contained in the serviceProviderId field within the SOAP message's body.
The concat function is a base XSL function that simply concatenates the
serviceProviderId retrieved value to the _cert string
to correctly identify a certificate on WebSphere DataPower SOA Appliances.
- Add an XSL transformation to the Web service proxy policy window. To do this,
select the Transform option, and drag it on the policy window before the
encryption action (see Figure 16).
Figure 16. Add an XSL transformation
- Double-click the Transform icon. A window appears. Click the
Upload button, browse to the location of the set_cert_name.xsl file, and
click OK.
- Take care to select none from the output list box to avoid the
stylesheet altering the content of the data. In this scenario,
in fact, the stylesheet aims merely to set a variable, not to transform the
message's content. If you select auto or pipe as the output
type, the SOAP message is transformed through the stylesheet, and its
output is sent to the encryption action (the following action in the
policy page), thus altering the content of the message. You can see what this
looks like in Figure 17.
Figure 17. Configure Transform
Action
- Verify that the var://context/transaction/dynamicCertName variable is
correctly set at run time. To do this, you can enable the probe on the
ESB_Proxy Web service proxy on WebSphere DataPower SOA Appliances and check the content of the
context variable before and after the XSL transformation. In this way, you
should be able to see that the variable is correctly set after the
transformation and that its value is kept unchanged until the end of the encryption
action.
| |
Conclusion
You've learned how it's possible to use WebSphere DataPower SOA Appliances
to promote a PKI. You've also learned how to
dynamically select a service provider's certificate, perform standard XML
encryption, and forward the encrypted SOAP message to the ESB.
The next articles of this series show how it's possible to
instrument the ESB to accept these messages, perform protocol switching, and then
forward these messages to a JMS topic where the service providers are registered.
Stay tuned!
Download | Description | Name | Size | Download method |
|---|
| Sample EAR files | AsynchResSystemModuleApp_WSDLFiles.zip | 6KB | HTTP |
|---|
Resources Learn
Get products and technologies
- Innovate your next development project with
IBM trial software, available for download or on DVD.
Discuss
About the authors | | | Antonio Gallo works as IT specialist at Banca d'Italia. As a member of the Tivoli Lab in Rome since 2000, Antonio was involved in different initiatives with the briefing center, providing customers consultancy on how SOA and Web services can be used to achieve their business and technical objectives and realizing first prototypes. He's a Sun Certified J2EE Enterprise Architect, and his interests include software design patterns, Enterprise Service Bus, and SOAs. |
| | | Maria Gallo is a software developer in the IBM Software Group's Tivoli Lab in Rome. She has 10 years of IT experience in the change and configuration management arena in different roles: customer support, product support, and development. Her primary interests are in security and J2EE architecture. She's also a Sun Certified J2EE Enterprise Architect. |
| | | Michele Crudele is a software architect working in the IBM Software Group's Tivoli Lab in Rome. He has 15 years of IT experience, mostly focusing on the development of systems management products and solutions. Michele has broad technical experience from working on different disciplines, such as change configuration management, monitoring and availability management, IBM autonomic computing technologies, and digital asset management for the publishing industry sector. |
Rate this page
| |
