Tutorial SOA Demonstrator PDF

Demonstrator for Open SOA Gateway
Tutorial
CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com
1. INTRODUCTION .............................................................................. 1
2. REQUIREMENTS ............................................................................. 2
3. INSTALLATION & START OF THE STARTER KIT ......................... 2
4. SAMPLE SCENARIO ....................................................................... 3
4.1.
Start of the sample scenario .............................................................................................. 7
4.2.
SOA Gateway........................................................................................................................ 14
4.3.
Protection of the return path ............................................................................................ 20
4.4.
Embedding of WSDL definitions ..................................................................................... 24
5. ADVICE .......................................................................................... 27
5.1.
SSL Connection ................................................................................................................... 27
5.1.1. Changing the Apache Tomcat TCP Port ....................................................................... 27

5.1.2. SSL connection with Microsoft Internet Explorer ......................................................... 27
5.1.3. SSL connection with Mozilla Firefox............................................................................... 27
5.1.4. Replacing the SSL certificate .......................................................................................... 29
5.2.
Supported number of user/roles ..................................................................................... 30
5.3.
OutOfMemory error ............................................................................................................. 30
5.4.
Performance problems (Deactivation of TCP monitors) ........................................... 30
1.
Introduction
Thank you very much for your interest in the Open SOA Gateway.
With the Open SOA Gateway Demonstrator you will receive a preconfigured package for
evaluation of the security solution. Besides the Open SOA Gateway, additionally there is a
sample web service as well as a TCP Monitor (TCPMon) included in the Demonstrator. This
enables the rapid performance of sample scenarios without set-up of additional
infrastructure.
2.
Requirements
The Demonstrator contains components requiring a Windows environment (e.g. Java

installation). Thus it is not possible to start the Demonstrator on other systems. The secRT,
of course, is platform independent and can be run on any system.
Please kindly ensure, that the following TCP Ports are not used on your test system:
8080
HTTP Port of the Apache Tomcat
443
HTTPS Port of the Apache Tomcat
2000,2200,2500
TCP Ports of the preconfigured secRT

entities
1900,2100,2300,2400,2600
TCP Ports of the preconfigured TC monitors
2301,2302
Additional ports for configuration example
Also, please kindly see the notes in chapter 5.
3.
Installation & Start of the starter kit
The starter kit is delivered as ZIP archive, containing an installation of all components
modified for demo purposes.
Unpack the ZIP archive directly to C:\. Within the archive there is a predefined file structure.
After extracting the CORISECIO directory should display the following structure:
For the start of all components a Batch file is used (startDemonstrator.cmd). Execute this file
to start the starter kit.
4.
Sample scenario
To enable a quick evaluation of the solution, CORISECIO provides a Demo Web Services as
well as a TCP monitor.
The sample scenario protects an order process in a book shop. It sends two requests to
different recipients (Services).
The communication between the shop and the recipients is unencrypted in this initial
constellation.
This scenario is a segment of the example attended to in the BSIs SOA Security
compendium. The following image displays the whole scenario.
Source: SOA Security compendium of the BSI
The order process is protected by the Open SOA Gateway. The protection is done between
Web Shop and merchant as well as between Web Shop and financial services provider. The
connection between Web Shop and warehouse is ignored here.
By using three Security Gateways the complete data set between Web Shop and
merchant as well as the payment information to the financial services provider are protected.
A complete protection of the transportation route between merchant and payment provider
could also be done but is omitted to gain a better overview of the scenario. Here the
connection from merchant to payment provider is assumed to be protected otherwise.
The protected set-up of the sample scenario is as follows:
Based on the five TCP monitors contained in the package the protection of the connection
may be simulated. Here the content of the first TCP monitor should exemplarily be used for
demonstration of the SOAP message and the elements to be encrypted.
The Open SOA Gateway protect the connection using SAML authentication, XML Signature
and XML Encryption. In this scenario a message for two different recipients is protected. On
one hand, the whole data set for the merchant is encrypted and signed and on the other
hand the access data for the payment provider is especially encrypted separately.
Below the detailed procedure is described:
The first Open SOA Gateway (order + payment encryption in the diagram)
inserts a SAML authentication to the message. Then paymentInformation is
encrypted using the certificate of the third Open SOA Gateway (payment decryption
in the diagram).
Subsequently the message (SOAP Envelope) is signed and encrypted. Here the whole
Order element (see SOAP message graphic above) for the second Security Connector
(order decryption in the diagram) is encrypted. Then the message is forwarded to
the second Open SOA Gateway e.g. via the Internet.
Now the second Open SOA Gateway scans the SAML authentication, decrypts the
message and verifies the signature. The paymentInformation data remains
encrypted. The message is forwarded to the merchant.
The third Open SOA Gateway decrypts the paymentInformation data and forwards it
to the payment provider.
The configuration of the individual Open SOA Gateway is described more detailed under
point 4.2. No further configuration of the Open SOA Gateway is required for execution of this
sample scenario.
To be able to view the communication between the individual paragraphs, several TCP
monitors are used. Using these TCP monitors actions processed on the SOAP message
can be viewed. In the sample scenario, 5 TCP monitors are started in one window.
As only the way out is secured, always only the upper part of the TCP monitor is relevant. In
the following image this part is marked in red.
4.1.
The
Start of the sample scenario

