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.
Using APIs to Create an Omni-Channel Retail Experience
Enterprise Access Control Patterns for REST and Web APIs Gluecon 2011, Francois Lascelles - Layer 7 -
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