This presentation illustrates the applicability of API keys, OAuth, SAML, OpenID, and a number of proprietary mechanisms such as HMAC signatures for consuming and exposing Web APIs and RESTful web services.

1. Enterprise access control patterns for REST
and Web APIs
Francois Lascelles
Director, Solutions Engineering

2. Today’s enterprise integration API drivers
SAAS
distributed enterprise SOA
Integration partner
APIs!
IAAS/PAAS
Cloud
APIs!
enterprise boundary B2B
APIs!
Access
control?
B2C
APIs!
• Sensitive data, apps
• Mission critical
• ID authority
• Legacy
developer
mobile

3. Controlling access to web apis, RESTful web services
 WS-* web services have rich security standards and authentication/authorization
mechanisms
 Web API, RESTful web services tend to use proprietary tokens, point-to-point
solutions
 What are the common patterns in use?
 Which standards are emerging?
 How to use specialized infrastructure to implement access control?
 How to accommodate requesting party technical capabilities?

4. API Keys in URI parameters
https://host/api/resource?keyid=foo&keysecret=bar
…
 Simplest thing, common practice
 Shared secret in a URL parameter based authentication, no signature involved
 Equivalent to https://host/api/resource?username=franco&password=mysecret
 Why not use HTTP Basic instead?

5. HMAC
PUT /api/resource
…
Authorization: AWS keyid:fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=
…
 Use the key to actually sign something
 Shared secret not sent
 Payload covered by signature -> message integrity
 Timestamp covered by signature -> less susceptible to replay
 Used by AWS, Azure
 Implementations are proprietary, not compatible
5

6. Sessions
 Web app => login followed by cookies, session ids
 APIs, services => login methods followed tokens, session ids
 Server state is not restful
 Session high jacking threat
 Token are useful for federated authentication (endpoint disconnected
from id authority)
Login
Get back token or cookie
Use token or cookie on subsequent calls

7. OAuth
Retrieve resource with
owner authorization
(REST exchange)
Resource
Application
provider
Do something Yes, I authorize it
with my resource
Resource
owner
GET /somewhere/someresource
…
Authorization: OAUTH fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=
…

8. OAuth applicability
 OAuth is resource-oriented => relevant to REST
 OAuth 2.0 is a protocol; it does not specify a token format
 In practice, there are various interpretation of what an OAuth token looks like
- OAuth 1.0, OAuth WRAP
- Does the signature cover the payload or not?
- Which attributes are included?
- Signed with HMAC/RSA?
- SAML
- Etc…

9. OAuth portal + API pattern
Portal accesses API
on behalf of user
API
Web Portal
OAuth style
redirect to authorize?
Web Portal user
AND
Resource owner
 OAuth needed here if portal and API are „independent‟
 If both the portal and the API authorize the same identity,
you can use id propagation and trust management instead

10. Enterprise SaaS composition with OAuth
 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

11. Cloud callback pattern with OAuth
 Authorize access to enterprise resource
- OAuth-enabled SaaS/PaaS can also retrieve resources hosted by enterprise
- Alternatively, authorize SaaS instance directly and define an access policy
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

12. SAML
is SAML appropriate for REST and Web APIs?
 A rich and established standard for making various claims regarding an identity
(authentication statements, authorizations statements, attribute statements)
- SAML is well supported by existing enterprise infrastructure
 SAML is verbose
- 8KB is too big a token for an authorization header or a query parameter
- You can gzip + base 64 encode the token to make it fit
 SAML is based on XML
- My API uses JSON, not API
- It does not matter, the two should be decoupled
 Binding specifications for Web browser SSO, SOAP+WSS, but no formal binding for
REST, web APIs

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

14. JSON Web Token (JWT)
 IETF Draft from March 2011
 Compact token format meant to be used in authorization headers and URI
parameters
 Three base64url encoded JSON segments : JWT Header . JWT Claim . JWT Crypto
 Crypto segment relies on another proposed specification: JSON Web Signature

15. SSL
 Hide shared secrets
- API keys, tokens, http basic
- Bearer tokens
 Even with payload signatures, you may be subject to replay attacks
 Use SSL correctly (hint: server-side authentication)
 SSL mutual great for two way authentication
 SSL does not provide “at rest” security nor addresses repudiation

16. Key Web API Management Infrastructure
 API portal
- Developer on-boarding
- Contract management, billing
- API discovery, documentation
 API proxy (PEP)
- API traffic proxying
- Authentication/Authorization
 Reporting, monitoring
- Contract enforcement
- Threat protection

17. Perimeter PEP Gateway/Proxy
 A PEP at the perimeter a service zone to handle
authentication, authorization
 Token validation, token issuing
 OAuth authorization server
 Interface with IAM infrastructure
 Coordinate trust between service zones
- On premise, off premise
 API threat protection
 SLA enforcement (per identity, per contract)

18. Developer Portal and PEP coordination
 Signup, registration, email verification
 Key issuing
 Be an ID provider*
 Contract assignment*
 Billing*
Shared or coupled provisioning
Trust relationship
 Runtime Authentication
 Runtime Contract Enforcement
 API protection
 Runtime feeds to reporting, billing,
monitoring

19. Coordinating service zones
 Central control of PEPs across service zones
 Centralized design time governance authority
defines access control rules, contracts
 Policies provisioned to relevant service zone
PEP
Governance
Authority or PDP
 PEP deployed on public cloud, private cloud,
on-premise/off-premise (form factors)
 Cross-domain trust handled at perimeter

20. Thank you
 Visit us at table #10 -> win an iPad2!
 Check out: http://www.layer7tech.com/api-management-and-security