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.
Enterprise Access Control Patterns for REST and Web APIs Gluecon 2011, Francois Lascelles - Layer 7 -
Enterprise access control patterns for RESTand Web APIsFrancois LascellesDirector, Solutions Engineering
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
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?
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?
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
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
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=…
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…
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
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
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
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
Example SAML binding for RESTful web service GET /token/joe Authorization: … 200 OK <saml:Assertion … /> GET /someresource Authorization: SAML PmfrTLJwMuZurA8= 200 OK … 13
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
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
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
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)
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
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
Thank you Visit us at table #10 -> win an iPad2! Check out: http://www.layer7tech.com/api-management-and-security