From a8a7f727cc2b025f255372f2cc0b46f57e1bb702 Mon Sep 17 00:00:00 2001 From: Soumya Ray Date: Mon, 22 May 2017 22:35:14 +0800 Subject: [PATCH] Create policy+validation assignment --- descriptions/060_token_authorization.md | 8 +++--- descriptions/070_policies_validation.md | 30 +++++++++++++++++++++ descriptions/070_validation_ssl.md | 28 -------------------- descriptions/080_token_authorization.md | 35 ------------------------- 4 files changed, 35 insertions(+), 66 deletions(-) create mode 100644 descriptions/070_policies_validation.md delete mode 100644 descriptions/070_validation_ssl.md delete mode 100644 descriptions/080_token_authorization.md diff --git a/descriptions/060_token_authorization.md b/descriptions/060_token_authorization.md index 9e02f71..87173d6 100644 --- a/descriptions/060_token_authorization.md +++ b/descriptions/060_token_authorization.md @@ -30,6 +30,8 @@ This week we will introduce authorization to our system, using authorization tok - Allow users to see their own token in their account page 4. API+App: Add features in App to view all resources - - Users can see their account information - - Users can see all resources they own - - Users can see all resources they are shared with others + - Ensure your API not only allows for authentication, but can now create/find one or more resources that belong to accounts + - Ensure that your Web App has views to create/retrieve resources + - Users can see their account information + - Users can see all resources they own + - Users can see all resources they are shared with others diff --git a/descriptions/070_policies_validation.md b/descriptions/070_policies_validation.md new file mode 100644 index 0000000..8ed14b6 --- /dev/null +++ b/descriptions/070_policies_validation.md @@ -0,0 +1,30 @@ +# Validated Form Input and Enforce SSL + +This week we will create centralized resource policies, and validate user input coming from web forms. See the latest version of our demo project: +- [Web API: auth_policy](https://github.com/ISS-Security/configshare-api/tree/6_auth_policy) +- [Web App: authorized_access](https://github.com/ISS-Security/configshare-app/tree/4_policy_validation) + +1. Formal Policies + - API: Create policy objects in a `/policies` folder of your API + - Create at least one policy object per resource (e.g., 'ProjectPolicy', 'ConfigFilePolicy', etc.) + - Initialize policy objects with appropriate model objects (e.g., account seeking to access resource, particular resource) + - Create true/false predicate methods check for key actions (creation/deletion/updating/viewing, etc.) + - Make your predicate methods readable by using descriptive private helper methods + - Use your policy objects in each API resource route to check authorization of agent + - API: Create policy scope objects + - Scope objects should return lists of all relevant objects for a given action (e.g., `viewable`) and agents (e.g., `current_account`) + - Scope objects could evaluate permission of account requesting access + - Use your policy scope objects to retrieve list of objects to return on index routes (e.g., `/api/v1/accounts/:id/projects`) + - API + Web App: Policy summaries + - API: Create a `summary` method for each policy object that returns a hash of all predicate names and results + - API: Routes that return a resource should return a jsonified summary of its policy for the given account + - Web App: Forms should determine authorization to show links/buttons/resources based on policy summaries returned by API +3. Web App: Validating Form input + - Use the `dry-validation` gem to create validation schema for your views + - Every view should have a unique schema defined by a *form object* + - Put your form objects in a new `/forms` directory + - Create custom rules for rules that use multiple input fields + - Choose between using `dry-validation`'s messages and creating custom error messages + - Use form objects in your controllers + - Pass your `params` directly to your form objects + - See that your controllers are now using only form objects and service objects to handle all non-routing logic diff --git a/descriptions/070_validation_ssl.md b/descriptions/070_validation_ssl.md deleted file mode 100644 index 3331b84..0000000 --- a/descriptions/070_validation_ssl.md +++ /dev/null @@ -1,28 +0,0 @@ -# Validated Form Input and Enforce SSL - -This week we are validating user input coming from web forms, and enforcing -SSL connections between essential parts of our architecture. Take a look at the -[latest code for the app client](https://github.com/ISS-Security/configshare-app/tree/3-validation_ssl). - -1. Validating Form input - - Use the `dry-validation` gem to create validation schema for your views - - Every view should have a unique schema defined by a *form object* - - Put your form objects in a new `/forms` directory - - Create custom rules for rules that use multiple input fields - - Choose between using `dry-validation`'s messages and creating custom error - messages - - Use form objects in your controllers - - Pass your `params` directly to your form objects - - See that your controllers are now using only form objects and service - objects to handle all non-routing logic -2. Add flash messages for errors and notices - - Use the `rack-flash3` gem to create flash messages - - Add a flash message bar to your `layout.slim` - - Create CSS file in `/public` folder for `:error` and `:notice` styles - - Set the location of your public directory for Sinatra - - Provide flash notices for form errors and important transitions (e.g., logout) -3. Enforce SSL connections - - Use the `rack-ssl-enforcer` gem to enforce SSL connections on *production* servers (won't work during development/testing) - - Enforce SSL for both your API and your web application - -Deploy your Web application to Heroku this week: we have fixed most of the major security vulnerabilities, but a few issues still remain for future weeks. diff --git a/descriptions/080_token_authorization.md b/descriptions/080_token_authorization.md deleted file mode 100644 index 0c63a2f..0000000 --- a/descriptions/080_token_authorization.md +++ /dev/null @@ -1,35 +0,0 @@ -# Token Based Authorization - -This week will implement the beginnings of authorization, and we will use tokens once again. Note that all the critical authorization decisions will be done on the API side. Thus, the API must create and send an encrypted token that must be returned by client applications on every request. - -For example code, take a look at the following branches of the API and App: -- [API: authorized_access](https://github.com/ISS-Security/configshare-api/tree/5_auth_token) -- [App: authorized_access](https://github.com/ISS-Security/configshare-app/tree/3_auth_token) - -1. API: Send and Require an Authentication Token from Client Apps - - Create `JWE` or such library class to encrypt/decrypt JWT tokens for API - - Return an encrypted token when client applications authenticate credentials (username, password) - - Change API authentication route: - - use POST instead of GET - - require authentication credentials as json in HTTP body instead of URL parameters - - make authentication route something like: `/api/v1/accounts/authenticate` - - Return: - - regular a account information (`id`, `username`, `password`) for the application - - an encrypted JWT that only the API can decrypt in future (expire after a week or so) - - Check authentication token on each data related request - - Create helper methods that verify identify of account identity of token with resource owner - - Check token in `HTTP_AUTHENTICATION` header of HTTP request as `'Bearer '` - - Return error 401 for any suspicious cases: - - if token is expired - - if identify of owner in `auth_token` does not match route - - if resource does not belong to account in `auth_token` -2. App: Return API's `auth_token` on every request - - Store API `auth_token` in user session cookie along with regular account information - - Send `auth_token` to API in every request as `HTTP_AUTHENTICATION` header: `'Bearer '` - - Allow users to see their own token in their account page -3. API+App: Add features - - Add features in App to view all resources: - - Users can see their account information - - Users can see all resources they own - - Users can see all resources they are sharing with others - - Make sure all new API routes you need use token based authorization