Enterprise Access Control Patterns for Rest and Web APIs

Enterprise Access Control Patterns for Rest and Web APIs



RSA Conference presentation by Francois Lascelles of Layer 7 Technologies discussing REST access control patterns and OAuth 2.0

RSA Conference presentation by Francois Lascelles of Layer 7 Technologies discussing REST access control patterns and OAuth 2.0



Total Views
Views on SlideShare
Embed Views



2 Embeds 704

http://www.layer7tech.com 703
https://twitter.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Example problem: shared secrets that end up on traffic logs
  • This relies on an agreed upon method for constructing string to sign (what is covered, in which order, etc).
  • OAuth is resource oriented, perfect for restBenefit: password remains secret
  • Grant types (flows)Authorization codeImplicitResource owner password credentialsClient credentialsSAMLFoo
  • OAuth client is for example a webapp, an iOS app
  • Showing authorization code grant type situationNote that theoauth client store is used to authorize the client (token endpoint)
  • An application is compromised, a subscriber loses him mobile deviceLink?: when a subscriber issues authorization, he receives a confirmation email with a link to later revoke if needeManagement GUI: administration interface

Enterprise Access Control Patterns for Rest and Web APIs Enterprise Access Control Patterns for Rest and Web APIs Presentation Transcript

  • Enterprise Access ControlPatterns For REST andWeb APIsFrancois LascellesLayer 7 TechnologiesSession ID: STAR-402Session Classification: intermediate
  • Today’s enterprise 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
  • REST access control standards gap 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 parametershttps://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&pass word=mysecret  Why not use HTTP Basic instead?
  • Pattern 2: HMACPUT /api/resource…Authorization: AWS keyid:fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=…  Prove possession of share secret using HMAC sig (shared secret not actually sent)  Payload covered by signature -> message integrity  Timestamp covered by signature -> less susceptible to replay  Used by AWS, Azure, core to OAuth 1.0  Requires agreement for normalized request string 5
  • Pattern 3: OAuth Specifies a handshake to grant an access token to an application (REST client) Access token is then used to consume REST service Retrieve resource with OAuth access token (REST exchange) Application Service Do something Yes, I authorize it with my resource Resource owner
  • OAuth 2.0 4 core grant types (handshakes) to address different use cases  Authorization code, implicit, password, client credentials SAML extension grant type (draft-ietf-oauth-saml2- bearer-03) Different token types  Bearer (easy, like cookies)  MAC (integrity, more secure) OAuth 2.0 is rich, fills the standards gap
  • Authorization code grant type Resource owner redirected between OAuth authorization server and client application Both resource owner and client authenticated as part of handshake Supports refresh 2. Get access token 1. Get authz code 8
  • Implicit grant type Also 3-legged but simpler Client is not authenticated  redirection URI must be registered to avoid fishing No refresh 1. Get access token 9
  • Resource owner password credentials granttype Resource owner provides credentials to client Client uses it to get access token Both client and res owner identities authenticated Can be refreshed 1. Provide credentials 2. Get access token 10
  • Client credentials grant type Two-legged handshake Client application authenticated only No refresh tokens 1. Get access token 11
  • 2 vs. 3 Legged SpectrumTwo Threelegged legged 12
  • Step-by-step enterprise APIaccess control(from an OAuth perspective) 13
  • Starting Point enterprise/provider admin I need REST API more OAuth FAIL!OAuth Client(application)
  • OAuth Clients Provisioning, Management Provide a portal for developers to register, generate shared secrets Enable approval flow (administrative) Store API keys, redirection URIs List existing clients, record usage statistics app developer register approve OAuth Client Management provision API dev portal
  • Runtime Policy Modeling, Integration Declare API endpoints in the resource server Integrate identity providers for runtime authentication Granular access control rules  Which API, which identities, which grant types, … Runtime Policy Modeling API endpoints configure Resource Server id providers, API keys PEP
  • OAuth Handshake Enable handshake  Lookup policy, authenticate identities, enable flow  Create ‘OAuth Session’ Token Management persist Token Endpoint Authorization Endpoint get token OAuth Authorization Server authorize redirect
  • Runtime API Call OAuth resource server enables API call  Lookup and verify incoming OAuth access token  Authorize based on OAuth session attributes  Route to API endpoint, return resource to client app  Record consumption statistics Token Management consume Resource Server
  • Token Refresh OAuth authorization server enables refresh  Authenticate client  Lookup and validate refresh token  Create new access token  Update ‘OAuth session’ Token Management refresh Token Endpoint
  • Token Revocation Minimize impact of compromised tokens Enable revocation for subscribers and API providers  Management GUI, links Token Management Revocation interface revoke check Resource Server FAIL! compromise
  • Comprehensive API Access Control Apply OAuth-enabling infrastructure:  Token management (lifecycle, revocation)  Developer portal (client provisioning, client management)  OAuth resource server (API proxy, PEP)  OAuth authorization server (authorization endpoint, token endpoint)  Runtime policy modeling  Reporting, monitoring interface
  • Thank youFor more information: info@layer7.com 22