This document discusses security patterns for RESTful web services in the enterprise. It begins by explaining how REST fits well with today's extended enterprise SOA landscape. It then covers key enterprise security requirements like threat protection and access control. The document presents several REST security patterns for authentication, authorization, and implementing security while keeping REST principles like statelessness. It also discusses using standards like OAuth, SSL, and SAML to provide security in a RESTful way. Finally, it advocates decoupling security from services through approaches like security as a service.

1. Enterprise Security Patterns for RESTful
Web Services
Francois Lascelles
Technical Director, Europe

2. Agenda
 Why REST matters to the Enterprise?
 Enterprise security requirements for RESTful web services
 REST security patterns
 Moving beyond point-to-point

3. Web services in the Enterprise
• Enterprise integration • Web background
(EI) background
• Web API, SAAS, Cloud
• SOAP, WSDL, UDDI
• Lightweight
• Sophisticated
infrastructure available
today
WS-* RESTful
service
orientation enablers
(both styles matter)
3

4. Today’s Enterprise SOA landscape
enterprise SOA
SAAS
Cloud deployed
services
partner
enterprise boundary
• Sensitive data, apps
• Mission critical
• ID authority
• Legacy
SAAS
4

5. REST fits the new extended Enterprise SOA
 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
5

6. 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
Web Threats WS Threats
RESTful web service threats
• parser attacks
• SQL/CODE/LDAP injections
• DOS, MITM, malware, buffer
overflow, replay, …
6

7. Enterprise requirement: Access Control
 Authentication
 Authorization
 Integration with enterprise identity infrastructure
- IAM, STS, LDAP
 Trust management
 Brokered authentication, federated identity
 Brokered authorization
7

8. 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

9. Ex. A basic REST authorization pattern
 Simple authorization rule based on URI pattern (resource) and
HTTP Verb (action)
Resource GET PUT POST DELETE
/foo/* ok forbidden forbidden forbidden
/bar/* ok ok ok ok
/baz/* ok ok ok forbidden
9

10. Ex. Identity based response pattern
GET /account
Authorization: [joe’s passwd]
<account name="joe”
…>
GET /account
Authorization: [bob’s passwd]
<account name=”bob”
…>
10

11. Message level integrity (?)
WS-* REST
transport transport
transport headers Self contained transport headers
sig
message
message independent from resource
(payload)
soap headers transport layer
sig Action and
resource identifier
soap body in transport
(payload)
?
sig

12. 2-party authentication/authorization
Resource
GET/PUT/POST/DEL
ETE with credentials
Requester RESTful web service
 Requester provides its own credentials
 The RESTful web service controls access to resources
12

13. 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

14. 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

15. Ex. Azure storage REST API
PUT /somewhere/someresource
…
Authorization: SharedKey accntname:fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=
…
 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)
15

16. EX. Amazon S3 REST API
PUT /somewhere/someresource
…
Authorization: AWS keyid:fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=
…
 Almost the same thing (yet incompatible)
- Different scheme name
- Different string to sign order and contents
16

17. 3-party access control
Retrieve resource with
owner authorization
(REST exchange)
Resource
Application
provider
Do something Yes, I authorize it
with my resource
Resource
owner
 An application accesses a resource with the authorization of its
owner
17

18. 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
GET /somewhere/someresource
…
Authorization: OAUTH fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=
…
18

19. 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
SaaS A and B integrate on
behalf of enterprise user
through OAuth + REST
SaaS A SaaS B
Do something
with my resource Yes, I authorize it
at SaaS B
Enterprise user
subscribing to SaaS A
and B
19

20. OAuth Enterprise pattern
 Authorize access to enterprise resource
- OAuth-enabled SaaS/PaaS can also retrieve resources hosted by enterprise
Call back enterprise
Enterprise OAuth
retrieves resource, authorization server
through OAuth + REST
SaaS
PaaS
Protected
resource
Do something with Yes, I authorize it
my resource at
http://myenterprise
Enterprise boundary
20

21. Federated authentication
Consume service with
token from trusted
issuer
RESTful
Requester
service
Authenticate, get
token back Trust relationship
Identity
Authority
 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
21

22. Federated authentication
 Also a crucial pattern to avoid identity silos related to enterprise
cloud usage
 Visibility and control for enterprise access of external services
Access SaaS with Enterprise STS
token issued by
Enterprise
SaaS enterprise IAM
Authenticate
locally
SaaS instance configured
to trust enterprise issuing
authority (STS)
Enterprise boundary
22

23. 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

24. Example SAML binding for RESTful web service
GET /token/joe
Authorization: …
200 OK
<saml:Assertion …
/>
GET /someresource
Authorization: SAML PmfrTLJwMuZurA8=
200 OK
…
(not
standardized)
24

25. Decoupling security from service
 Service orientation is about agility
 More security decoupling = more agility
X
Security
as a Service,
Gateways
Container X Agent
agility
security solutions
X
Security in
application
logic
X
decoupling
25

26. Perimeter security implementation
RESTful
Requesters service zone
Delegate security responsibilities
to specialized perimeter
infrastructure
26

27. 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

28. 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