Downloaded 53 times
![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"
}
]
}](https://image.slidesharecdn.com/soasecuritysecrays-150319085449-conversion-gate01/85/SOA-Security-18-320.jpg)
SOA Security
- 1.
- 2. 2 • SOA Technologies •Security in SOA Architecture • XML threats • Secure mobile service integration
- 3. • 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
- 4. 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
- 5. 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
- 6. Security standards forSOAP • 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
- 7. 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
- 8. Encryption • Encryption isthe 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
- 9. Digital signatures • Integritymeans 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
- 10. Digital Certificates • Nonrepudiationmeans 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
- 11. Authentication 1/2 • Multipleauthentication 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
- 12. Authentication 2/2 • TheOASIS 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
- 13. OAuth • Authorization frameworkfor 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 Javascript notation
- 14. Policy Enforcement • Authorizationdecisions 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
- 15. PEP, PDP • Architectureshould 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
- 16. Protecting services • InSOA 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
- 17. XML Threats 17 • XMLEntity 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
- 18. To REST ornot? • 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" } ] }
- 19. Gateway architecture • Howdo 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
- 20.
- 21.
- 22. • Insecure DataStorage • 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- Based Attacks SQL Injection Cross Site Scripting Parameter Tampering Cookie Poisoning Web Application Security WebServer Storage Network Business Applications Computing Infrastructure Email CRM Finance App Server Information Leakage Hybrid app Native code browser OWASP mobile top 10 Risks Client/ device security Local store
- 23.