Secure SOA Web Services - Conferences

Secure SOA Web Services Dipen Valani

T.M.Bansod

Aarti Karande

Department Computer Engineering VJTI, Mumbai [email protected]



Abstract— The main purpose of this paper is to create an integrated model for a secure environment shaped by Service-oriented Architecture (SOA). SOA/WS are exposed outside an organization’s boundaries, the risk of targeted malware threats goes up dramatically, therefore organizations need to both secure against SOA/WS threats while simultaneously uniquely controlling access for separate SOA/WS client applications and organizations. In this paper the proposed model use the security services standards to secure the webservices. Keywords-SOA (Service Oriented Architecture); ESB (Enterprise Service Bus); xml; Webservices; SOAP(Simple Object Access Protocol); SAML(Security Assertion Markup Language). I.

INTRODUCTION

The Service Oriented Architecture is now accepted by many companies, because of its loosely coupled natures and it openly access the HTTP, so SOA require security aspects. First we look at the some of the basic service oriented architecture before diving into security factors. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification.

DCOM is the acronym for the Distributed Component Object Model, an extension of the Component Object Model (COM). DCOM was introduced in 1996 and is designed for use across multiple network transports, including Internet protocols such as HTTP. DCOM is based on the Open Software Foundation's DCE-RPC spec and will work with both Java applets and ActiveX components through its use of the Component Object Model (COM). It works primarily with Microsoft Windows[2]. A. Structure of SOA Services are offered and published by a service provider who acquires the business processes. The services are designed to be easily published and discovered through a service registry such as the Universal Description, Discovery and Integration (UDDI) platform by registering its abstracted Web Service Description Language (WSDL) file within that platform. The service consumer can search the UDDI for the services he/she needs. Once the service consumer finds the required services, he/she sends a request to the service provider asking for access to those services.

CORBA is the acronym for Common Object Request Broker Architecture. It was developed under the auspices of the Object Management Group (OMG). It is middleware. A CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network. The first service-oriented architecture for many people in the past was with the use of Object Request Brokers (ORBs) based on the CORBA specification. The CORBA specification is responsible for really increasing the awareness of service-oriented architectures[1].

Figure 1. The main structure of SOA The service consumer and provider exchange request/response messages through the use of protocols such as Simple Object Access Protocol (SOAP). Figure 1 depicts the basic structure of SOA [3].

Proc. of the International Conference on Science and Engineering (ICSE 2011) Copyright © 2011 RG Education Society ISBN: 978-981-08-7931-0 499

Proc. of the International Conference on Science and Engineering (ICSE 2011)

B. Security in the service-oriented life cycle An important facet of service orientation is an emphasis on the entire life cycle of IT systems—from conception to ongoing operation and management. Service orientation aims to better align business and IT goals and to provide a greatly improved capability to deal with change. Refer to Appendix B, “IBM SOA Foundation” on page 415 for more information about the SOA life cycle model

Deploy In this role: •

Application administrators install the applications and work with security developers and security administrators to configure the applications and associated security policies.

Manage In this role: •

IT and security administrators manage the security policies across a set of applications and infrastructure to meet the requirements, which can continue to change over time.

•

Operators monitor the system behavior for compliance and detect situations that are potential security threats and feed them back to administrators to make changes as required.

•

Business analysts view business dashboards to assess the impact to the business due to certain system security events.

•

Security auditors assess the system’s compliance with regulatory and corporate policies.

Security encompasses all aspects of the life cycle As shown in Figure 1-7, certain roles in an organization contribute toward the creation, definition, refinement, monitoring, verification, and management of security policies during the execution of the serviceoriented life cycle.

It is significant to observe that security policies are specified and refined throughout the life cycle, undergoing transformation from one phase to the next[4]. II. SOA SECURITY LOGICAL ARCHITECTURE Figure 2 Service-oriented life cycle from a security perspective Model In this role: •

Corporate security officers and equivalent executives define corporate security policies and outline regulations with which the business must comply.

•

Business analysts work with security policy officers to translate corporate security policies into terms of a business vocabulary and process.

Assemble In this role: •

Application and security architects model the security policies, based on choices provided by the business analyst.

•

Application programmers and administrators factor in these security policies by declaring the requirements for the infrastructure to enforce. When the infrastructure support is not sufficient, the security policy can be implemented in the applications.