solution
is
now
ready-for-use
http://localhost:8080/WSDemo/.
and
may
be
called
up
under
To obtain help for the use of the Demo scenario, you may move the mouse over the button
Demo Help (
) on each page. Here a help for the required steps is displayed on the
respective page.
Start the book order with a click on Start Demo in the middle of the window.
Chose one or more articles from the assortment and then confirm with Add to Shopping
Cart at the end of the page (the maximum amount per item is limited to 10).
Now confirm your choice with Proceed to Checkout.
Enter sample data in address and payment data request and confirm with Send Order (the
credit card number must be a 16-digit number).
Then you will see the respective messages on the TCP monitors. Here this is shown
exemplarily using excerpts of the individual monitors. The other demo shop sites are only for
information purposes. By clicking on Send Order the operation is completed.
TCP Monitor #1 (Tab Port 1900):

The message is unencrypted and all order information is visible. In the scenario this TCP
monitor is located between the web shop and the first Open SOA Gateway. No security
procedure has been executed yet.

After having been processed by the first Open SOA Gateway SAML authentication
information was added, the payment information and the complete Order element were
encrypted. Additionally the message was applied with an electronic signature. The following
images show the individual elements within the SAOP message.
SAML authentication information
10
Signature
Encryption
The whole Order element has been encrypted. As described in the scenario, also the
paymentInformation element was previously encrypted. This will be shown in the
next TCP monitor.
11

The second Open SOA Gateway decrypted the Order element, the
paymentInformation data remains encrypted. Additionally the SAML assertion was
scanned and the signature verified.
TCP Monitor #4 (Tab 2400):

12
The merchant forwards the paymentInformation; this is encrypted as before. The

message has changed as the order data has been extracted and only address data and
payment data are forwarded.
TCP #5 (Tab 2600):

Now, the payment data is being decrypted and may be processed by the payment provider.
Finally
you
may
call
up
summary
of
the
payment
provider
http://localhost:8080/WSDemo/pp
13
under
as well as under http://localhost:8080/WSDemo/dl a summary of the orders.
Please kindly note that the configured TCP monitors are not designed for long-term usage or
load tests. If protection of web services seems to be slow, you may deactivate the TCP
monitors. The required procedure is described in chapter 5.4.
You have successfully completed the prepared scenario. You may now see and edit the
Security Connector settings in the following chapter.
4.2.
SOA Gateway
The configuration of the Open SOA Gateway is done via the Workflow Manager on the
local secRT entity. The local administration is done via a web console, accessible via
browser.
The three Security Gateways are accessible under the following addresses (see scenario
diagram):
https://localhost/consumer
https://localhost/provider
https://localhost/payment
https://localhost/proxy
You may log-in with the password secRT on the respective Security Gateway.
14
Now choose Workflow Manager from the left-hand menu to see or edit the respective
SOA Gateways.
15
Via the Workflow Manager several Workflows within a secRT may be administrated.
Therefore, the overview page of the available workflows is displayed first. For the sample
scenario only one workflow per secRT is configured. Click on the Edit button after the
name of the configured workflow each, to view the detail configuration. The active workflows
in the standard configuration are consumer, provider and payment.
The currently active workflow is marked with the symbol
Hereafter the configurations of the individual Open SOA Gateway from the sample scenario
are shown.
16
order + payment encryption SOA Gateway: consumer Workflow
17
order decryption SOA Gateway: provider Workflow
18
payment decryption SOA Gateway: payment Workflow
Short description of the functions used:

