Whitepaper

Disclaimer: The information provided in this document is provided "AS IS" WITHOUT ANY WARRANTIES OF ANY KIND INCLUDING WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT OF INTELLECTUAL PROPERTY. SOA Software may make changes to this document at any time without notice. All comparisons, functionalities and measures as related to similar products and services offered by other vendors are based on SOA Software's internal assessment and/or publicly available information of SOA Software and other vendor product features, unless otherwise specifically stated. Reliance by you on these assessments / comparative assessments are to be made solely on your own discretion and at your own risk. The content of this document may be out of date, and SOA Software makes no commitment to update this content. This document may refer to products, programs or services that are not available in your country. Consult your local SOA Software business contact for information regarding the products, programs and services that may be available to you. Applicable law may not allow the exclusion of implied warranties, so the above exclusion may not apply to you.

Whitepaper

Security Issues

In the SOA

SOA Software, Inc.

12100 Wilshire Blvd, Suite 1800 Los Angeles, CA 90025 866-SOA-9876 www.soa.com [email protected] Copyright © 2005 by SOA Software, Inc.

www.soa.com Copyright © by SOA Software, Inc. 2005. All rights reserved. 1

Table of Contents 1. Introduction........................................................................................ 3

2. Security Problems in the Service Oriented Architecture........................... 4

3. How the SOA Software Service Manager provides end-to-end security in the SOA ...................................................................................................... 7

4. About SOA Software...........................................................................12


“Web services have arrived, but without much security. However, with the right brew of standards and technologies, firms can apply what they already know about security – and put Web services to work for them”

Forrester Research

“Security is the immediate roadblock facing widespread implementation of Web services Technologies across the enterprise.” -

Zapthink Analyst Report

“Attention to security when developing and deploying Web services applications can make the difference between success and disaster.”

XML Magazine


1. Introduction Although the IT community is embracing the new paradigm of the Service-Oriented Architecture (SOA) because of its promise of efficiency and improved IT management, security problems are causing many to proceed slowly, or not at all, with SOA implementations. At the same time, virtually all IT managers are realizing that they must identify and implement security solutions for SOAs soon because their developers are exposing applications as Web services using the new generation of development tools. In addition, many new versions of existing enterprise applications expose numerous Web services upon installation. SOA security is an issue that virtually everyone in corporate IT is going to have to deal with in the near term.

The SOA’s inherent security problems stem from the ways in which the SOA replaces traditional security parameters with new, open standards. The security problem is twofold in that not only are the new standards completely open – no one owns them – but they were also developed without security in mind.

This paper examines the nature and causes of SOA security risks and identifies ways in which the SOA Software Service ManagerTM (SERVICE MANAGER) addresses those risks. SOA Software is focused on providing secure and manageable SOA’s. The Service Manager, with its “pipeline” of security features, has been developed to help IT managers implement SOAs with the confidence that the Web services they are exposing will be used securely only by authorized and authenticated users.


2. Security Problems in the Service Oriented Architecture Why do SOAs inherently contain security risks? The answer lies partly in the origins of the SOA. Web services were developed over a period of years by industry consensus as a way to, among other things, enable the creation of reusable code, simplify development, and streamline system integration. While these goals were met, the open standards that emerged neglected to address security. Specifically, XML, SOAP, WSDL, and UDDI are open standards that enable the transmission and description of data and procedure calls between systems. However, none of these open standards contain any inherent security aspects of their own. If left alone, they are completely insecure. In fact, Web services were designed to be able move efficiently through firewalls. Their very openness actually exposes their insecurity all the more.

The nature of the SOA also disrupts the traditional security paradigm in several critical ways:

- Machine-to-Machine communication - Most security infrastructure is geared to human-to-machine interactions while Web services involve scalable machine-to-machine interaction. Unauthorized users may find it simple to penetrate and evade detection in SOAs compared to traditional architectures because they are going after exposed application functionality that has no human screening.

- Securing unknown third parties – By their nature, an SOA may require that an entity authenticate and grant authorization to users from outside its system. To be secure, an SOA must have a way to get inside the security apparatus of an outside user’s system in order to authenticate and authorize use of the service.

- Flooding – Malicious, unauthorized users can “flood” an SOA with service requests and render it inoperable – a Denial of Service attack.

- Unwanted “listening in” – In contrast to traditional architectures that allow messages to be exchanged either exclusively within the firewall or through private networks, Web services message may travel across the Internet where they are vulnerable to eavesdropping by unknown individuals.

- SLA – The SOA has no way of monitoring or assuring the service levels of Web services, crippling the ability of system administrators to identify and respond to security problems in a timely manner.

- No logging – The unsecured SOA has no message and transaction logging mechanism. After a service has been called and used, there is no way to determine who has used the service and from where the request originated. As a result, there is no audit trail that can be used later to investigate possible breaches in security.


- No encryption – The unsecured SOA has no encryption protocol embedded in its architecture. Messages that are intercepted can be read by anyone.

To illustrate the security problems inherent in SOAs, let’s look at the example of a supply chain management process that involves a manufacturer and three vendors. Figure 1 represents the traditional B2B security environment:

