API Security & Oauth Patterns RSA Europe @flascelles
-
Upload
ca-api-management -
Category
Technology
-
view
74.237 -
download
4
description
Transcript of API Security & Oauth Patterns RSA Europe @flascelles
Session ID: STAR-305Session Classification:
Intermediate
Francois LascellesLayer 7 Technologies
Enterprise Access Control Patterns for
REST and Web API
Today’s enterprise API drivers
enterprise boundary
distributed enterprise SOA
• Sensitive data, apps• Mission critical• ID authority• Legacy
partner
SAAS
mobile
IAAS/PAAS
developer
Integration APIs!
B2B
APIs!
B2C
APIs!
Cloud APIs!
Access control?
Agenda
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?
Pattern 1: API Keys in URI parameters
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?
https://host/api/resource?keyid=foo&keysecret=bar…
Pattern 2: HMAC
5
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
Pattern 3: OAuth
Autz server
Application
Resource owner
Do something with my resource
Yes, I authorize it
Retrieve resource with owner authorization(REST exchange)
GET /somewhere/someresource…Authorization: OAUTH fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=…
Resource provider
OAuth Benefits
OAuth 2.0 is poised to fill the standards gap Passwords remain secret Tokens easier to ‘control’ than passwords Resource-oriented => perfect for REST Many different flows to accommodate
different use cases (two and three parties) Different token types
Bearer (easy, like cookies) MAC (integrity, more secure)
What about SAML?
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 XML 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 SAML Bearer Profile for OAuth 2.0
Sample SAML binding for RESTful web service
9
GET /token/joeAuthorization: …
200 OK<saml:Assertion …/>
GET /someresourceAuthorization: SAML PmfrTLJwMuZurA8=
200 OK…
trust
10
Step-by-step enterprise API access control
(from an OAuth perspective)
Starting Point
Resource owner
Resources (API)
OAuth Client(application)
enterprise/provider admin
I needmore OAuth
FAIL!
OAuth Clients Provisioning, Management
app developer
provider admin
1. Create/manage my account, get shared secret, define my callback
2. Approve new clients, list existing client, get stats on usage
3. Provision app with account id, shared secret
2
1
3
OAuth Clients
Runtime Policy Modeling, Integration
OAuth Clients
1. Administrator declares internal APIs to be accessed using OAuth authorization
a) which token types – Bearer, Macb) which flowsc) http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-
03
Prot Res Server
1
1
1
OAuth Handshake
OAuth Clients
1. Client redirect owner to oauth provider2. Policy looked up, flow executed:
OAuth handshake as per flow. 3. Client is authenticated, gets access
token
3 OAuth Autz server
2
OAuth Tokens
22, 3 2, 3
1Prot Res Server
OAuth Resource Retrieval
OAuth Clients
1. Client uses access token to access resource2. Protected resource server validates incoming token, authorize
specific access based on token attributes, updates usage statistics
3. The API is called on behalf of, and returned to client
OAuth Tokens
Prot Res ServerOAuth Autz server
1
2
3
Token Refresh
OAuth Clients
1. Client uses refresh token to extend access resources on behalf of resource owner. Autz server authenticates Client and update the token
2. Client access resource using refreshed token
OAuth Tokens
OAuth Autz server
Prot Res Server1
11
2
2
2
Owner-driven Token Revocation
OAuth Clients
1. Resource owner revokes authorization previously granted to Client. Autz server revokes corresponding token.
2. Client tries to access resource, access is refused.
OAuth Tokens
OAuth Autz server
Prot Res Server
2
1
1
FAIL!2
Provider-driven Token Revocation
OAuth Clients
1. Client is hacked, access tokens compromised
2. Administrator revokes all tokens issued to this particular client
3. Hacker cannot use old tokens to access resources
OAuth Tokens
OAuth Autz server
Prot Res Server
3
2
FAIL!1
4. Client prompts resource owner to repeat OAuth handshake. Owner does not need to change password.
3
Monitoring, Reporting
OAuth Clients
1. Report on APIs, Clients, Owners. Monitor usage, performance.
OAuth Tokens
OAuth Autz server
Prot Res ServerAnalytics
Comprehensive REST Access Control
OAuth ClientsProvisioningApproval FlowPersistenceQueryingMetrics
OAuth TokensPersistenceQueryingMetricsRevocationRefresh
OAuth Autz serverPolicy ModelingOAuth ProtocolIdentity integrationToken issuingToken refreshSLA enforcement
Prot Res ServerPolicy ModelingToken validationBearer, MACIdentity integration, SAMLIntegrity checkAPI proxyingSLA enforcement
AnalyticsReportsMonitoringSLAsAlerting
*all of this*
Omg, it’s full of win
APPLY
Decouple OAuth and other access control mechanisms from actual API implementations
Enable OAuth for existing APIs by deploying OAuth broker at perimeter Configure, not code
Ensure support for OAuth 2.0 and all of its richness
21