AppServer Listener #1
Configuration of the TCP Port
SetSecRTEntity
Configuration of the entity name, the private key and the certificate.
ExtractFromRequest
19
Extracting of a SOAP message from an HTTP-Request
SAMLAddUserAuth( SAML 2.0 )
Inserting of a SAML authentication information
encryptXPathForCertificate
Encryption of the required XML element with the given certificate
SignSOAPEnvelopeWithXPath
Signature of the SOAP message; the signature is done by the elements referenced
by the given X-Path.
EnvelopeInRequest
Inserting of the SOAP message into an HTTP request
Proxy
Proxy configuration for forwarding of the http request
decryptXPath
Decrypting of an XML element with the private key
SAMLCheckUserAuth (SAML 2.0)
Checking of the SAML authentication information
verifySOAPEnvelope
4.3.
Verification of signature
Protection of the return path
Using the protection of the return path as an example in this chapter will be demonstrated
how Web Services may be protected easily with the help of Open SOA Gateway. The http
response between the entities consumer and provider is protected. For this purpose the
workflow of both entities has to be adapted in the demonstrator.
1. Open a browser and enter the address https://localhost/provider.
2. Log-in at the Open SOA Gateway using the password secRT.
20
3. Click the button Workflow on the menu bar.

4. Activate the checkbox at the Workflow provider and select Edit from the action bar.
5. Add the following functions in the area Workflow Sequence using the Drop-Down
Box Function:
ExtractFromResponse
EncryptXPathForCertificate
EnvelopeInResponse
6. Chose the function EncryptXPathForCertificate and click Configure.

7. From Configure certificate chose the certificate of the secRT entity consumer.
8. Copy the following text to the text field Configure XPath (via the XPath is defined
which element will be encrypted):
//*[local-name() = 'OrderingResult']
21
9. Click Ok to save the changes.

10. Activate the checkbox at Workflow provider and select Activate / Deactivate from
the action bar. In doing so, the workflow with the updated values is loaded.
11. Open a browser and enter the address https://localhost/consumer.
12. Log-in to the Open SOA Gateway using the password secRT.
13. Click the button Workflow on the menu bar.
14. Activate the checkbox at the Workflow consumer and select Edit from the action
bar.
15. Add the following functions using the Drop-Down Box Functions:
ExtractFromResponse
DecryptXPath
EnvelopeInResponse
22
16. Chose the function DecryptXPath and click on Configure.

17. Copy the following text to the text field Configure XPath (via the XPath is defined
which element will be encrypted):
//*[local-name() = 'OrderingResult']
18. Click Ok to save the changes.

19. Activate the checkbox at the workflow consumer and select Activate / Deactivate
from the action bar. With this action the workflow with the updated values is loaded.
The configuration of the encryption is now completed. With this configuration also the
return path between the secRT entities consumer and provider is protected. The result
can be seen on Port 2100 on the TCP monitor; now attention must be paid to the lower
part of the TCP monitor.
23
4.4.
Embedding of WSDL definitions
For the following scenario another secRT entity was pre-configured and a workflow was
pre-defined. In this scenario the turnover tax advance return for each transaction is done
automated at the local tax office. This process represents the lowermost part of the
overall scenario already introduced. For this a provided WSDL definition is used and the
value of the current transaction is entered.
1. Open a browser and enter the address https://localhost/wsdl.
2. Click Admin on the menu bar and select Import / Export.
3. Select Workflows under Import in the Drop-Down Box.
4. Now click the Browse button and chose the file C:\CORISECIO\workflow.csv.
With this file a preconfigured workflow is imported in the secRT.
24
5. Now click on Workflow in the menu bar.

