Peng Xu, Zhiyi Fang, Hang Su and Chuyi Wei
College of Computer Science and Technology, Jilin University, Changchun, P.R. China
Keywords: SOA, SCA, SDO, data confidentiality, data integrity, non-repudiation of data.
Abstract: By using technologies such as encryption, decryption, message digest, and digital signature and so on, this
paper designed respective solutions for some security problems of SDO (Service Data Objects) data model,
a concrete business processes based on SOA-SCA (Service Component Architecture) as well as security
solutions for data confidentiality, integrity and non-repudiation of SDO data model based on the business
processes. In addition, the design goals of security solution were analyzed in detail. Finally, the solution was
achieved by using development tools WID (WebSphere Integration Developer) and WPS (WebSphere
Process Server). The test and capability analysis for this realization was performed too.
SOA (Service Oriented Architecture) is the new
phase of the construction methods and environment
for distributed software system. SOA includes a set
of new construction methods and environments for
distributed software system such as running
environments, programming model, structure style
and relevant methodology, which cover the whole
life cycle for service: Modeling - Development -
Integration - deployment - Operation - Management.
Compared with the traditional applications, SOA
mainly considers in which way and how to expose
services, as well as to expose what services. In this
way, we can combine the services provided by the
old system to construct a new application. If using
traditional methods, this may require
re-development, all from the beginning.
Disadvantages of traditional application
architecture lead to the existing application
architecture model's sluggish response on the
changing business needs and results in the increase
of our investment. SOA can help us to improve
business value better and faster, and in this way we
can get the ability of quick response and reuse.
Because of the inherent openness of SOA and a
number of standard protocols used by SCA (Ben,
2007), which makes SOA security issues, especial
for data security problem, very serious, researches
on security issue of SDO became a very helpful
thing. This paper focuses on the SDO data's
confidentiality, integrity and non-repudiation and
does research to address my solutions to these
2.1 Overview SOA Security
SOA security issues are result from using new open
standards instead of traditional security parameters.
There are two aspects make the security issues more
prominent. For one thing, these new standards are
completely open and no one holds them. For
another, it seems that nobody considered security
issues when designing these standards. Let's have a
look at what serious security problems the SOA
architecture may bring on.
2.2 Security of Authorization
and Authentication in SOA
Authentication is a process to verify the identity of
visitors. It is related with authority verification but
has some differences. Authority verification is to
verify whether a user is allowed to access the
services it calls, while authentication is to prove that
the identity of whom visiting your service now is the
same with that the user declared. In an unsafe SOA
Xu P., Fang Z., Su H. and Wei C. (2008).
In Proceedings of the International Conference on Security and Cryptography, pages 337-341
DOI: 10.5220/0001929203370341
environment, it is difficult to achieve trusted
authentication. Because of the coarse-grain security
checking mechanism for interaction between
computers, a SOA services may be attacked by
illegal users. SOA services have neither
authentication nor authority verification. If a
mainframe's resources were used by illegal users, it
will be a serious security issue.
2.3 SOA may Lead to 'Denial of
Service Attacks'
Because the unsafe SOA open for all users, illegal
users can send a large number of service requests to
the server, which will result in service providers'
abnormal work. Therefore, a group of illegal users'
request may bring on denial of service attacks and
SOA may lose the ability to monitor the service level
it provides if serious. (The service level is the
qualitative measurement for SOA). If there is an
attack, unsafe SOA can't tell you whether it has been
overloaded and will make system administrator can
not react on the security issues in the first time.
2.4 SOA may Lead to Auditing
An audit log is a basic requirement for IT security.
In order to check the security performance and
analyze security problems, the system administrator
must have the accurate system behavior log in his
hand. Because unsafe SOA don't have message and
transaction log mechanism, there's no way to
determine who had used the service and where the
service originate from when a service was called,
which will result in no audit trail can be used to
investigate the security gap after the incident and no
way to determine who and damaged the system and
when it happened.
2.5 Data Security Problem of SDO
2.5.1 Analysis for Confidentiality of
SDO Data
Confidentiality is to make sure that there's no
eavesdropping in the transmission. Even if the data
is intercept by illegal user, he will not understand the
real meaning. If architecture can not guarantee a
high degree confidentiality, that is not fully secure.
In an unsafe SOA environment, illegal users can
eavesdrop and intercept the SDO data transmitting
on the net. If the SDO data manufacturers sent to
suppliers contains confidential information, for
example, something like a list of materials required,
the necessary quantity of each material, the very
arrival date, and didn't do additional processing,
illegal users could analyze the SDO data he has got
very easily and find these clear message he wants
after he intercepted the SDO data due to the
standards SDO based. What's worse, if illegal users
modified the SDO data and transmitted it to
suppliers, it will result in huge economic losses.
Therefore, the possibility of SDO data's being abuse
by illegal users is very high.
2.5.2 Analysis for Integrity and
Non-repudiation of SDO Data
When a service provider received a call from the
requesting party, it must be verified to ensure that
the data is sent from the requesting party and the
data has been neither changed in transmission nor
forged by illegal third-party. That is data integrity.
The requesting party can not deny that it had sent the
request of the services, namely, the non-repudiation
of data. Data integrity and non-repudiation is very
important for the service providers and petitioner
exchanging data on the net.
For most security problem in the SOA-SCA
environment there is a suit of solution. A big
solution also contains a number of small solutions,
and every solution resolves a security problem in a
specific area of SOA. Security solutions for SOA
will be hinged on its security architecture and the
needs of each application. I will provide specific
solutions for data security (data confidentiality,
integrity and non-repudiation) (Matt, 2004) of
Security framework of Traditional application is
based on the interaction between human and
computer, while SOA allows interaction between
computers. However, the developers paid very little
attention to that interaction. I think this is because
SOA lacks of internal security. In SOA-SCA
environment, we should embed these functions that
ought to be achieved by the equipment into the
application program.
Since it is not so fast for public key encryption
and private key decryption as well as signing with
the private key and verifying with public key, they
are not suitable to operate on mass data. Owning to
this, my solution doesn’t sign or encrypt all the data.
SECRYPT 2008 - International Conference on Security and Cryptography
The SDO data to be processed is only the
confidential information. There are two advantages
by doing this way. Firstly, the solution will not run
slower because of increasing data. Secondly, after
being processed by the solution, the SDO data's
format is still based on open standards, so the
receiver can still treat it as SDO.
3.1 Solution for Confidentiality of
SDO Data
Take manufacturers for example, assume that the
supplier system want to send a SDO services call to
the manufacturer. First, manufacturer must send a
public key to CA (certificate authority) (Wenbo,
2003), and supplier request a certificate from CA.
The certificate supplier received contains a public
key which matches manufacturer's private key.
Second, the supplier encrypts its message with the
public key in the certificate, and sends the encrypted
message and its certificate to the manufacturer.
Then, SOA security solutions intercept the
information and check the validity of the certificate
through CA. Doing this can verify the identity of the
supplier. Once the authentication checked, the
encrypted SDO data can be sent to the manufacturer.
After received the SDO data, manufacturer can use
its private key to decrypt the data and process it.
As shown in Figure 1if the supplier wants to
send SDO data to manufacturer, the process will be
as follows:
1. Manufacturer sends its public key to CA, and
holds private key on its own side.
2. Supplier requests the certificate that contains
manufacturer's public key from CA.
3. Supplier gets manufacturer's public key by
analyzing the certificate received in Step 2.
4. Supplier sends the SDO data encrypted with
the public key got in Step 3 and its certificate
together to manufacturer.
5. SOA security solutions send manufacturer's
certificate got in Step 4 to CA to validate its
authentication. If succeed, go to Step 6.
Otherwise, tell the supplier by send message
that certificate validation failed and
6. SOA security solutions send manufacturer
the SDO data encrypted with its public key.
7. When received encrypted data from Step 6,
manufacturer decrypt the data by using its
private key to get clear data
When the message processed with encryption
keys by the security solutions for data
confidentiality, it will be converted to encrypted
SDO data. In other words, the message meets the
SDO format, but the content is encrypted. By doing
this, system could receive messages as SDO and
process it, rather than rely on custom or proprietary
messaging standards. At the same time, we realized
the SDO data confidentiality, and the system still
based on open standards.
Figure 1: Process of use public/private key encryption and
certificate in unsafe SOA.
The solution involves only two systems. When
there are multiple systems, every interaction
between two systems should follow the solution
above to send and receive SDO data.
3.2 Solution for Integrity and
Non-repudiation of SDO Data
We will solve it by using digital signatures. As
shown in Figure 2. When sending message, sender
needs to append a message digest signed with its
private key. When received the information, receiver
need to decrypt the signed message digest with
sender's public key. If the message digest from
decryption is the same with that generated from
Figure 2: Principles for the realization of data integrity and
received clear data, it means that the message has
not been modified by a third party when
transmitting, or it is likely that the message has been
modified and the data integrity was destroyed. There
is another situation that no signed digest is in the
message, which means that sender didn't confirm
this message and data non-repudiation destroyed.
Also take communications between supplier and
manufacturer as an example, assume that supplier
want to send SDO data to the manufacturer, the
process will be as follows:
1. Firstly, supplier and manufacturer need to
generate their own pair of public key and
private key, and then send public key to CA,
and CA will generate certificate for them.
2. Supplier generate message digest of SDO data.
3. Supplier makes a digital signature for message
digest from Step 2 with its private key.
4. When receive the message with supplier's
signatures, manufacturer will request the
supplier's certificate, which contains its public
key, from CA first.
5. Manufacturer decrypt the SDO data received in
Step 4 with its private key to get clear data,
and then generate message digest.
6. By using the public key in supplier's certificate
and the message digest from Step 5,
Manufacturer verifies SDO data signed by
7. If succeed in Step 6, the SDO data was not
modified when transmitting in the net, and
includes the supplier's signature.
8. If the validation failed, there are two kinds
possibility. For one thing, SDO data was
modified in the transmission, which means the
data integrity was destroyed. For another,
there's no supplier's signature in the received
SDO data, or the signature information in the
SDO data is wrong, which means
non-repudiation of data was destroyed.
By using WID and WPS, the system realized such a
service that an intermediate agents ACME transfers
between bank accounts on behalf of customers. Fig.3
shows main functional modules.
Figure 3: System Module.
According to Fig.3, the system mainly contains
the following modules: module for the account
services of the relative bank system, customer
service module of ACME, fees module of ACME, a
module in charge of the information exchange
between modules, and a CA module to provide
certificates to every customers. The modules
division, as well as the services provided by every
module is according to the SOMA (
Modeling and Architecture) method (Abdul, 2008).
5.1 Test Case
Assume that a customer of ACME, John, have
respectively account in two banks, Bank A and Bank
B. Now he wants to transfer $10,000 to Bank B
account from Bank A account, but he did not want to
go to bank. ACME has integrated account services
of the two banks, so he wanted to complete this
through ACME.
Since encryption, decryption or signature with
RSA (Murdoch, 2001) is not suitable for mass data,
the system will process the confidential information
of the SDO data only (choos transfer accounts here).
5.2 Test Result
Under the server WPS v6, a stand-alone reference
was exported by WID and we can design a JSP page
to call SCA services in the test.
Here is the data accrued when system running:
[2/24/08 16:32:30:047 CST] 000000bb SystemOut
a3tPNAXCwPk2mDHmMoS8rz3J6c8kA== --
[2/24/08 16:32:30:047 CST] 000000bb SystemOut
O customer signature verification success -- ACME
[2/24/08 16:32:30:094 CST] 000000bb SystemOut
SECRYPT 2008 - International Conference on Security and Cryptography
[2/24/08 16:32:30:109 CST] 000000bb SystemOut
O deduct amount: 10000 -- bank
[2/24/08 16:32:30:109 CST] 000000bb SystemOut
O ACME signature verification success -- bank
[2/24/08 16:32:30:109 CST] 000000bb SystemOut
O customer signature verification success -- bank
[2/24/08 16:32:30:109 CST] 000000bb SystemOut
O deduct money from bank
From line 2 to line 6, this is the encrypted data
and signature created when John processing amount
of account transfer. The data contains two parts, and
they are separated by the keyword “SDO”. First part
is the data encrypted with public key of ACME, and
the second part is the signature data obtained from
the digest of account transfer amount which signs
with John’s private key. The data is output data for
John and input data for ACME.
When ACME got the encrypted data and
signature in line 2 to line 6, it verifies John's
signature and data integrity. According to the system
log, verifying succeeded. After verified the signature
data (Raghavan, 2000) and integrity, ACME use its
private key to obtain the clear data in the first part,
and then use public key of the BANK to encrypt.
Finally, ACME appends its signature to the data
In the line 10 to line 16, the data is the output of
ACME, and also input of BANK. The data contains
three parts, which also use the keyword "SDO" to
separate. The first part is the data encrypted with the
public key of BANK. The second part is the
signature data obtained from the digest of account
transfer amount which signs with John’s private key.
The third part is signature of ACME. Once gets the
data, the bank will decrypt it to clear data, “10000”.
According to the log, the decryption succeeded and
the clear data of amount was found. Then, the bank
will verify the signature of ACME and it of John.
According to the log, the two works are all
successful, too. After completion of these works,
BANK will treat with the account of John.
According to the operating data and analysis
above, we can conclude that, the SDO data in
SOA-SCA environment achieved the goal of data
confidentiality, integrity and non-repudiation on the
way from producer to consumer.
5.3 Analysis for System’s Performance
Although the system added some extra processing
and extra data which increased network traffic to
guarantee the secrecy, integrity and undeniably of
the SDO data, the hardware of the servers and the
bandwidth been has greatly enhanced. Also, we
processed only confidential data when carrying out
the system. So, comparing with not having these
extra operations and data, system's performance has
not large scale reduction.
SOA has greater openness, flexibility and scalability
than traditional applications. Meanwhile, security
issues of SOA bring about greater challenge. Any
person or computer in any time and any place can
visit the service as long as it follows the standards.
SCA is an application framework based on SOA.
SDO is the data model based on SCA. This paper
designed the solution to guarantee confidentiality,
integrity and non-repudiation of SDO data when
calling the SCA application, and then achieved it
using WID, WPS.
Ben MargolisandJoseph Sharpe, 2007. SOA for the
Business Developer: Concepts, BPEL, and SCA, MC
Press, First Edition.
Matt Bishop, 2004. Introduction to Computer Security,
Addison-Wesley Professional
Wenbo Mao, 2003 .Modern Cryptography: Theory and
Practice, Prentice Hall PTR
Abdul Allam, Ali Arsanjani, 2008. Service-Oriented
Modeling and Architecture”, Technical paper of IBM
Global Services. Version 2. 14-34.
Murdoch Mactaggart, 2001. Introduction to Encryption,
IBM developerworks, China
Raghavan Srinivas, 2000. Security’s Evolvement and Idea
of Java, IBM developerworks, China