- Each trading partner communicates with the manufacturer using a private network.

- Encryption may be used, but the manufacturer and vendor can both be fairly confident that their communication is private.

- Authentication is coded into the application, so the manufacturer can be relatively confident that Vendor A is actually the vendor A.

- Authorization is, in addition to being coded into the applications themselves, also handled by the security infrastructure of the entity originating the transmission.

Though secure, this traditional setup is costly and complex to maintain:

- Modifications to the manufacturer’s application will automatically require custom revisions to the vendor’s application or else they will not be able to communicate.

- Flexibility in extending the functionality of these connected applications is limited to the amount of custom interface development that each trading partner wants to finance.

If the manufacturer and its vendors decide to expose their applications as Web services in an SOA, they benefit from greatly increased flexibility but face security risks. Figure 2 shows what this SOA would look like. Applications developed in this environment have numerous potential functional advantages over the traditional model, including:

- The vendor’s ability to create applications that easily interact with the manufacturer’s ERP system – “pulling” order data out of the system based on anticipated demand.

Manufacturer

Vendor CVendor BVendor A

Firewall Firewall Firewall

Firewall

Accounting

App.ERP App.

ERP App. ERP App.ERP App.

Secure transmission over

private network.

Figure 1

Security infrastructure of a traditional B2B relationship.


- The manufacturer’s and vendor’s mutual ability to process financial matters between their respective accounting systems.

- All of which can be accomplished

o Without needing any proprietary software to create custom interfaces and remote procedure calls.

o Without needing a dedicated private network.

o Without even having to develop any code – it may already exist as a reusable Web service.

Unfortunately, however, the SOA shown in Figure 2 also contains a variety of security risks:

- Because the messages may travel across public networks,

o They can be “listened to” by others.

o They can be intercepted and changed.

o They can be re-routed for the purpose of fraud or malicious mischief.

- Whatever hard-coded authorization process that existed in the traditional model does not exist here. Neither the manufacturer nor the vendor know who is authorized to access specific Web services.

- Whatever hard-coded authentication process that existed in the traditional model does not exist here. A hacker could configure a machine to impersonate a vendor’s system and make erroneous or fraudulent service calls.

- The SOA can be overloaded by service calls, resulting in a DoS attack.

- There is no audit trail to determine who has done what and at what time.

Manufacturer

Vendor CVendor BVendor A

Firewall Firewall Firewall

Firewall

Accounting Web Service ERP WS

ERP WS ERP WSERP WS

Insecure transmission

over public networks

The Internet/Public Networks

Figure 2

Security risks inherent in the transition of the B2B relationship to a Service-Oriented Architecture.


3. How the SOA Software Service Manager provides end-to-end security in the SOA

A basic consumer and provider interaction that uses Web services can be built and deployed quickly, but is not inherently reliable or secure.

To add security in this interaction, the consumer and provider applications need to agree on, implement, and enforce a security

policy, which can include authentication, privacy, integrity, etc. The consumer and provider applications, however, are now

tightly bound as a result of the security policy. The security policy cannot be changed without updating and redeploying the consumer and provider applications.

The SOA Software Service Manager (SERVICE MANAGER) product suite provides a highly configurable and standards compliant end-to-end security solution. SERVICE MANAGER is a Web services security infrastructure that is designed and deployed in alignment to the myriad of security requirements for an organization or B2B network. In the SERVICE MANAGER solution, there are enforcement points, enablement points, and centralized policy management for security and Web services management.

Enforcement Points

The responsibility of an enforcement point is to protect a Web service by enforcing a security policy. Security policies address the “CIAAA - pillars of security” for Confidentiality (message privacy), Integrity (message non-repudiation), Authentication, Authorization, and Auditing. Security policies are defined in a centrally managed SERVICE MANAGER Policy Manager and drive the behavior of the enforcement points, in real-time, if necessary. A Web service request must satisfy the security policy in order for an enforcement point to allow access to a Web service it is protecting.

The policy can be defined as follows:

Request Message must be encrypted (DES, 3DES, RSA) Request Message must be signed (SHA, MD5, DSIG)

Figure 3 The standard SOAP request and response

Requesting

ApplicationWeb Service

Soap Request over HTTP

Soap Response over HTTP


Requestor must be authenticated (SAML, user/password, X.509 certificate, XML-Digital Signature, other forms mapped to SAML credentials)

Requestor must be authorized to use the Web service (SAML, role based, privilege ACL)

Requestor must be “contracted” to use the Web service (time of day, day of week, no. of uses)

Audit all request and response messages for high valued transactions

Enforcement points are implemented as SERVICE MANAGER Management Points, and can be deployed as standalone proxies to the Web service or as embedded Management Points, which run inside the Web service container of the application server (any J2EE or Microsoft IIS application servers). There are a wide range of security use cases that will incorporate a combination of proxy and embedded MP’s. These include use cases for high performance, high throughput, horizontal scalability, high availability, load balancing, protocol bridging, security bridging, multiple security domain support, identity management bridging, etc. In either deployment, the Web service provider is decoupled from the security policy responsibilities

