Your SlideShare is downloading. ×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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
  • Transcript

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