Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Enterprise Access Control Patterns for REST and Web APIs Gluecon 2011, Francois Lascelles - Layer 7 -


Published on

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.

  • Be the first to comment

Enterprise Access Control Patterns for REST and Web APIs Gluecon 2011, Francois Lascelles - Layer 7 -

  1. 1. Enterprise access control patterns for RESTand Web APIsFrancois LascellesDirector, Solutions Engineering
  2. 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. 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. 4. 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&password=mysecret  Why not use HTTP Basic instead?
  5. 5. HMACPUT /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. 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. 7. OAuth Retrieve resource with owner authorization (REST exchange) Resource Application provider Do something Yes, I authorize it with my resource Resource ownerGET /somewhere/someresource…Authorization: OAUTH fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=…
  8. 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. 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. 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. 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 + RESTSaaSPaaS Protected resource Do something with Yes, I authorize it my resource at http://myenterprise Enterprise boundary
  12. 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. 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. 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. 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. 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. 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. 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. 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. 20. Thank you Visit us at table #10 -> win an iPad2! Check out: