Understanding Identity in the World of Web APIs – Ronnie Mitra, API Architect, Layer 7 Talk from Identity Management 2013

842 views

Published on

Web Based APIs have become a powerful tool for reaching end users in an increasingly fragmented market. The emergence of public and private APIs have introduced new challenges in identity management and access control. Attend this session to get a crash course in Web APIs, the risks they introduce and the emerging standards that can make them safer to use (including OAuth 2 and Open ID Connect)

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
842
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
27
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Understanding Identity in the World of Web APIs – Ronnie Mitra, API Architect, Layer 7 Talk from Identity Management 2013

  1. 1. Understanding Identity in the World of WebAPIsRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy
  2. 2. API Managementvirtual cloudon-premise
  3. 3. Connecting things
  4. 4. Connecting computer programs
  5. 5. … over the web
  6. 6. 2000 – ebay
  7. 7. 2000 – salesforce
  8. 8. 2006 – Amazon Web Services
  9. 9. Twilio or stripe2007 - Twillio
  10. 10. Web APIsLanguage IndependentAPIs are constrained by the syntax of the webMost API Design principles can be appliedSome design principles are unique to Web APIs
  11. 11. Web APIsHTTP
  12. 12. Network Based APIsHTTPCOAP MQTTWebSocket?
  13. 13. Tunnel StyleURI StyleHypermedia StyleEvent Driven Style
  14. 14. Tunnel StyleExample: SOAP• transport agnostic• operation based• binding documents (WSDL)
  15. 15. Tunnel Style<RetrieveStudentRecords><StudentId>1213</StudentId></RetrieveStudentRecords>
  16. 16. URI StyleGETPUTPOSTDELETE+ URI
  17. 17. URI StyleGET /students/1232
  18. 18. Hypermedia Style
  19. 19. Hypermedia Style• links• templated input (forms)• task based
  20. 20. {links: [link {href: ‘…’ rel: ‘list’},link {href: ‘…’ rel: ‘add’}]collection: [{link: {rel:complete,href:‘…},id:42,text:‘Record 42}]}
  21. 21. Event Driven StyleExample: WebSockets• event based communication• server initiated events• full-duplex (websocket)
  22. 22. Ronnie,Mitra,UK
  23. 23. Established mechanisms, tools and frameworksHTTP and URI security mechanismsSimilar to URI style, new challenges with linksStarts in HTTP, need visibility in new protocol
  24. 24. Private/Partner or Closed APIs
  25. 25. Acme Corp.APIAcme Corp.App
  26. 26. Public or Open APIs
  27. 27. Acme Corp.APIThird PartyApp
  28. 28. Priority:Lower CostPriority:Increased Adoption
  29. 29. Focus on the developer experience(dx)
  30. 30. UsabilityReliabilitySimplicitySecurityEtc…Software Qualities
  31. 31. DX > Software Qualities
  32. 32. Priority:Lower CostPriority:Increased Adoption
  33. 33. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  34. 34. The API security challenge:BalancingSecurity and Usability
  35. 35. IdentityAuthenticationAuthorizationAvailabilityIntegrityPrivacy
  36. 36. Identities and Attack Surfaces
  37. 37. DeveloperPortalAPIDeveloperEnd UserAdministrator
  38. 38. PortalAPIDeveloperEnd UserAdministrator
  39. 39. APIEnd User
  40. 40. Injection Attack
  41. 41. API
  42. 42. Examples:SQL InjectionCommand InjectionCode InjectionArgument Injection
  43. 43. API Attack Example:SQL Injection Attacks: APIsGET http://host.com/aresource?token=%E2%80%98or%20%E2%80%981%3D1GET http://host.com/aresource?token=‘ or ‘1=1select * from tokens where token = ‘’ or ‘1=1’;
  44. 44. APIs May Be A Direct Conduit49HTTPServerAppServerDatabaseAppObjectsOften:• Self-documenting• Closely mapped to object space
  45. 45. SQL Injection Attack - MitigationSanitize inputsValidate request and response dataLimit data size
  46. 46. Denial of Service
  47. 47. API
  48. 48. Examples:XML/JSON Parser AttacksJumbo MessagesServer Overload
  49. 49. Denial of Service Attack: MitigationEnforcement of boundary conditionsIntelligent rate limitingOffload processing
  50. 50. Overflow
  51. 51. API
  52. 52. Buffer Overflow Attack: MitigationBoundary limit enforcementMessage validation
  53. 53. Cross Site Scripting
  54. 54. API
  55. 55. XSS API Example60AttackerWeb App Server(browser+APIs)Victim: WebBrowserClient<SCRIPT …>1. API injectsscript in3. Browser loadscontent withembedded script2. Server fails toperform FIEO: FilterInput, Escape OutputAPI
  56. 56. Cross Site Scripting: MitigationWhitelist tags if you can (i.e. where the validation space issmall and concise)Blacklist dangerous tags like <SCRIPT>Always perform FIEO (Filter Input, Escape Output)Learn more: http://xssed.com61
  57. 57. rate limiting is essential
  58. 58. we need message and payload validation too
  59. 59. is this new API world compatible with validation?
  60. 60. good APIs are extendable and evolvable
  61. 61. /myapi/v1<contact><name>Ronnie</name><city>London</city></contact>
  62. 62. /myapi/v1<contact><name>Ronnie</name><city>London</city><country>UK</country></contact>
  63. 63. <xs:complexType><xs:sequence><xs:element name=“name" type="xs:string"/><xs:element name=“city" type="xs:string"/></xs:sequence></xs:complexType><contact><name>Ronnie</name><city>London</city><country>UK</country></contact>
  64. 64. API!
  65. 65. Man in the Middle
  66. 66. API
  67. 67.  Always use HTTPS Corollary: Use a secure HTTPS implementationMan in the Middle Attack: Mitigation
  68. 68. App Spoofing
  69. 69. API
  70. 70.  Examples:- Guessing application ID by brute force- Retrieving application ID by sniffing traffic- Cracking application to retrieve application IDApp Spoofing
  71. 71. how can I protect identity on a mobile device?
  72. 72. …?
  73. 73. what happens if my mobile app is impersonated?
  74. 74. APIEnd User
  75. 75. Revenue Source
  76. 76. What the Fudge*! Ididn’t make 10000calls yesterday!!!!!!I’m not paying that.*This is what WTF actually stands for.
  77. 77. I didn’t buy 1000mobile phones inRussia!I’m not paying that!
  78. 78. Forrester:we are moving towards a ‘zero-trust’ model
  79. 79. New platforms, new languages, new challenges:• Ruby on Rails• Node.js• Scala• Nginx• Squid/Varnish/Traffic Manager
  80. 80. TLSOAuth 2Open ID Connect
  81. 81. OAuth provides aDelegated Authorization Framework
  82. 82. An imperfect analogy….
  83. 83. http://www.flickr.com/photos/drewleavy/5587005480
  84. 84. http://www.flickr.com/photos/24oranges/5791460046/
  85. 85. http://www.flickr.com/photos/grumbler/571106054/http://www.flickr.com/photos/roboppy/238406811/Your MoneyThis Shop Needs Your MoneyYou need to grant accessto your money
  86. 86. http://www.flickr.com/photos/drewleavy/5587005480I won’t tell.I promise!
  87. 87. www.flickr.com/photos/auntiep/255249516
  88. 88. Granting access to someone to acton your behalf.
  89. 89. resolving the password anti-pattern
  90. 90. Your resourcesThis app needs to act on your behalfYou need to grant accessto your resources
  91. 91. Your google+ dataThis app needs to access yourGoogle+ dataYou need to grant accessto your resources
  92. 92. Hi Google.I’d like to have access to a user’sfriends list.
  93. 93. Hang on, let meask…
  94. 94. He said yes. Here is youraccess code.
  95. 95. “Client” == application“Resource owner” == end-userThe first step to understanding OAuth 2:
  96. 96. OAuth 2 Grant Types Authorization Code Implicit Resource Owner Password Credentials Client Credentials
  97. 97. Authorization Code Grant104Client ApplicationResource OwnerUsingApplicationResource ServerI Wish I could accessmy resources throughthis application…
  98. 98. Authorization Code Grant105Client ApplicationResource OwnerUsingApplicationResource Server…but I don’t trust thisapp enough to give itmy credentials.
  99. 99. Authorization Code GrantInitiation106Client ApplicationResource Owner Authorization ServerResource ServerUser AgentIssue GETrequest viaUser-Agent
  100. 100. Authorization Code GrantInitiation107Client ApplicationResource Owner Authorization ServerResource ServerUser AgentIssue GETrequest viaUser-Agentresponse_typeclient_idredirect_uriscopestate
  101. 101. OAuth 2 Authorization Request response_type – indicates grant type client_id –application identifier redirect_uri (optional) – address which the UA can use to respond to client scope (optional) – space delimited string: what the client wants to do state (optional)– opaque string used to defeat CSRF attacks Sample Authorization GET URL:https://azserver/oauth2/authorize?response_type=code&client_id=my_id&state=state&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fcallback
  102. 102. Authorization Code GrantResource Owner Authentication109Client ApplicationResource Owner Authorization ServerResource ServerUser AgentSendUserAuthenticationForm?Authenticate
  103. 103. Authorization Code GrantAuthorization110Client ApplicationResource Owner Authorization ServerResource ServerUser AgentDeliverGrantScreen???ApproveGrantRequest
  104. 104. Authorization Code GrantReceipt of Authorization Code111Client ApplicationResource Owner Authorization ServerResource ServerUser AgentRedirectUser-AgentClientApplication! RedirectedToClientApplicationcodestate302
  105. 105. Authorization Code GrantAccess Token Request112Client ApplicationResource Owner Authorization ServerResource ServerRequestAccessTokenReturnAccessTokenand OptionalRefresh Tokengrant_typecoderedirect_uriclient_id200AZ CodeAZ Code
  106. 106. Authorization Code GrantAccess Protected Resource113Client ApplicationResource Owner Authorization ServerResource ServerRequestResourceUsingApplicationReturnResource200
  107. 107. be careful – much can go wrong!
  108. 108. Authorization Code GrantInitiation115Client ApplicationResource Owner Authorization ServerResource ServerUser AgentIssue GETrequest viaUser-Agentresponse_typeclient_idredirect_uriscopestate
  109. 109. Authorization Code GrantReceipt of Authorization Code116Resource Owner Authorization ServerResource ServerUser AgentRedirectUser-AgentClientApplicationRedirectedToClientApplicationcodestate302
  110. 110. is this complex?
  111. 111. is this too complex?a better question:
  112. 112. is this too complex for our developers?an even better question:
  113. 113. It depends, but it is the best we have today
  114. 114. 2 vs. 3 Legged Spectrum121ThreeleggedTwolegged
  115. 115. Three Legged122Client ApplicationResource OwnerAuthorization ServerResource Server
  116. 116. Two Legged123Client ApplicationAuthorization ServerResource Server
  117. 117. OAuth 2 ChallengesIt is a framework
  118. 118. OAuth 2 ChallengesIt is complex for the implementer
  119. 119. OpenID Connect Identity Access Built on top of OAuth 2 Not tied to any single vendor or identity provider
  120. 120. APIEnd User
  121. 121. APIEnd User?
  122. 122. Client ApplicationRetrieve UserInformationOpenIDResourceServerid_token
  123. 123. Portal
  124. 124. Who is using the API?How are they (mis)using it?
  125. 125. What would happen if the portal was exploited?
  126. 126. PortalAPIDeveloperEnd UserAPI
  127. 127. PortalAPIAdministrator
  128. 128. Where are the components deployed?Who owns the identity store?
  129. 129. PortalAPIis this safe?
  130. 130. http://www.flickr.com/photos/naomi_pincher/3306312873/Layered Pattern
  131. 131. Security LayerTLS terminationOAuth and OpenID Connect supportSchema validationBoundary enforcementCryptographic operationsSecurity mediation
  132. 132. API GatewayGatewayAPIAPI
  133. 133. API ManagementPortalGatewayAPIAPI
  134. 134. Summary:Old threats still existBe aware of new surfaces and threatsEnforce security in an abstracted layer with a gateway
  135. 135. www.apiacademy.co
  136. 136. Visit the Layer 7 booth for informationon our gateways and portals!

×