Exposing service-oriented connectivity points using Web APIs, REST creates new security challenges for the enterprise. Mr. Lascelles’ presentation will make sense of SAML, OAuth, OpenID, API keys, HMAC, custom tokens, cookies and more, and will explain how these protocols fit together and how the enterprise can leverage such technologies for enabling trust management and access control.

1. Enterprise Access Control Patterns for REST and Web API Francois Lascelles Layer 7 Technologies Session ID: STAR-305 Session Classification: Intermediate

3. Mission critical

4. ID authority

5. Legacydeveloper mobile

6. Agenda 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?

7. Pattern 1: API Keys in URI parameters https://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?

8. Pattern 2: HMAC PUT /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

9. Pattern 3: OAuth Retrieve resource with owner authorization (REST exchange) Autz server Application Resource provider Do something with my resource Yes, I authorize it Resource owner GET /somewhere/someresource … Authorization: OAUTH fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8= …

10. OAuth Benefits OAuth 2.0 is poised to fill the standards gap Passwords remain secret Tokens easier to ‘control’ than passwords Resource-oriented => perfect for REST Many different flows to accommodate different use cases (two and three parties) Different token types Bearer (easy, like cookies) MAC (integrity, more secure)

11. What about SAML? 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 XML 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 SAML Bearer Profile for OAuth 2.0

12. Sample SAML binding for RESTful web service GET /token/joe Authorization: … 200 OK <saml:Assertion … /> GET /someresource Authorization: SAML PmfrTLJwMuZurA8= trust 200 OK … 9

13. 10 Step-by-step enterprise API access control (from an OAuth perspective)

14. Starting Point enterprise/provider admin Resources (API) I need more OAuth FAIL! OAuth Client (application) Resource owner

15. OAuth Clients Provisioning, Management provider admin app developer 2 1 OAuthClients 3 Create/manage my account, get shared secret, define my callback Approve new clients, list existing client, get stats on usage Provision app with account id, shared secret

16. Runtime Policy Modeling, Integration 1 OAuthClients 1 1 Prot Res Server Administrator declares internal APIs to be accessed using OAuth authorization which token types – Bearer, Mac which flows http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03

17. OAuth Handshake OAuthClients OAuthTokens 2, 3 2, 3 2 3 OAuth Autz server Prot Res Server 1 Client redirect owner to oauth provider Policy looked up, flow executed: OAuth handshake as per flow. Client is authenticated, gets access token 2

18. OAuth Resource Retrieval OAuthClients OAuthTokens 3 2 1 Prot Res Server OAuth Autz server Client uses access token to access resource Protected resource server validates incoming token, authorize specific access based on token attributes, updates usage statistics The API is called on behalf of, and returned to client

19. Token Refresh OAuthClients OAuthTokens 2 1 2 1 1 OAuth Autz server Prot Res Server 2 Client uses refresh token to extend access resources on behalf of resource owner. Autz server authenticates Client and update the token Client access resource using refreshed token

20. Owner-driven Token Revocation OAuthClients OAuthTokens 2 1 OAuth Autz server Prot Res Server 2 FAIL! Resource owner revokes authorization previously granted to Client. Autz server revokes corresponding token. Client tries to access resource, access is refused. 1

21. Provider-driven Token Revocation 2 OAuthClients OAuthTokens 3 OAuth Autz server Prot Res Server 1 FAIL! Client is hacked, access tokens compromised Administrator revokes all tokens issued to this particular client Hacker cannot use old tokens to access resources 3 Client prompts resource owner to repeat OAuth handshake. Owner does not need to change password.

22. Monitoring, Reporting OAuthClients OAuthTokens OAuth Autz server Prot Res Server Analytics Report on APIs, Clients, Owners. Monitor usage, performance.

23. Comprehensive REST Access Control Omg, it’s full of win OAuthClients Provisioning Approval Flow Persistence Querying Metrics OAuthTokens Persistence Querying Metrics Revocation Refresh *all of this* OAuth Autz server Policy Modeling OAuth Protocol Identity integration Token issuing Token refresh SLA enforcement Prot Res Server Policy Modeling Token validation Bearer, MAC Identity integration, SAML Integrity check API proxying SLA enforcement Analytics Reports Monitoring SLAs Alerting

24. APPLY Decouple OAuth and other access control mechanisms from actual API implementations Enable OAuth for existing APIs by deploying OAuth broker at perimeter Configure, not code Ensure support for OAuth 2.0 and all of its richness 21

25. 22 Thank you For more information: info@layer7.com