In Fig. 3 shows the typical logical SOA deployment architecture. The Web application/portal server leverages existing applications/services either directly or through an ESB. Clients can be users or service consumers, both internal and external. Similarly, existing applications/services can be either internal or external. In this type of a deployment, security is enforced at various points within the architecture. The proxy can enforce confidentiality and integrity, identity validation, authentication, and auditing. Additional security checks, auditing and authorization can be enforced into the application server.[5] IT Security Services can be used by different components in an SOA environment. The use of common IT Security Services enables a consistent security implementation. IT Security Services include Identity Services, Authentication Services, Authorization Services, Confidentiality Services, Integrity Services and Audit Services.[5]

500


III. SECURING SOA SERVICES In this section, I proposed the architecture that secures access to services by inspecting the security information contained in the XML documents submitted by the service consumers. Using the set of SOA standards the centralized security policies bound to user identities to provide XML threat prevention, authentication, authorization, federation, session management and security auditing services. The global and pervasive security requirements of any given information system are Confidentiality, Integrity and Availability. The main key point to secure the SOA is to preserve the Confidentiality, Integrity and Availability of an organization’s information processing

Figure 3. Typical logical deployment architecture for an SOA application.[4] In many other ways the enterprise security requirements of SOA/WS are very familiar. In general, organizations have the following goals:

WŽůŝĐǇ ^ĞƌǀĞƌ

• Message Integrity- Ensuring that messages have not been tampered with

3 SERVICE REQUESTOR

• Message Privacy- Making sure the message is encrypted for confidentiality

1

ƵƐƚŽŵĞƌͬ ƉƉůŝĐĂƚŝŽŶ

2

tĞď WŽƌƚĂů

INTERNET

5

• Authentication- Discerning the identity of the requester TABLE I.

Standards

Authorization Services

XACML, JACC, and WSFederation

Confidentiality and Integrity Services

WS-Security, WSSecureConversation, PKI, XKMS, WS-SecurityPolicy, SSL/TLS, JSSE/JCE, XML Signature, and XML Encryption

(Authorization) XML/SOAP REQUEST

5

tĞďͲ ^ĞƌǀŝĐĞƐ ƉƉůŝĐĂƚŝŽŶ ^ĞƌǀĞƌ 4 5

SECURITY SERVICES STANDARDS

Security Service

Secures Web service traffic and website traffic

XML+ WS-SECURITY SAML (Confidentiality )

INTERNET

tĞďͲ ƐĞƌǀŝĐĞƐ SERVICE PROVIDER

Figure 4. A “Security Enhanced” SOA Interaction Model Fig4. Shows the security enhanced SOA interaction model for accessing web services securely. Step 1 is just for interaction of ant application or customer to the application related portal.

• Authorization- Deciding the level of entitlement that the requesting application or user should have

Step 2, now portal based application makes a SOAP call to main web service application server.

• Federation: Securely linking sessions across security domains

Step 3, Session get validate and authorized by Application server’s SOA agent and policy server secures Web service traffic and website traffic

• Auditing and Reporting- Keeping track of what has and is happening from a security point of view in the environment

Step 4, Generates WS-Security/SAML token and adds it to SOAP Header of request for the next step in the Web service. Username, X.509, SAML, and Kerberos security tokens are inserted in WS-Security headers in a standard way

• Malware Threats- Keeping out requests that are looking to disrupt the usage of services or steal private data.[6]

501


For example, a SOAP message using a SAML assertion would look like this: ... ... In this case, SAML assertions and references to assertion identifiers are contained in the element, which in turn is ncluded in the element IV. CONCLUSION In the proposed service-oriented architectures has introduced the need for additional standards to help support the new security challenges involved with enabling a standards-based SOA/WS security.so after introducing this standards into SOA architecture the system becomes fully secured against threats. REFERENCES [1] [2] [3] [4]

[5]

[6]

http://www.service-architecture.com/webservices/articles/corba.html dated on 08/11/2010. http://www.service-architecture.com/webservices/articles/dcom.html dated on 08/11/2010. E. Newcomer and G. Lomow, Understanding SOA with Web Services, Pearson Education, Inc., USA, 2005. A. Buecker, P. Ashley, M. Borrett, M. Lu, S. Muppidi, and N. Readshaw, “Understanding SOA Security Design and Implementation,” 2rd ed., IBM Corp., pp. 1-124, pp. 393-444, November 2007. Marzieh Asgarnezhad, Ramin Nasiri, Saeedreza Sahebhonar, “Analysis and Evaluation of Two Security Services in SOA,” Islamic Azad University, Kashan branch, Iran. Michael Menzel, Christoph Meinel, “A Security Meta-Model for Service-oriented Architectures,” Hasso-Plattner-Institute, Germany.

502