Securing Insecure
Download as PPTX, PDF0 likes1,074 views
The document discusses various patterns for securing APIs in different enterprise scenarios. It outlines 12 different problem statements involving securing APIs that can only be accessed by employees via web/mobile applications, ensuring authentication and authorization, and integrating with identity providers while supporting single sign-on. The patterns cover securing APIs within and across departments, supporting third-party partners, non-repudiation of API calls, and securing APIs without changing the APIs or clients.
Securing Insecure
- 1. Securing Insecure Prabath Siriwardena, WSO2 Twitter : @prabath
- 2. About the presenter (@prabath) • 7+ years at WSO2 • Member of OASIS Identity Metasystem Interoperability (IMI) TC,OASIS eXtensible Access Control Markup Language (XACML) TC, OASIS Security Services (SAML) TC, OASIS Identity in the Cloud TC and OASIS Cloud Authorization (CloudAuthZ) TC • Blog: http://blog.facilelogin.com • Books:
- 3. Perception
- 4. Perception
- 5. Perception
- 6. Correctness
- 10. Defense In Depth
- 11. Threat Modeling
- 12. Pattern 01 Problem Statement A medium-scale enterprise has a limited number of RESTful APIs. These APIs should only be accessed by company employees via a single web application while they are behind the company firewall. All the user data are stored in an Active Directory and the web application is connected to it to authenticate users. The web application passes logged in user’s identifier to the backend APIs and retrieves data related to the user.
- 15. Pattern 02 Problem Statement A medium-scale enterprise has a limited number of RESTful APIs. These APIs should only be accessed by company employees via a single web application while they are behind the company firewall. All the user data are stored in an Active Directory and the web application is connected to it to authenticate users. The web application needs to access the backend APIs on behalf of the logged in user.
- 18. Pattern 03 Problem Statement A medium-scale enterprise has a limited number of RESTful APIs. These APIs should only be accessed by company employees via multiple web applications while they are behind the company firewall. All the user data are stored in an Active Directory and all the web applications are connected to a SAML 2.0 Identity Provider to authenticate users. The web applications need to access backend APIs on behalf of the logged in user.
- 20. Pattern 04 Problem Statement A medium-scale enterprise has a limited number of RESTful APIs. These APIs should only be accessed by company employees via multiple web applications while they are behind the company firewall. All the user data are stored in an Active Directory and all the web applications are connected to a SAML 2.0 Identity Provider to authenticate users. The web applications need to access backend APIs on behalf of the logged in user. All the users are in a Windows domain and once they are logged into their workstations – they should not be asked to provide credentials at any point for any other application.
- 22. Pattern 05 Problem Statement A medium-scale enterprise has a limited number of RESTful APIs. These APIs should only be accessed by company employees as well as employees from trusted partners via multiple web applications. All the internal user data are stored in an Active Directory and all the web applications are connected to a SAML 2.0 Identity Provider to authenticate users. The web applications need to access backend APIs on behalf of the logged in user.
- 24. Pattern 06 Problem Statement A medium-scale enterprise has a limited number of RESTful APIs. These APIs should only be accessed by company employees via multiple web applications while they are behind the company firewall. All the user data are stored in an Active Directory and all the web applications are connected to an OpenID Connect Identity Provider to authenticate users. The web applications need to access backend APIs on behalf of the logged in user.
- 26. Pattern 07 Problem Statement A medium-scale enterprise in the finance industry needs to expose an API to its customers through a mobile application. One major requirement is that all the API calls should support non-repudiation.
- 28. Pattern 08 Problem Statement A medium-scale enterprise that sells bottled water has a RESTful API (Water API), which can be used to update the amount of water consumed by a registered user. These APIs should be accessed by any registered user via any client application - could be an android app, an iOS app or even a web application. The company only provides APIs and anyone can develop client applications to consume those. All the user data are stored in an Active Directory. Client applications should not be able to access the API directly and query about users. Only registered users can access the API – and they also should not be able to see other users information. At the same time for each update by the user – the Water API must also update user’s health care record maintained at the MyHealth.org. The user also has a user record at MyHealth.org and it too exposes an API (MyHealth API). The Water API has to call MyHealth API to update user record, on be half of the user.
- 30. Pattern 09 Problem Statement A large-scale enterprise has a set of RESTful APIs. The APIs are hosted in different departments and each department runs its own OAuth authorization server due to vendor incompatibilities in different deployments. These APIs should only be accessed by company employees via multiple web applications while they are behind the company firewall – irrespective of the department they belong to. All the user data are stored in a centralized Active Directory and all the web applications are connected to a centralized OAuth Authorization Server (also supports OpenID Connect) to authenticate users. The web applications need to access backend APIs on behalf of the logged in user. These APIs may come from different departments – having their own authorization servers. The company also has a centralized OAuth authorization server and an employee having an access token from the centralized authorization server must be able to access any API hosted in any department.
- 32. Pattern 10 Problem Statement A global organization has APIs and API clients distributed across different regions. Each region operates independent from each other. Currently both the clients and the APIs are non-secured. Need to secure the APIs without doing any changes either at the API end or at the client end.
- 34. Pattern 11 Problem Statement A company wants to expose an API to its own employees. But the user credentials must not ever go over the wire.
- 35. Pattern 12 Problem Statement A medium-scale enterprise has a limited number of RESTful APIs. These APIs should only be accessed by company employees via a single web application while they are behind the company firewall. All the user data are stored in an Active Directory and the web application is connected to it to authenticate users. The web application needs to access the backend APIs on behalf of the logged in user. The backend API must authorize the user.
- 37. Contact us !