37
Securing Insecure Prabath Siriwardena, WSO2 Twitter : @prabath

Securing Insecure

Embed Size (px)

Citation preview

Page 1: Securing Insecure

Securing Insecure

Prabath Siriwardena, WSO2

Twitter : @prabath

Page 2: Securing Insecure

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:

Page 3: Securing Insecure

Perception

Page 4: Securing Insecure

Perception

Page 5: Securing Insecure

Perception

Page 6: Securing Insecure

Correctness

Page 7: Securing Insecure

C-I-A

Confidentiality

Integrity

Availability

Correctness

Page 8: Securing Insecure

The Weakest Link

Page 9: Securing Insecure

Insider Attacks

Page 10: Securing Insecure

Defense In Depth

Page 11: Securing Insecure

Threat Modeling

Page 12: Securing Insecure

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.

Page 13: Securing Insecure
Page 14: Securing Insecure
Page 15: Securing Insecure

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.

Page 16: Securing Insecure
Page 17: Securing Insecure
Page 18: Securing Insecure

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.

Page 19: Securing Insecure
Page 20: Securing Insecure

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.

Page 21: Securing Insecure
Page 22: Securing Insecure

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.

Page 23: Securing Insecure
Page 24: Securing Insecure

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.

Page 25: Securing Insecure
Page 26: Securing Insecure

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.

Page 27: Securing Insecure
Page 28: Securing Insecure

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.

Page 29: Securing Insecure
Page 30: Securing Insecure

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.

Page 31: Securing Insecure
Page 32: Securing Insecure

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.

Page 33: Securing Insecure
Page 34: Securing Insecure

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.

Page 35: Securing Insecure

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.

Page 36: Securing Insecure
Page 37: Securing Insecure

Contact us !