security-kickstart

A demo of various Apigee security capabilities such as shared flows, oauth, rate limiting, json payload protection, sql injection protection, and SOAP payload injection

Introduction

Apigee provides a plethora of out-of-the-box security solution. In this repository you will personally test out a few of them in the format of a reproducable demo.

Assumptions

1. You already have an Apigee X org provisionined
2. You have Postman downloaded and ready to use. Postman is a free service that we will use to call our API endpoints

Intial Setup

1. Download the sharedflowbundle folder from within the OAuthQuota folder to your computer and zip it. Rename your zip to "OAuthQuota". Your zip file should now contain a folder named "sharedflowbundle". Once this is done upload it to Apigee as a shared flow bundle to create a new shared flow called "OAuthQuota". Be sure to deploy this shared flow on the following page after creation.
2. Download the apiproxy folder from within the oauth folder to your computer and zip it. Rename your zip to "oauth". Your zip file should now contain a folder named "apiproxy". Once this is done upload it to Apigee as a proxy bundle to create a new proxy called "oauth". Be sure to deploy this proxy on the following page after creation.
3. Download the apiproxy folder from within the secured folder to your computer and zip it. Rename your zip to "secured". Your zip file should now contain a folder named "apiproxy". Once this is done upload it to Apigee as a proxy bundle to create a new proxy called "secured". Be sure to deploy this proxy on the following page after creation.
4. From the Apigee console, create a new developer with a name and email of your choosing
5. From the Apigee console, create a new product called secured-product. Configure it with public access, a quota of 5 requests every 1 minute, and add an operation for the secured proxy with a path of "/". Don't forget to click save.
6. From the Apigee console, create a new app called secured-app. Configure it with your newly created developer, no callback URL, add your secured-product under credentials, approve the secured-product, and set it to never expire. Don't forget to save. After saving, make note of the client id and secret.
7. Navigate to the following links, update the request with our organization, and click the Execute button to create an Apigee Key Value Map (KVM) and populate it with mock username and password credentials. These credentials will be used for our AssignMessage SOAP policy.

• Create KVM
• Create KVM username entry
• Create KVM password entry

8. Download SecuredAPIDemo.postman_collection.json to your computer. Then import it to Postman as a new collection to create a new collection called "SecuredAPIDemo"
9. From Postman, navigate to your newly imported collection's variables as shown in the below image. Update the current value for api_domain with the domain retreived from Apigee at Admin > Environments > Groups, update the value for client_id from your Apigee App, and update the value for client_secret from your Apigee App. Don't forget to save with CTRL+S. We'll update the oauth_token value in our demo.

Demonstrate

We'll be using Postman to call our API and test out our security features.

A Few Notes First

There are a few things happening in the demo that aren't explicitely mentioned in the demo:

• Our secured proxy is configured to send requests to https://httpbin.org/anything. That endpoint will simply return the plain text of the request itself. This is helpful for this demo so we can quickly and easily understand exactly what our request looks like when we pass it off to the backend.
• In the shared flow we are not only enforcing OAuth security and our quota, but we also subtly remove the client token from the request so it doesn't unecessarily appear anywhere downstream in the request
• In the secured proxy target endpoint request preflow, we add a cors policy to allow requests from any source. In a production environment, we'd want to update this policy to only allow requests from desired sources and in desired formats
• Our api proxies are all prepended with a "/v1" path. This is best practice for production APIs as you'll want to prepare for the possibility of future versions
• As you demo in Postman, feel free to flip back and forth between Apigee as well to understand the policies your requests are hitting

Postman Demo

1. Get our OAuth token: From the Secured API Demo Postman collection, click on the Retreive Token POST call. Send this request to exchange your client_id and client_secret values for a newly minted OAuth token. Note the temporary OAuth token from the access_token field in the response. From Postman, navigate to your newly imported collection's variables as done previously for the domain, client_id, and client_secret variables. Assign your OAuth token against the oauth_token variable. All future calls with be authenticated with this OAuth token in the header.
2. Verify the OAuth token: From the Secured API Demo Postman collection, click on the Use Token GET call. Send the request and note the response. You should receive a 200 success message, verifying that your OAuth token is valid and being used properly.
3. Test Quota: Our product is configured to only allow 5 requests per minute. From the Use Token GET call, send 6-7 requests as quickly as Postman will let you. Around the 6th request you should receive a quota violation error.
4. Test JSON Payload Validation: Our API proxy is configured to only allow JSON payload with 5 or less top-level properties within it. To demonstrate navigate click on the Use Token JSON Good POST request and click send. Note the request's body before sending a request and receiving a 200 response. Next, navigate on the Use Token JSON Bad POST request and click send. Note the request's body before sending it and receiving an error message.
5. Test SQL Injection: Our API proxy is configured to check the value for any URL parameters under the name of studentId for attempts of SQL injection. To demonstrate this navigate to the Use Token SQL Good GET request and click send. Note the request's url parameter before sending a request and receiving a 200 response. Next, navigate to the Use Token SQL Bad GET request and click send. Note the request's url parameters before sending it and receiving an error message
6. Test SOAP Security: The endpoint "/soap" within our API proxy is configured to augment the incoming request to enable it to authenticate with a legacy SOAP backend.To demonstrate this navigate to the Use Token SOAP request and click send. Note that the request's lack of a payload body and the body returned in the response. This will demonstrate how our proxy added SOAP auth security to our request. Also worth pointing out in the demo that the username and password are securely stored in KVM.