Security in Service Oriented and REST architectures SiliconIndia Java Conference, Nimhans, Bangalore 29 Oct 2010 Srinivas Padmanabhuni, Ph.D. Principal Research Scientist SETLabs, Infosys Technologies Ltd. Bangalore, India.

2 Security in Service Oriented and REST architectures Brief Intro to WS Style SOA Brief Intro to REST Security Requirements of SOA SOA Threat Profile Why SSL is not good enough for SOA SOA Security Standards Application (XML) Firewalls REST Security Considerations BEST Practices for REST Security Conclusions

3 WS Style SOA A Web Service is a unit of software that: Processes XML messages framed using SOAP Describes its messages using XML Schema Provides an interface description using WSDL Can be discovered using UDDI (optional) Is transport independent (HTTP/JMS/SMTP…) These are not web services (though they may qualify as services) ….. XML over HTTP (or any other transport) XML over MQ/JMS

4 SOA in Action with WS Requester Requester Entity Requester Agent Provider Provider Entity Provider Agent 2. Input Semantics (XSD) 2. Input Semantics (XSD) 3. Get WSDL 4. Interact (SOAP) Source: W3C Web Services Architecture Group 1. Agree on Semantics (XSD) Discovery Agent (UDDI) (Optional) Publish WSDL (Optional) Find WSDL (Optional)

5 REST "REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.“ Roy Fielding, UCI Ph.D Thesis, founder of REST In REST, basic concept is that of a resource We need to Model each document and each process as a “resource” with a distinct URI Works with HTTP as the protocol Uses HTTP “verbs” to interact with the resource: –GET: Retrieve a representation of a resource. –DELETE: Remove a representation of a resource –POST: Create or update a representation of a resource –PUT: Update a representation of a resource In Practice, GET is used, even for update operations Everything is in “Query String”

6 Security Aspects of SOA – Generic. Security AspectWhat it means AccessibilityIs the system hack-proof? AuthenticationHow do I know your identity is true? AuthorizationAre you allowed to perform this task? ConfidentialityAre we sure that nobody has read the data? IntegrityIs the data you sent the same as the data I received? Non-repudiationBoth sender & receiver can provide legal proof to a third party that -the sender did send the transaction, and - The receiver received the identical transaction

7 Single Sign-on : Capability to leverage one state of signed in to be used at multiple applications Federated Trust/identity: Being able to pass on the same credentials to a subordinate in some circumstances (federation) Prevention from Repeated Attacks: Capability to prevent application level repeat attacks Preventions from malicious attacks: Capability to prevent malicious application invocations Security Mechanisms Interoperability: Capability of one security system to talk to another Security Aspects of SOA.Specific..

8 SOA Threat Profile

9 Why SSL is not good enough for Web Services Intermediaries – SSL provides point to point whole message encryption. Intermediaries need encryption of parts of messages so that parts can be read Two-Way Authentication - Client Side SSL required for two- way credential management however is very difficult to manage, hence SSL is not suitable for authenticating all kinds of web services clients Authorization – SSL does not handle authorization issues at all Federation – SSL has no mechanism for federation of web services security credentials which is very necessary in distributed web services environments

10 SOA Security Standards Stack

11 Base Web Services Standards – XML Signature/Encryption XML Signature Capturing Digital Signature in XML Documents Enables partial signing of documents Canonical form of XML used XML Encryption Allows encryption of partial XML documents Encrypted info is an XML node in the transformed document

12 Other Important Standards for Web Services Security FeaturesIssuesRemarks SSL Authentication Encryption Integrity Point to Point Only HTTP based Lack of partial encryption If using only this then should be used only in intranet web services scenarios, otherwise use in combination with other technologies. Use in internet only if no intermediate nodes present. SAML Authentication Authorization Single Sign On Need for infrastructure for auth apps No built in support for Encryption Good for single sign- on. Currently supported by multiple identity management products. WS-Security Authentication, Authorization Integrity, Encryption, Non Repudiation. Support for username/passwd, kerberos, certificates. No support for SSO Performance issues as each message exchange need to be secured independently Overall security provided, must use in case of web services with intermediate nodes.

13 Federated Identity Sample Use Case – Cross Domain Authentication Standards : Liberty, WS- Federation/SAML2.0 Distributed data stays with “rightful” owner Multiple authenticators –Competition for consumer trust Delineation between authentication and authorization –Merchant retains control of transaction requirements –Gradient levels of authentication within network Consumer is in control of who can access information Log in Be recognized Excite.com Pets.com

14 Application Level and XML Firewalls Unlike conventional firewalls, new generation firewalls do not work at packet filtering level Capable of SOAP content inspection Can detect SOAP level repeated / malicious attacks DOS detection Good to deploy at the enterprise gateway Both in Hardware and Software Common vendors are Westbridge, Reactivity etc Capable of handling XML security standards

15 A typical Enterprise SOA Security Scenario

16 REST Security Considerations REST does not have predefined security methods so developers define their own Most APIs handle authentication using a key but no secret, essentially requiring a user name but no password Using HTTP basic authentication (with no SSL) and letting the user name and password cross the wire with no encryption. Need to protect against typical Web threats like XSS, XML/JSON content manipulation, DoS attacks, session hijacking attacks etc.

17 Best Practices for REST Security Extend Web security mechanisms for your REST APIs Deploy Access Control Rules to Methods Validate Validate Validate QUERYSTRING Add a password requirement in addition to API Key (enable a shared secret) Don't pass unencrypted static keys. Encrypt any HTTP Basic communication Use hash-based message authentication code (HMAC) using SHA-2 or above (Used in S3 and other AWS) Check for XML firewalls additional capability for JSON and other REST content filtering

18 Conclusions SOA both WS style and REST style require flexible security mechanisms beyond SSL XML firewalls are crucial REST is mere extension of HTTP so treat it like Web application security SOA WS* deploy standards where possible for maximum interoperability REST – Deploy content inspection thoroughly for Querystring REST – Use multiple factors, and encrypted content Extend XML firewalls for REST content like JSON