Security in Service Oriented and REST architectures

SiliconIndia Java Conference, Nimhans, Bangalore

29 Oct 2010

Srinivas Padmanabhuni, Ph.D.Principal Research ScientistSETLabs, Infosys Technologies Ltd.Bangalore, India.srinivas_p@infosys.com

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 Sem

antics

(XS

D)

2. Input Sem

antics

(XS

D)

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 Aspect What it means Accessibility Is the system hack-proof?

Authentication How do I know your identity is true?

Authorization Are you allowed to perform this task?

Confidentiality Are we sure that nobody has read the data?

Integrity Is the data you sent the same as the data I received?

Non-repudiation Both 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 SecurityFeatures Issues Remarks

SSL AuthenticationEncryptionIntegrity

Point to PointOnly HTTP basedLack 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 AuthenticationAuthorizationSingle Sign On

Need for infrastructure for auth appsNo 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 SSOPerformance 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

Berecognized

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