Enterprise Security Patterns for RESTful

Web Services

Francois Lascelles

Technical Director, Europe

Agenda

Why REST matters to the Enterprise?

Enterprise security requirements for RESTful web services

REST security patterns

Moving beyond point-to-point

Web services in the Enterprise

3

WS-* RESTful

• Enterprise integration (EI) background

• SOAP, WSDL, UDDI

• Sophisticated infrastructure available today

• Web background

• Web API, SAAS, Cloud

• Lightweight

service

orientation enablers

(both styles matter)

Today’s Enterprise SOA landscape

4

enterprise boundary

SAAS

Cloud deployed

services

SAAS

enterprise SOA

• Sensitive data, apps

• Mission critical

• ID authority

• Legacy

partner

REST fits the new extended Enterprise SOA

5

Today’s enterprise SOA extends beyond the enterprise boundary

- Services on-premise/off-premise

- External service providers, partners, public APIs

- Multiple identity domains and authorities

This distributed SOA is increasingly aligning with the web

- RESTful Web services as an architectural style fits this trend

The enterprise consumes external RESTful web services

The enterprise needs to expose its own RESTful web services

Enterprise requirement: Threat protection

Some RESTful web services are ‘public’ and require no

authentication/authorization mechanisms

Regardless, all RESTful services are subject to threats

Service orientation => multiplication of threats

6

Web Threats WS Threats

RESTful web service threats

• parser attacks

• SQL/CODE/LDAP injections

• DOS, MITM, malware, buffer

overflow, replay, …

Enterprise requirement: Access Control

Authentication

Authorization

Integration with enterprise identity infrastructure

- IAM, STS, LDAP

Trust management

Brokered authentication, federated identity

Brokered authorization

7

RESTful Security

Security applied to RESTful web services must align with REST

principles

- Statelessness (no server sessions, no cookies)

- URI uniquely identifies resources

- Cachable

- Use existing HTTP concepts like Authorization header, appropriate HTTP

status codes, etc

Security aware of REST concepts

- Access control which considers HTTP verbs, URI patterns, cache duration

8

Ex. A basic REST authorization pattern

Resource GET PUT POST DELETE