and therefore supports increased reuse since a range of concurrent security use cases are handled by the MP.

Enforcement Point Summary (SERVICE MANAGER Management Point)

As an enforcement point, the SERVICE MANAGER Management Point decouples the Web service provider from changes to security policy

CIAAA – security requirements are enforced Security policy is centrally managed Changes to security standards are isolated from Web service providers Multiple deployment models for the SERVICE MANAGER Management

Point

Figure 4

Management Point as an enforcement point to the Web service. Security Policy is indicated in the red flows.


WS-Security compliant (XML encryption, XML-Digital Signature, SAML, etc.)

Enablement Points

The responsibility of an enablement point is to apply or “enable” security policy to a request message from a Web service consumer application. The enablement point is a client side SDK that the consumer application uses. Through the SDK, the consumer application applies security policy to the outgoing Web service request message, i.e. encrypts, digitally signs, retrieves SAML tokens, etc. The SDK obtains the security policy from the SERVICE MANAGER Policy Manager and automatically applies them to the request message at runtime. A single security policy is used by both the enablement and enforcement points. The enablement point applies the security and the

enforcement point verifies and enforces the security.

The policy can be defined as follows:

Request Message must be encrypted (DES, 3DES, RSA)

Request Message must be signed (SHA, MD5, DSIG) Requestor must be authenticated (SAML, user/password, X.509

certificate, XML-Digital Signature, other forms mapped to SAML credentials)

Requestor must be authorized to use the Web service (SAML, role based, privilege ACL)

Requestor must be “contracted” to use the Web service (time of day, day of week, no. of uses)

Audit all request and response messages for high valued transactions

Figure 5

SERVICE MANAGER SDK as an enablement point for Web services security policy


Request Message Security Policy

What the enablement point does

What the enforcement point does

Encryption Encrypt message Decrypt message

Digital Signature

Sign message Verify signature

Authentication Provide credentials, digital token, certificate

Verify credentials, digital token, certificate

Authorization Provide credentials, digital token

Verify credentials, digital token

Contract Verify contract permissions

Audit Log request / response messages

Enablement points can also be implemented as a client-side Management Point in stand-alone proxy mode. The same functionality is provided as with the SDK but without a footprint on the consumer application.

Key Points

As an enablement point, the SERVICE MANAGER SDK and Management Point decouples the Web service consumer from changes to security policy

CIAAA – security requirements are enforced Security policy is centrally managed Changes to security standards are isolated from Web service consumers Multiple deployment models for the enablement point WS-Security compliant (XML encryption, XML-Digital Signature, SAML,

etc.)


In addition to offering a variety of features that enable service orchestration, monitoring, caching, versioning, context-sensitive business impact reporting, the SERVICE MANAGER provides the following security features through its Management Point:

- Federated Authentication -The Management Point provides a pluggable security authentication and authorization framework for Web services. The framework utilizes SAML, WS-Security and JAAS open standards to implement a flexible, federated security architecture that can be easily integrated into existing enterprise environments, as needed.

- Application Proxy – The Management Point can serve as a highly effective, secure proxy for an organization’s Web services. The Point can decouple and protect both internal Web services from external users and trading partners as well as proxy approved external services to users and applications within the organization.

- SSL – Secure Sockets Layer (SSL) is fully supported by the Service Manager architecture, thereby facilitating 40 or 128-bit secure communications at the HTTP level.

- Contract Management - The Service Manager can be configured to permit access to a service through a service contract. The contract specifies the terms between a service provider and consumer and is associated with an SLA. The contracts can be set up to include:

o Start Date & Time o End Date & Time o Access Count

- Digital Signing – Digital signatures are used to facilitate an implicit trust relationship between a server provider, the consumer and the Management Point. The Service Manager ships with a software development toolkit (SDK) for the creation and validation of digital signatures. Digital signing is done using RSA/DSA signing.

- XML Encryption – An SDK is also available to perform XML encryption at the element level in the SOAP message. This allows service providers to increase the level of security for a particular operation within a service.

- Replay Attack Protection –The Management Point provides services with protection from replay attacks by keeping track of SOAP requests and ensuring that the same request is not replayed. This helps eliminate Denial of Service (DoS) attacks and errors in contract usage & billing.

- Auditing – The Management Point tracks and logs all service calls, thereby providing a mechanism to audit and reconcile all service transactions.


4. About SOA Software SOA Software is the leading provider of comprehensive enterprise-class SOA management, security, and governance solutions. SOA Software’s products include the award winning Service Manager™, Registry™, XML VPN™, and SOLA™. Service Manager provides a high-performance, scalable SOA Management solution. XML VPN makes it easy for companies to securely publish B2B Web services for their partners to consume. SOA Software’s UDDIv3 compliant Registry is the first product to integrate service discovery with policy and performance management. And SOLA is the only production proven mainframe Web services solution for CICS programmers. These enterprise-class products combine to create the only complete SOA Infrastructure solution available today. SOA Software is a privately held company backed by leading investors including Redpoint, Mellon Ventures, Palisades Ventures Fund and Paladin Capital Group. For more information, please visit www.soa.com.

Documents

Whitepaper