6. Select the Workflow umsatzsteuer (turnover tax) and click on Activate/ Deactivate.
7. Recall the shop via the address http://localhost:8080/WSDemo.

8. Order any amount of books and enter the required data.
9. After completion of the order process please call up the following address
http://localhost:8080/WSDemo/fa to view the turnover tax advance

return.
Short description of the used functions:
25
ExtractFromRequest
Extracting of a SOAP message from an HTTP request
XMLValueToExecutionVariable
Reading of an XML variable (order value) from the order and saving in a variable.
CreateSOAPMessageFromWSDL
Query of a WSDL definition and generation of an appropriate SOAP message.
SetValueOfXPath
Setting of variable (order value) value in a defined XPath.
Envelope in Request
Inserting of a SOAP message in an HTTP request
Proxy configuration for forwarding of the HTTP request
Proxy
26
5.
Advice
In this chapter you will find information to solve potential problems.
5.1.
SSL Connection
As the connection with the secRT entities is protected via a self-issued SSL certificate, you
will receive warning messages in your browser. In this chapter is described, how you may
access the secRT entities despite of warnings (under Microsoft Internet Explorer and Mozilla
Firefox). Furthermore, a replacement of the SSL certificate used is explained.
5.1.1.
Changing the Apache Tomcat TCP Port
If the HTTPS TCP Port is used on your server already, you may change the Apache Tomcat
configuration.
Close
the
complete
demonstrator
and
open
the
file
C:\CORISECIO\Tomcat\conf\server.xml. In the line port="443" instead of 443
enter the required TCP Port.
5.1.2.
SSL connection with Microsoft Internet Explorer
When accessing the secRT entities a notification appears in the Internet Explorer that there
is a problem with the certificate of the web site.
Here click on Continue to this website (not recommended), to establish the

connection to the Open SOA Gateway or to the Webshop.
5.1.3.
SSL connection with Mozilla Firefox
When accessing the secRT entities or the demo web shop a notification in Firefox appears
that the connection is not to be trusted.
27
Here click on I Understand the Risks.
The button Add Exception appears in Firefox. Please click this button. A dialog for Adding
of security exception rules is opened.
28
Please click on Zertifikat herunterladen and then on Confirm Security Exception.

