SOA Security

Pauli Kauppila

2

• SOA Technologies

• Security in SOA Architecture

• XML threats

• Secure mobile service integration

• Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation

• Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services

• A service:• Is a logical representation of a repeatable

business activity that has a specified outcome• Is self-contained• May be composed of other services• Is a “black box” to consumers of the service

The Open Group

SOA Technologies

• Technologies (XML)– SOAP

• Simple Object Access Protocol protocol specification for exchanging structured information in the implementation of Web Services in computer networks.

– WSDL• Web Services Description Language interface description language

that is used for describing the functionality offered by a web service

• XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information

– UDDI• Universal Description Discovery and Integration XML-based registry

specification describing how Web Service providers can publish a WSDL and how consumers can find it

4

SOA Technologies

• REST

– Representational State Transfer has become a way of building SOA with Web 2.0

– RESTful Web Services can support other marshalling types besides XML, most notably JSON

– RESTful WS has become popular because of simplicity

5

Security standards for SOAP

• The OASIS WS-Security standard

• An extension to SOAP specs

• WS-Security standard defines the structure of an XML document and the rules and mechanisms that can be used to enable communication between applications

Security building blocks

• It is common to divide security into logical views to help focus and understanding

• In this presentation we look at SOA security aspects using these views

7

Confidentiality

Integrity

Nonrepudiation

Authentication

Authorization

Availability

Encryption

• Encryption is the main building block for confidentiality

• Multiple ways of implementing encryption in SOAP XML– Symmetric and asymmetric – SOAP over HTTPS

• SSL encryption between client and server network traffic• SSL encryption includes both symmetric and asymmetric

techniques

– XML Encryption for SOAP XML• XML Element and its contents• Content of an XML Element

• Computationally encryption/decryption is very “expensive”

• What is the level of required confidentiality?– What are the risks involved?– SOA services usually involve multiple multiple

processing parties both inside and outside the organization

Integrity

Nonrepudiation

Authentication

Authorization

Availability

Confidentiality

Digital signatures

• Integrity means that message data can not be not be changed en route to receiver

• Note that encryption alone does not guarantee integrity

• In SOAP XML this boils down to creating a document hash and encrypting it with sender’s private key– The data can be encrypted and packed

after signing to enforce confidentiality

• Signing documents digitally leads to nonrepudiation

Nonrepudiation

Authentication

Authorization

Availability

Confidentiality

Integrity

Digital Certificates

• Nonrepudiation means that the sender can not claim to have sent a certain message– Sender uses her private key to sign a document– To verify the signature, sender’s public key must be

available• And here digital certificates come in to play

• Within SOAP XML the sender can attach her digital certificate to the message– The receiver can use this certificate to obtain sender’s

public key to verify the signature

• Basically using digital certificates is a matter of trust– You trust the entity that signed the certificate, the

Certification Authority

• Certificates might be revoked before their actual validity period ends– The revocation checks must be in place for any SOAP

XML solution relying on certificates

Authentication

Authorization

Availability

Confidentiality

Integrity

Nonrepudiation

Authentication 1/2

• Multiple authentication methods have been tried in the past– Straightforward (shared secret + hash) still current

• Digital certificates can be used for authentication• OASIS WS-Security standard for Web Services defines

multiple token profiles that can be used for authentication– Username Token Profile– X.509 Token Profile– SAML Token Profile– Kerberos Token Profile– …

• Username Token Profile– Username&password combination, very commonly used– PasswordText: Sent in clear, not signed, no replay mitigation– PasswordDigest: used in combination with nonce and

timestamp_created offers a basis to prevent replay attacks– In any case, you should always encrypt the message channel

• Using unsigned token does not introduce nonrepudiation

Confidentiality

Authorization

Availability

Integrity

Nonrepudiation

Authentication

Authentication 2/2

• The OASIS SAML (Security Assertion Markup Language) specification defines how different trust assertions can be used with XML– SAML is based on an idea of separating the authentication

and authorization services from the entity providing the services

• Besides authentication, SAML deals with attribute and authorization assertions– Authorization decisions can be made by detecting subject

information in an authenticated attribute assertion

– This involves Policy enforcement and decisions processes

OAuth

