Enterprise Access Control Patterns for Rest and Web APIs


Published on

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

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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

    1. 1. Enterprise Access ControlPatterns For REST andWeb APIsFrancois LascellesLayer 7 TechnologiesSession ID: STAR-402Session Classification: intermediate
    2. 2. 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
    3. 3. 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?
    4. 4. 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?
    5. 5. 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
    6. 6. 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
    7. 7. 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
    8. 8. 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
    9. 9. 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
    10. 10. 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
    11. 11. Client credentials grant type Two-legged handshake Client application authenticated only No refresh tokens 1. Get access token 11
    12. 12. 2 vs. 3 Legged SpectrumTwo Threelegged legged 12
    13. 13. Step-by-step enterprise APIaccess control(from an OAuth perspective) 13
    14. 14. Starting Point enterprise/provider admin I need REST API more OAuth FAIL!OAuth Client(application)
    15. 15. 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
    16. 16. 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
    17. 17. 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
    18. 18. 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
    19. 19. 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
    20. 20. 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
    21. 21. 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
    22. 22. Thank youFor more information: info@layer7.com 22