I use AWS Lambda as a backend service to authenticate users from my ios app. When learning about Lambda I was pointed to use the Amazon API Gateway to make the data over the network go over HTTPS:// and NOT HTTP://.
Someone recently pointed out that all calls to AWS Lambda, DynamoDB, S3, and Cognito directly from my app automatically go over HTTPS://. Is this true or not?
Unfortunately the docs are not explicit on the matter, that I could find, but inspecting the source on github:
AWSService, one of the base services used by the sdk, uses https by default, and will only switch to http if the AWSServiceConfiguration particular configuration is established with the parameter useUnsafeUrl set to true.
And AWSLambdaService, even if initialised with a configuration object, appears to set the useUnsafeUrl option to NO.
So - inspection of the source suggests that all access to the service is by default https.
This is consistent with AWS SDK defaults in other languages/frameworks as well.
-- Edited to note --
I had a thought after posting this - it's possible that the advice to use API Gateway for https was based on the common practice of exposing Lambda functions as API endpoints. If you want to do that, then API Gateway gives you a way, and if you are using API Gateway, then you do need to ensure it is configured to use https.
What is not clear from your question is - from your app, are you invoking the lambda functions via the API Gateway endpoint? Or directly via the AWS SDK? If invoking directly via the AWS SDK then there is no need to use API Gateway at all.
If you are already using the API Gateway, and issuing HTTPS web requests to invoke your lambda functions, I wouldn't necessarily stop, because it gives you a nice point of abstraction and decoupling - you could completely change your backend implementation and as long as you keep the API Gateway endpoint configuration the same, your clients will still work. Alternatively, you could start to implement other clients or expose your API to 3rd party clients who aren't in a position to use AWS SDK and they will still be able to interract with your backend via standard HTTP protocols.
Related
We have a service that sends delivery notification messages to a client via HTTP requests - meaning, the client must also act as a Server (must expose an HTTP endpoint) in order to receive these notifications.
Some of our clients are asking that our requests authenticate against their endpoints via OAuth. We would prefer to implement this using a third-party so as to avoid having security features implemented in-house (and avoid security issues/not well-handled edge cases that we could end up introducing); More specifically, we'd prefer to have a reverse-proxy.
The idea would be that our service would send a request to the client through the reverse proxy, which would identify that the request is missing a token and would be responsible for getting a token and injecting it into the request.
I googled for this but couldn't find anything; perhaps I'm not searching for the correct keywords. Is there a packaged/"market" reverse-proxy solution for this? Or perhaps a programmable reverse-proxy that could bootstrap a solution for us?
I can see two approaches for this:
have an oauth2 client library in your own code to handle the oauth2 authentication flow for your app. Most programming languages have an oauth2 client so you wouldn't re-implement anything and have a secure authentication mechanism,
use a proxy that implements an oauth2 client so it would do that part of the flow for your service but I'm not sure it exists. I couldn't find anything also related to this because of the fact that most of the languages have an oauth2 client that's readily available.
I hope you find the solution to your problem :)
I want to use API Gateway for its mutual TLS capability and add it to an existing .net fx 4.8 web application hosted in IIS which is fronted by and AWS ALB:-
client browser -> apigw -> alb -> ec2
I have configured the apigw method to return html and to use proxy integration, but I am having issues in a couple of places:-
any request made to a subfolder of the mapped path returns {"message":"Missing Authentication Token"}
images are not being returned (tested by using the iis home page on the root
In the absence of any api auth being configured, I understand that the missing token response could indicate a bad url. I am new to apigw so I may be missing something obvious, but I cannot believe I would have to map every single possible path available in our web app in the apigw config - there are simply too many!
I have read a few articles/messages talking about handling images but these either refer to using s3 as the store or, in the case of the image being the only thing in the response, configuring the apigw to return an image content type. In this case of a .net web app which will return html and images, I have not found any advice.
So my question is (before I spend way too long trying to make this work!), is it possible or even advisable to front a .net fx web app with an aws api gateway?
You need to configure "Catch-all Path Variables" in API Gateway, as described here.
My backend is a simple dockerized Node.js express app deployed onto elastic beanstalk. It is exposed on port 80. It would be located somewhere like
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com
I can call my APIs on the backend
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com/hello
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com/postSomeDataToMe
and they work! Yay.
The URL is not very user friendly so I was hoping to set up API gateway to allow to me simply forward API requests from
api.myapp.com/apiFamily/ to mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com
so I can call api.myapp.com/apiFamily/hello or api.myapp.com/apiFamily/postMeSomeData
Unfortunately, I can't figure out (i) if I can do this (ii) how to actually do it.
Can anybody point me to a resource that explains clearly how to do this?
Thanks
Yes, you can do this. For this to happen you need two things:
a custom domain that you own and control, e.g. myapp.com.
a valid, public SSL certificate issued for that domain.
If you don't have them, and want to stay within AWS ecosystem, you can use Route53 to buy and manage your custom domain. For SSL you can use AWS ACM which will provide you with free SSL certificate for the domain.
AWS instructions on how to set it up all is:
Setting up custom domain names for REST APIs
We currently have the following architecture (for a RoR based production system)
A gateway, which also acts as auth (oauth functionality implemented using DoorKeeper) is the starting point for all requests coming from the front end.
The system is working perfectly well. The task we are faced with now involves addition of a legacy application (written in multiple languages, including ASP.NET). This legacy application currently works fine as a standalone system. What we intend to do is
Integrate the legacy system within our working system (within our own subnet)
Do minimum (or if possible zero) modifications to the legacy system
keep using our oauth layer (gateway) as the first point of contact for all incoming requests (including the requests to the legacy system)
We are in control of the front end requests and routing, so CSRF is not a concern
One solution that we are considering is that the auth layer (gateway) also acts as a reverse proxy. In essence any request coming for the legacy environment (from the legacy front end clients) will be authenticated by doorkeeper but they will now be redirected to the legacy server-application and the response is then send back to the client.
The above sounds like a nginx reverse proxy, but I want a RoR gem which I can use because I want this to be flexible for future modifications. For example (but not limited to)
I can modify the legacy client to start using multiple auth mechanisms (so the request from client to auth layer will have different headers, but I would like to change this request to its legacy format during the journey from auth-legacy-backend-server-application and back) [easier]
I would like to add encryption (SSL) on client to auth (gateway) requests. The gateway will decrypt the request and send un-encrypted request for the auth-legacy-backend-server-application and back journey) [tougher]
A few of the legacy system requests are such that Legacy-FrontEnd (LFE) --> Legacy-Backend (LBE) use cookie based sessions. I want to use the gateway to simulate this behavior.
LFE -> gateway uses my auth mechanism (say encrypted tokens)
gateway -> LBE simulates the cookie based sessions behavior
gateway keeps the mapping of token to session-cookie
[the last point above is a over simplification of a use case we might encounter at a later date]
I am building a RESTFul API and wondering what's the best way to do auth? Users will need to authenticate. I know of three ways:
1.) Pass API key in every RESTFul requests:
http://api.mydomain.com/api-key-here/get-users
This is nice because developers can immediately start using the API by simply copying URL string into the browser. Are there any potential security risks though?
2.) Every request passes the API key in the header of the request.
This seems to be more secure, but developers can't make requests via their browser. CURL is required.
3.) oAuth
I must admit I don't know much about it, but seems very popular. My concern is that its a barrier for developers to start using the API. They first must be familiar with oAuth, and have it setup.
Thoughts? Thanks greatly.
If your concern is burdening developers with a high cost to entry, I suggest basic auth, but running your API over https.
I do this with Diligent Street and it works really well. I use an API Key and couple it with a Secret as the username/password combination for basic auth.
I have employed the technique found here: Build a RESTful API. This solution uses an MD5 hash of your API ID, API secret and the UNIX Time stamp and passed in the HTTP header. This authentication method is the same used by Mashery’s Authentication.
This link references and contains a full blown starter kit for creating an API that has Auth, Membership and*API Usage Metering* along with a supporting EF database.
As for testing the service you can use RESTClient to execute HTTP calls with custom headers instead of using Curl.