• Authorization framework for permitting access to resources via authorization server

• Service provider trusts a separate authorization service, which grants access tokens to client– Centralized approach to identity

management

• Similar to SAML in the idea of AA separation from the service provider– But when SAML is based on SOAP &

XML, OAuth leverages Javascriptnotation

Policy Enforcement

• Authorization decisions should be based on clearly defined policies

• Hence SOA service provider architecture should also have clearly defined Policy Enforcement and Decision points

• The PEP (Policy Enforcement Point) is a system or application that protects the resources– It sends requests to the PDP (Policy Decision

Point)

• XACML (eXtensible Access Control Markup Language) provides both a policy language and a access-control request/response language

Availability

Confidentiality

Integrity

Nonrepudiation

Authentication

Authorization

PEP, PDP

• Architecture should support consumer and service based decisions– Different SLAs for different

consumers– Configurable levels of trust for

different consumers

• Service policies might be based on requested resource, service context or their combinations

• Policy Information Point is an abstraction for external directory– Centralized identity management

system

• You should also plan for exception and error handling situations early

15

Protecting services

• In SOA world we are opening exposing system services via explicitly defined interfaces which represent contracts between the provider and requestor

• In robust environment we should take into consideration possible contract breaches

• XML-based messages introduce a wide variety of threats (next slide)– These are notoriously difficult to handle

efficiently – Specially with Java based application servers– Performance problems easily lead to lowering

the level of validation processes, or even removing them

Confidentiality

Integrity

Nonrepudiation

Authorization

Authentication

Availability

XML Threats

17

• XML Entity Expansion and Recursion Attacks

• XML Document Size Attacks

• XML Document Width Attacks

• XML Document Depth Attacks

• XML Wellformedness-based Parser Attacks

• Jumbo Payloads

• Recursive Elements

• MegaTags – aka Jumbo Tag Names

• Public Key DoS

• XML Flood

• Resource Hijack

• Dictionary Attack

• Message Tampering

• Data Tampering

• Message Snooping

• XPath Injection

• SQL injection

• WSDL Enumeration

• Routing Detour

• Schema Poisoning

• Malicious Morphing

• Malicious Include – also called XML External Entity (XXE) Attack

• Memory Space Breach

• XML Encapsulation

• XML Virus

• Falsified Message

• Replay Attack

• …others

To REST or not?

• REST simplicity is appealing– Implementing a SOAP/SAML

authentication/authorization scheme is not necessarily a trivial exercise

• With Web 2.0 REST w/JSON has become a de facto standard

• The bottom line is that REST just does not have the same security standards as you have within SOAP with WS-Security– RESTful services are point-to-point solutions

• Large organizations will have legacy SOAP– Should they turn to REST?

{"firstName": "John","lastName": "Smith","age": 25,"address": {

"streetAddress": "21 2nd Street","city": "New York","state": "NY","postalCode": 10021

},"phoneNumbers": [

{"type": "home","number": "212 555-1234"

},{

"type": "fax","number": "646 555-4567"

}]

}

Gateway architecture

• How do you protect your assets and legacy services BUT at the same time utilize your existing systems and applications?

• How do you Web 2.0 enable your services securely?

• One solution is to expose services via gateway or enterprise bus

Gateway

GatewayExternal service

consumers/partners

Internalservices

•AAA•Encryption•Digital signatures•Message validation

•AAA•Encryption•Transformations

Gateway provides protocoltransformations

SOAP clients

• Insecure Data Storage• Client side injection• Side channel data leakage• Broken crypto

Web Application Security – DataPower for (Mobile) Application Security applied to mobile

• Weak server side control• Improper session handling• Security decisions via untrusted input• Sensitive information disclosure

22 Source: IBM

• Insufficent transport protection• Poor authentication & authorization

Pattern-BasedAttacks

SQL Injection

Cross Site Scripting

Parameter Tampering

Cookie Poisoning

Web Application Security

WebServer

Storage Network

Business Applications

Computing

Infrastructure

Email CRM

Finance

App

Server

InformationLeakage

Hybrid app

Native code

browser

OWASP mobile top 10 Risks

Client/device security

Local

store

Thank you!

Pauli Kauppila

pauli@secrays.com

@pkauppila