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
• 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