Skip to content
This repository has been archived by the owner on Mar 5, 2019. It is now read-only.

Protect the api so that POSTs, PUTs, PATCHs and DELETEs are restricted #156

Open
JohnSmall opened this issue Feb 19, 2017 · 1 comment
Open

Comments

@JohnSmall
Copy link

Description

We need to ensure that the api does not expose methods that can change the data, except to certain people or processes.

Comments, Questions and Considerations

There are two main ways to do this ;-
(1) use OAuth and require people to sign in if they want to change things. That requires maintaining a list of valid users.

(2) Use an API gateway, like Mashery, Apigee, or Amazon API gateway and require client certificates to communicate with the API.

Acceptance Criteria

This story can be considered done when the following acceptance tests
are satisfied:

Scenario: A non-authenticated user attempts to change the data
Given I am a non-authenticated user
When I attempt the change the data
Then it will not be successful

Scenario: A non-authenticated user attempts to read the data
Given I am a non-authenticated user
When I attempt to read the data
Then it will be successful

Scenario: A non-authenticated user attempts a Ddos attack
Given I am a non-authenticated user
When I try to overload the server with requests
Then the server will not be taken down

Scenario: An authenticated user attempts to change the data
Given I am an authenticated user
When I try to change the data
Then it will be successful

Scenario: An authenticated user attempts to read the data
Given I am an authenticated user
When I attempt to read the data
Then it will be successful

Scenario: An authenticated user attempts  a Ddos attack
Given I am an authenticated user
When I try to overload the server with requests
Then the server will not be taken down

Simple OAuth cannot restrict traffic, therefore we should first look at the API gateway + client certificate option. I'll do a spike to learn how to use Amazon API gateway to do this.

@JohnSmall JohnSmall self-assigned this Feb 19, 2017
@aspiers
Copy link
Member

aspiers commented Feb 20, 2017

This is great. I suggest it might make sense to separate out the rate throttling into a separate issue. Presumably any throttling rates would be a function of whether the user is authenticated (and if so, as whom), therefore I guess it makes sense to sort out the authentication and read-only functionality first, and then implement the throttling later.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants