Security Options

There are several different mechanisms that can be used to provide security for your API and portal. Below are the options for security relating to the Proxy.

  • SSL – client/server
  • Whitelist
  • Shared secret
  • OAuth
  • HTTP-Auth

SSL

(Secure Socket Layers) can be utilized to encrypt traffic over the internet.  There are two different use cases for SSL with regard to your API.  Adding SSL to the segment of the API call between the Mashery Proxy and your Endpoint is included for all levels of the Mashery API service, there is no additional cost.  We will self sign a certificate and provide you with the key and certificate to install on your server. 

Client facing SSL, allowing users to submit via HTTPS rather than HTTP is available though not included in any of the offerings. Client side SSL will result in a recurring monthly fee. In order to do client side SSL you will need to provide us with the SSL key and SSL certificate for Mod/SSL or openSSL.

Whitelist

If you choose to allow only Mashery Proxied traffic through to your servers we recommend an IP whitelist as a simple solution.  The following list contains the Mashery Proxy IP addresses, failover IP addresses as well as the various monitoring IP addresses that Mashery uses to monitor your Direct API. If you would not like to add the entire list please select at least 5 monitoring locations and notify Mashery so that we can disable monitoring from the other locations.
Please note that if you select a location that has more than one IP you have to whitelist all the IPs listed for that location.

 

Internap IPs (NOTE: network blocks)

119.59.74.32/27 Honk Kong
64.94.14.0/27 Atlanta
216.52.244.96/27 Los Angeles

AWS Gateway IPs (US)

75.101.137.168
75.101.142.168
75.101.146.168
75.101.141.43
75.101.129.141

AWS Gateway IPs (Europe)

79.125.12.130
79.125.12.141
79.125.12.145

Monitoring servers – IP’s that we use to proactively monitor your API’s:

208.73.222.10 Atlanta, GA
208.73.219.22 Atlanta, GA
59.108.227.39  Beijing, China
72.46.127.9 Boston, MA
72.46.126.116    Boston, MA
200.43.192.223  Buenos Aires, Argentina
69.59.25.39    Charlotte, NC
208.100.38.179  Chicago, Il
69.56.226.74 Dallas, TX
75.125.175.138 Dallas, TX
67.19.150.138 Dallas, TX
216.7.173.196  Denver, CO
79.125.50.108  Dublin, Ireland
123.242.230.68  Hong Kong
208.109.177.88  Las Vegas, NV
89.187.68.81 London, England
72.34.227.42  Los Angeles, CA
72.51.35.30  Los Angeles, CA
85.238.3.179 Madrid, Spain
204.10.109.237  Miami, FL
69.74.45.245  New York, NY
69.74.45.153  New York, NY
209.92.144.57 Philadelphia, PA
209.188.15.140  Phoenix, AZ
64.151.100.28 San Francisco, CA
208.78.244.120  San Jose, CA
69.12.104.163 Seattle, WA
206.196.98.41  St. Louis, MO
202.157.179.14  Sydney, Australia
213.8.152.163  Tel Aviv, Israel
202.51.11.173  Tokyo, Japan
64.34.168.197 Washington, DC

Shared Secret

Mashery supports Shared Secrets.  Shared secrets can be set to be automatically assigned to users receiving keys via the Mashery service.  By default the shared secret is hashed with the current time (GMT) allowing for 5 minutes of clock drift.  Through the use of Custom Adapters which we have built in to the system Mashery can support virtually any kind of authentication request utilizing Shared Secrets and signatures.

OAuth

We offer an OAuth accelerator so you can add OAuth to your API with very little effort or cost.  OAuth allows a user to designate access to his data to a third party while protecting his credentials.  The authorization token can be revoked at any time.

Mashery can handle two different approaches to OAuth.

  1. Mashery OAuth Accelerator.  Mashery acts as the token provider.  Our Client creates a page on their system which allows a user to allow or revoke access to their data.  Our Client then uses Mashery's API to create or revoke access for a particular site.  Mashery handles the authentication of calls.  This path requires that the Client do very little to implement OAuth and can focus on their core business.
  2. Client implemented OAuth.  Some clients may wish to handle OAuth on their own, in this case the OAuth call looks just like any other API call being made through the proxy.  The client must create the system to create and manage OAuth tokens as well as authenticate calls.

HTTP-Auth

Some clients prefer to not shut off access at the edge of their network using whitelists, but would rather control access on a call by call basis.  By adding an http challenge to your application/webserver you will be able to allow access to users with the correct credentials.  Mashery can easily add the appropriate username/password pair to all calls made to your Direct API. 

Comments

New comments are not being accepted at this time.