Securing Insecure

Prabath Siriwardena, WSO2

Twitter : @prabath

Perception

Perception

Perception

Correctness

C-I-A

Confidentiality

Integrity

Availability

Correctness

The Weakest Link

Insider Attacks

Defense In Depth

Threat Modeling

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Contact us !