IBM API Management 2.0 Security

This deck will demystify the standard security mechanisms around API Management such as OAuth and Basic Auth. This deck also provides a brief description to the roles and characteristic of APIs and also some background to API Management in general.

Transcript

1. © 2013 IBM Corporation © 2013 IBM Corporation API Management Security Chris Markes Shiu-Fun Poon API Management Engineer DataPower Security Architect IBM IBM TSA-2731
2. © 2013 IBM Corporation In this talk • The role of APIs • Background to API management • Why APIs are not the same as [internal] services • API characteristics • API security • IBM API management
3. © 2013 IBM Corporation Please Note IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.
4. © 2013 IBM Corporation The web beyond the browser “$7bn worth of items on eBay through APIs” Mark Carges (Ebay CTO) “The adoption of Amazon’s Web services is currently driving more network activity then everything Amazon does through their traditional web sites.” Jeff Bar (Amazon evangelist) / Dion Hinchcliffe (Journalist) “$7bn worth of items on eBay through APIs” Mark Carges (eBay CTO) “The API which has easily 10 times more traffic then the website, has been really very important to us.” Biz Stone (Co-founder, Twitter) “The adoption of Amazon’s Web services is currently driving more network activity then everything Amazon does through their traditional web sites.” Jeff Bar (Amazon evangelist) / Dion Hinchcliffe (Journalist) Web APIs are the new, fast-growing business channel Businesses are Evolving stores (800) ###s web sites Not having an API today is like not having a web site in the 1990s.
5. © 2013 IBM Corporation The engaging enterprise Apps Business User IT Person Enterprise App Developer The Platform Enterprises want to tap into innovation from a large community of developers, not just developers they employ Customer • Business Users want to engage Customers in new markets • They need to Externalize the Enterprise • They need to get Apps in front of these Customers • Apps need APIs that Externalize the Enterprise • App Developers use APIs • App Developers are now External to the Enterprise • IT Personnel need to secure, scale and support the externalized Enterprise • Business Users and IT folks needs Insight so they can respond to business needs
6. © 2013 IBM Corporation Meet your newest developer. (You didn't have to hire him.)
7. © 2013 IBM Corporation The programmable web: 9000 APIs and counting programmableweb.com
8. © 2013 IBM Corporation API channels ifttt.com/channels
9. © 2013 IBM Corporation The basics of an API What is a web API?  An API is a public persona for an enterprise; exposing defined assets, data or services for public consumption  An API is simple for app developers to use, access and understand  An API can be easily invoked via a browser, mobile device, etc. What value does a web API provide?  Extends an enterprise and opens new markets by allowing external app developers to easily leverage, publicize and/or aggregate a company’s assets for broad-based consumption What “assets, data or services” are exposed via a web API?:  Product catalogs  Phone listings  Insurance cases  Order status  Bank loan rates
10. © 2013 IBM Corporation APIs and SOA • SOA typically oriented around internal services • APIs provide external access to content in internal services • Technology choices may be differently motivated HTTP JSON SOAP XML MQ CICS API
11. © 2013 IBM Corporation Before and after APIs Before • You controlled the applications (and the developers) • You knew who your users were (and how many) After • Applications not under your control • May have no relation with app developers • Users may not be known to you • Scale
12. © 2013 IBM Corporation Scale “We're being eaten alive.”
13. © 2013 IBM Corporation BTW, here are your other developers .
14. © 2013 IBM Corporation Scale • To avoid being eaten alive... – Caching • Reduce load on backend servers • Improve response time – Throttling • Gate requests at a predefined rate (burst rate, and average over time) • Avoid abuse of your API (or use to apply tiering) • API
15. © 2013 IBM Corporation Types of APIs Public, open-to- all APIs Protected, open-to- partner APIs Private, open-to- employee APIs • APIs are open to any developer who wants to sign up • Apps are more targeted towards end consumers • The business driver is to engage customers through external developers • APIs are open to select business partners • Apps could be targeted at end consumers or business users • The business driver is usually different, based on the data and type of business of the enterprise • APIs are exposed only to existing developers within the enterprise • Apps are usually targeted at employees of the enterprise • The business driver is more around productivity of employees
16. © 2013 IBM Corporation Private APIs user app API user registry (internal) resources
17. © 2013 IBM Corporation Partner APIs user app API user registry (managed) resources
18. © 2013 IBM Corporation Public APIs user app API user registry (dynamic) resources
19. © 2013 IBM Corporation Application identity • How do you know who (or what) is using your API? – Standard practice is to require an app key – Identifies the app itself (and owner) – Does not identify the end user of the app – • Why do you need to know? – If nothing else, to have a point of control – As the basis for analytics – • Can you always be sure? – No... – Not all apps can keep a secret – Not all apps are running in a trusted platform or environment
20. © 2013 IBM Corporation End user authentication • APIs are often exposing resources that are restricted to the owning user – The end user and the app do not have the same identity – End-user-credentials passed in on each request – May be HTTP Basic or Oauth – Channel needs not to expose credentials • SSL/TLS essential
21. © 2013 IBM Corporation Managing users • With a public API, your user community is the Internet – Need to be able to sign up users – Manage registration of apps (and lifecycle) • Disable rogue apps – Developer community resources
22. © 2013 IBM Corporation Making APIs public • For your API to be adopted, it needs to be discoverable – Documentation – Examples – Ability to try it out directly
23. © 2013 IBM Corporation Analyzing API usage • How do you know if your API is successful? – Who calls it? – When/how often? – What requests do they make?
24. © 2013 IBM Corporation Implications for security • Relations between app, user, and data may be different – You may not know the app [developer] – The app may not own the data – The app user may not trust the app
25. © 2013 IBM Corporation Oauth: the valet key for the Internet • Sets out to solve the problem of allowing apps to access resources, without giving them the keys to everything.
26. © 2013 IBM Corporation OAuth terminology • Resource owner – The end user who owns some content • Resource server – The system where the content resides • Client – The app that wishes to access the content for the user • Authorization server – Manages access by the app on behalf of the user
27. © 2013 IBM Corporation Oauth three-legged flow, in a nutshell Client redirects user to authorization server, which asks the user to authorize the app. The user authorizes the app, and is redirected back to the client. The client is returned an authorization code. The client uses the authorization code to request an access token. The user is now logged in. On subsequent requests, the client passes the access token. client authorization server / resource server user agent http://tools.ietf.org/html/rfc6749
28. © 2013 IBM Corporation IBM API management API providers use the API builder to • define and expose APIs • set API invocation limits • configure security for APIs • analyze API usage API consumers use the API store to • discover APIs and documentation • register and manage apps • track their usage of APIs
29. © 2013 IBM Corporation Application identity • Registered applications identified with API key – Used on all invocations – API secret may be required – Basis for analytics
30. © 2013 IBM Corporation APIs and entitlements • Entitlements define the contract between app and API – Approval – Identification with secret – Rate limits
31. © 2013 IBM Corporation Authenticating users • User credentials may be supplied with API request – Authenticated in addition to application identity – Uses HTTP Basic Auth mechanism
32. © 2013 IBM Corporation API management on-premise
33. © 2013 IBM Corporation We love your Feedback! Don’t forget to submit your Impact session and speaker feedback! • Your feedback is very important to us – we use it to improve next year’s conference • Go to the Impact 2013 SmartSite (http://impactsmartsite/com): ‒ Use the session ID number to locate the session ‒ Click the “Take Survey” link ‒ Submit your feedback
34. © 2013 IBM Corporation
35. © 2013 IBM Corporation Legal Disclaimer •© IBM Corporation 2013. All Rights Reserved. •The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. •References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results. •If the text includes any customer examples, please confirm we have prior written approval from such customer and insert the following language; otherwise delete: All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. •Please review text for proper trademark attribution of IBM products. At first use, each product name must be the full name and include appropriate trademark symbols (e.g., IBM Lotus® Sametime® Unyte™). Subsequent references can drop “IBM” but should include the proper branding (e.g., Lotus Sametime Gateway, or WebSphere Application Server). Please refer to http://www.ibm.com/legal/copytrade.shtml for guidance on which trademarks require the ® or ™ symbol. Do not use abbreviations for IBM product names in your presentation. All product names must be used as adjectives rather than nouns. Please list all of the trademarks that you use in your presentation as follows; delete any not included in your presentation. IBM, the IBM logo, Lotus, Lotus Notes, Notes, Domino, Quickr, Sametime, WebSphere, UC2, PartnerWorld and Lotusphere are trademarks of International Business Machines Corporation in the United States, other countries, or both. Unyte is a trademark of WebDialogs, Inc., in the United States, other countries, or both. •All references to Acme refer to a fictitious company and are used for illustration purposes only.