/foo/* ok forbidden forbidden forbidden

/bar/* ok ok ok ok

/baz/* ok ok ok forbidden

9

Simple authorization rule based on URI pattern (resource) and

HTTP Verb (action)

Ex. Identity based response pattern

10

GET /account

Authorization: [joe’s passwd]<account name="joe”

…>

GET /account

Authorization: [bob’s passwd]<account name=”bob”

…>

Message level integrity (?)

WS-*

transport

transport headers

message

soap headers

soap body

(payload)

transport

transport headers

resource

(payload)

REST

Self contained

message

independent from

transport layerAction and

resource identifier

in transport

sig

sig

sig

?

2-party authentication/authorization

12

Requester provides its own credentials

The RESTful web service controls access to resources

Resource

GET/PUT/POST/DEL

ETE with credentials

Requester RESTful web service

SSL

The ‘obvious’ fit

- SSL is de-facto security for the web

- RESTful

Addresses many security requirements

- Confidentiality, integrity

- Endpoint authentication

- Client authentication (with ssl mutual or http basic/digest)

Limitations

- Point-to-point

- PKI Burden (?)

- Does not provide non-repudiation

13

Proprietary schemes

Grassroots enterprise REST initiatives often rely on

proprietary/point-to-point authentication schemes

- Browser-friendly account id in query parameters

- Web-style login forms and sessions

Many PAAS and Web API management solutions also define their

own authentication schemes

- Often related to their subscription model (account ids, account keys)

14

Ex. Azure storage REST API

PUT /somewhere/someresource

…

Authorization: SharedKey accntname:fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=

…

15

HMAC signatures in Authorization header using a key associated

with account

- Signature covers URI, certain headers and payload’s md5

- Potential end-to-end integrity (although proprietary)

EX. Amazon S3 REST API

16

PUT /somewhere/someresource

…

Authorization: AWS keyid:fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=

…

Almost the same thing (yet incompatible)

- Different scheme name

- Different string to sign order and contents

3-party access control

An application accesses a resource with the authorization of its

owner

17

Resource

providerApplication

Resource

owner

Do something

with my resourceYes, I authorize it

Retrieve resource with

owner authorization

(REST exchange)

OAuth

A standard solution to a common scenario

- Standard protocol and authorization token

- User grant access to its resource, not its credentials

- Already implemented by numerous platforms and services: google, twitter,

salesforce, …

- OAuth 1.0 (rfc5849) -> OAuth WRAP -> OAuth 2.0

18

GET /somewhere/someresource

…

Authorization: OAUTH fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=

…

OAuth Enterprise pattern

SaaS/PaaS composition pattern

- Enterprise subscribes to multiple SaaS and needs them to integrate

- Addresses critical challenge related to enterprise cloud adoption

19

SaaS BSaaS A

Enterprise user

subscribing to SaaS A

and B

Do something

with my resource

at SaaS B

Yes, I authorize it

SaaS A and B integrate on

behalf of enterprise user

through OAuth + REST

OAuth Enterprise pattern

Authorize access to enterprise resource

- OAuth-enabled SaaS/PaaS can also retrieve resources hosted by enterprise

20

Enterprise boundary

SaaS

PaaS

Yes, I authorize it

Call back enterprise

retrieves resource,

through OAuth + REST

Protected

resource

Do something with

my resource at

http://myenterprise

Enterprise OAuth

authorization server

Federated authentication

21

RESTful

serviceRequester

Identity

Authority

Authenticate, get

token back

Consume service with

token from trusted

issuer

Trust relationship

Requester does not have credentials recognized by service but

accessed by authenticating with an identity authority trusted by

the service provider

Essential pattern for B2B interactions

Federated authentication

Also a crucial pattern to avoid identity silos related to enterprise

cloud usage

Visibility and control for enterprise access of external services

22

Enterprise boundary

SaaS

Authenticate

locallySaaS instance configured

to trust enterprise issuing

authority (STS)

Enterprise

IAM

Enterprise STSAccess SaaS with

token issued by

enterprise

Federated authentication and REST

OpenID

- Web focused

- Browser driven (interactive steps, redirects)

SAML

- Enterprise focused

- Has browser profile binding very similar to OpenID flow

- Has other bindings (such as ws-security) and is extensible

RESTful/API friendly federated authentication

- No redirects

- No interactive steps

- Don’t expect a browser

23

Example SAML binding for RESTful web service

24

GET /token/joe

Authorization: …200 OK

<saml:Assertion …

/>

GET /someresource

Authorization: SAML PmfrTLJwMuZurA8=

200 OK

…

(not

standardized)

Decoupling security from service

Service orientation is about agility

More security decoupling = more agility

25

decoupling

Security in

application

logic

Security

as a Service,

Gateways

ag

ilit

y Agent

solutions

Container

security

X

X

X

X

Perimeter security implementation

26

RESTful

service zoneRequesters

Delegate security responsibilities

to specialized perimeter

infrastructure

Perimeter security benefits

Avoid duplication of responsibilities across all service endpoints

Threat protection

- Additional abstraction layer camouflages service implementation

- Safe detection of parser attacks, injections

- Safe input sanitization (XML Schemas, JSON Schemas)

Uniform centralized trust management acting on behalf of

services

Uniform identity authority acting on behalf of services

Efficient use of resources (performance)

Reconcile caching and security

27

Apply Enterprise REST security patterns

Enable REST developers by providing REST-capable security

infrastructure and process

Demand and favor standard and interoperable security

mechanisms from your providers

Avoid identity silos

- REST-enable your perimeter identity infrastructure

Decouple security from application logic

- Centralize access control, validation and threat protection

28