Now you will be forwarded without warning directly to the secRT entities resp. the demo shop
at each call.
5.1.4.
Replacing the SSL certificate
To replace the Apache Tomcat SSL certificate, first terminate all running entities. A suitable
P12 Container is required for the SSL configuration. Finally act as follows:
Copy your P12 file to the directory C:\CORISECIO\Tomcat
Open the file C:\CORISECIO\Tomcat\conf\server.xml
In the row keystoreFile replace the entry secrt.p12 with the file you require.
In the row keystorePass replace the password for the P12 file.
29
Start
the
demonstrator
by
C:\CORISECIO\startDemonstrator.cmd.
5.2.
calling
the
file
Supported number of user/roles
Please kindly note that the standard configuration was designed for 300 objects at user and
role.
5.3.
OutOfMemory error
The starter kit was configured with the standard value 1024MB RAM. If you would like to run
more complex tests, it is advisable to increase the available memory. In order to do so the
file C:\CORISECIO\Tomcat\bin\catalina.bat needs to be adjusted.
For this open the file with a text editor of your choice and search for the value set
JAVA_OPTS=%JAVA_OPTS%. In this row increase the maximum heap size value (Xmx1536M) to increase the RAM limit to 1536 Megabyte. Please kindly note that the limit for
32 bits operating systems is 1600 MB.
Example:
set JAVA_OPTS=%JAVA_OPTS% -Xmx1536M -XX:MaxPermSize=256m Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager Djava.util.logging.config.file="%CATALINA_BASE%\conf\logging.propert
ies"
Please ensure that the Xmx entry as well as the MaxPermsize Parameter (-Xmx1536M XX:MaxPermSize=256m) are set at your Apache Tomcat entity.
5.4.
Performance problems (Deactivation of TCP monitors)
Please kindly note that 5 TCP monitor entities have been inserted between each section.
The TCP monitors are used for control of exchanged data. If you would like to run
performance or load tests, you may deactivate the use of the TCP monitors.
For this it is required to terminate the TCP monitors and to activate each workflow with the
add-on (no TCP Monitor) in the three secRT entities.
Additionally you have to terminate the Apache Tomcat and to replace the content of the file
C:\CORISECIO\Tomcat\webapps\WSDemo\config.xml with the content of the file
config_withoutTCPMonitor.xml
in the same directory. Afterwards restart the
demonstrator with C:\CORISECIO\startDemonstrator.cmd.
30
Please kindly note that the TCP monitors are called up automatically at each re-start of the
demonstrator. This can be changed by deleting the row start tcpmon.bat in the file
C:\CORISECIO\startDemonstrator.bat.
To re-use the TCP monitors, act as follows: in the three secRT entities the workflows have to
be reset to the initial state. Please stop the Apache Tomcat entity and replace the content of
the file C:\CORISECIO\Tomcat\webapps\WSDemo\config.xml with the content of the
file config_withTCPMonitor.xml in the same directory. Then start the demonstrator by calling
the file C:\CORISECIO\startDemonstrator.cmd.
31

Tutorial SOA Demonstrator PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tutorial SOA Demonstrator PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Demonstrator for Open SOA Gateway

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

Start of the sample scenario .............................................................................................. 7

Protection of the return path ............................................................................................ 20

Embedding of WSDL definitions ..................................................................................... 24

SSL Connection ................................................................................................................... 27

5.1.1. Changing the Apache Tomcat TCP Port ....................................................................... 27

Supported number of user/roles ..................................................................................... 30

OutOfMemory error ............................................................................................................. 30

Performance problems (Deactivation of TCP monitors) ........................................... 30

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

The Demonstrator contains components requiring a Windows environment (e.g. Java

HTTP Port of the Apache Tomcat

HTTPS Port of the Apache Tomcat

TCP Ports of the preconfigured secRT

TCP Ports of the preconfigured TC monitors

Additional ports for configuration example

Also, please kindly see the notes in chapter 5.

Installation & Start of the starter kit

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

Source: SOA Security compendium of the BSI

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

Start of the sample scenario

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

Now confirm your choice with Proceed to Checkout.

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

TCP Monitor #1 (Tab Port 1900):

TCP Monitor #2 (Tab Port 2100):

SAML authentication information

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

TCP Monitor #3 (Tab Port 2300):

TCP Monitor #4 (Tab 2400):

The merchant forwards the paymentInformation; this is encrypted as before. The

TCP #5 (Tab 2600):

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

as well as under http://localhost:8080/WSDemo/dl a summary of the orders.

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

The currently active workflow is marked with the symbol

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

order + payment encryption SOA Gateway: consumer Workflow

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

order decryption SOA Gateway: provider Workflow

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

payment decryption SOA Gateway: payment Workflow

Short description of the functions used:

Configuration of the TCP Port

CORISECIO GmbH - Uhlandstr. 9 - 64927 Darmstadt - Germany - www.corisecio.com

Extracting of a SOAP message from an HTTP-Request

SAMLAddUserAuth( SAML 2.0 )

Inserting of a SAML authentication information

Encryption of the required XML element with the given certificate

Inserting of the SOAP message into an HTTP request

Proxy configuration for forwarding of the http request

Decrypting of an XML element with the private key

SAMLCheckUserAuth (SAML 2.0)

Checking of the SAML authentication information

Protection of the return path