I would like to use an API Gateway HTTP integration towards an endpoint, where certain parts of the URL are provided by the custom authorizer (e.g., user ID or user grants).
I could definitely use a Lambda integration but that introduces quite significant response time overhead.
Unfortunately syntax that works for stageVariables does not seem to work for custom authorizer context - ${context.authorizer.variableName}.
Note: To answer some comments, yes, the warning sign is there bacause I used a dummy url string. Has nothing to do with the fact that replacement of authorizer context variables does not work for me, no matter what the URL is.
The URL needs to valid, meaning like https://example.com/foo with a protocol and hostname.
Starting with url/ is never going to be valid.
Related
I am using the DocuSign REST API to send documents and we are trying to take advantage of the webhook capabilities.
Our problem is that we have basic auth set up on our webhook listener which it doesn't appear is supported in the REST API. I am enquiring whether or not this is an accurate understanding. I know it is possible on the Connect product, which the basic auth can be set up via the portal, however I am looking specifically for API REST calls.
How can I secure the EventNotification event?
Many thanks,
Mitch.
As of now, according to docusign offical post:
Individual Envelope Connect configurations created with the eventNotifications API option do not support Basic Authentication at this time.
A WORKAROUND SOLUTION:
Docusign has an official blog post to answer this question. Securing Your Connect Webhook Listener
For us, we use the Use a Pre-shared Secret method to secure our webhook. We are using the python sdk. During the process we create the EventNotification, we add a secret parameter to the webhook listener url. When the docusign post the request to your listener server, it will include the secret. You could check the parameter to make sure the request is valid.
event_notification = EventNotification()
event_notification.url ='your webhook_url' + '?secret=' + 'your_secret')
The text below is quoted from the blog post.
This defense acts both as access control and authentication. The
listener URL you provide to DocuSign can include one or more query
parameters. DocuSign will include them during its POST request to your
listener.
For access control, your listener will first check that the request
includes the expected query parameter and reject all requests that
don’t. For authentication, your listener will additionally check the
value of the query parameter. Remember that you can encode any values
for the name and value of the query parameter. For this example, we’re
using “pw” as the name of the query parameter.
To use a pre-shared secret, just set the URL accordingly in the
Connect configuration. For example,
https://listener_url.example.com/listener?pw=secret
Remember that the complete URL, including its query parameters, is
encrypted before it is sent across the internet. The URL and its query
parameters are visible in various logs and configuration screens,
including the Connect webhook configuration page.
I've set up an API gateway to a lambda function. It's a really simple POST call to a simple function that takes a string in and returns a string.
The call works but when I configured the API call's authorization to require AWS_IAM it just kept allowing calls to succeed - even calls from a simple little test app I wrote that makes no attempt to set authorization parameters. It's the same from Postman - I set it to no authorization and it still works.
I have to be missing something.
Can anyone tell me what, please?
Thanks,
Adam.
Did you remember to redeploy the API to your stage after updating the method to require AWS_IAM authorization?
I read many posts about passing sensible data in a GET request but didn't find an answer that would suit my needs.
I have to expose a RESTful resource that will check the password strength.
GET http://api.domain.com/security/password/P#55w0rd
I find the GET HTTP verb suitable since I only want if the password is secure enough.
The problem is that the client will be forced to pass it in the resource (i.e. URL).
Some colleagues told me to use POST and then pass it in the data body but I'm not sure how RESTful is it.
The REST standard just says to use HTTP Verbs. It doesn't actually mandate that you use particular ones. However some conventions have arisen about which verb to use, POST to create & GET to retrieve data, however this should not be followed religiously if it will cause an issue.
As per the following article you should not use GET for password, and yes you can use POST or pass something in the HTTP headers instead.
REST Security Cheat Sheet
Session management
RESTful web services should use session-based authentication, either by establishing a session token via a POST or by using an API key as a POST body argument or as a cookie. Usernames, passwords, session tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.
I went with this:
GET /api/public/check-password
Authorization: Basic <base64(test:<password>)>
The username must literally be either '' (empty string) or 'test'.
I chose to use
test because it's obviously not a real user
GET because no modifications are made
The Authorization header because the security middleware in (most?) application stacks already removes that from logging - so no special care is needed.
/api/public because it doesn't require authentication to do the check
I'm not in love with check-password - that sounds more RPC-ish than REST-ish... but what can you do? At least it's obvious. I'm open to other suggestions.
The SpringXDTemplate is the SpringXD java client. Build around the REST API it doesn't support Basic Authentication required by the same API:
the REST endpoints will require Basic authentication for access;
Furthermore the RestTemplate used undernet is not accessible cutting the possibility to implement the Basic Auth at lower level.
Perhaps i'm missing something? Advices are suggestions are appreciated!
I don't know this API but looking at javadocs, I see a constructor of template that accepts ClientHttpRequestFactory. So maybe if you try to pass your own implementation that will append HTTP Authorization header with basic authentication when createRequest is invoked, that may solve your problem. Otherwise I don't see other way how to "get into" the process of template.
What options are available for authentication of an MVC3 Web API application that is to be consumed by a JQuery app from another domain?
Here are the constraints/things I've tried so far:-
I don't want to use OAuth; for private apps with limited user bases I cannot expect end users to have their accounts on an existing provider and there is no scope to implement my own
I've had a fully functioning HMAC-SHA256 implemention working just fine using data passed in headers; but this doesn't work in IE because CORS in IE8/9 is broken and doesn't allow you to send headers
I require cross-domain as the consuming app is on a different domain to the API, but can't use jsonp becuase it doesn't allow you to use headers
I'd like to avoid a token (only) based approach, as this is open to replay and violates REST by being stateful
At this point I'm resigned to a HMAC-SHA256 approach that uses either the URL or querystring/post to supply the hash and other variables.
Putting these variables in the URL just seems dirty, and putting them in the querystring/post is a pain.
I was succesfully using the JQuery $.ajaxSetup beforeSend option to generate the hash and attach it to the headers, but as I mentioned you can't use headers with IE8/9.
Now I've had to resort to $.ajaxPrefilter because I can't change the ajax data in beforeSend, and can't just extend data in $.ajaxSetup because I need to dynamically calculate values for the hash based on the type of ajax query.
$.ajaxPrefilter is also an issue because there is no clean/simple way to add the required variables in such a way that is method agnostic... i.e. it has to be querystring for GET and formdata for POST
I must be missing something because I just cannot find a solution that:-
a) supports cross-domain
a) not a massive hack on both the MVC and JQuery sides
c) actually secure
d) works with IE8/9
There has to be someone out there doing this properly...
EDIT
To clarify, the authentication mechanism on the API side is fine... no matter which way I validate the request I generate a GenericPrincipal and use that in the API (the merits of this are for another post, but it does allow me to use the standard authorization mechanisms in MVC, which I prefer to rolling my own... less for other developers on my API to learn and maintain)
The problem lies primarly in the transfer of authentication information from the client to the API:-
- It can't rely on server/API state. So I can't pass username/password in one call, get a token back and then keep using that token (open to replay attack)
- Anything that requires use of request headers is out, because IE uses XDR instead of XHR like the rest of the browsers, and it doesn't support custom headers (I know IE10 supports XHR, but realistically I need IE8+ support)
- I think I'm stuck generating a HMAC and passing it in the URL somewhere (path or querystring) but this seems like a hack because I'm using parts of the request not designed for this
- If I use the path there is a lot of messy parsing because at a minimum I have to pass a username, timestamp and hash with each request; these need to be delimited somehow and I have little control over delimiters being used in the rest of the url
- If I use data (querystring/formdata) I need to change the place I'm sending my authentication details depending on the method I'm using (formdata for POST/PUT/etc and querystring for GET), and I'm also polution the application layer data space with these vars
As bad as it is, the querystring/formdata seems the best option; however now I have to work out how to capture these on each request. I can use a MessageHandler or Filter, but neither provide a convienient way to access the formdata.
I know I could just write all the parsing and handling stuff myself (and it looks like I will) but the point is I can't believe that there isn't a solution to this already. It's like I have (1) support for IE, (2) secure and (3) clean code, and I can only pick two.
Your requirements seem a little bit unjustified to me. You can't ever have everything at the same time, you have to be willing to give something up. A couple of remarks:
OAuth seems to be what you want here, at least with some modifications. You can use Azure's Access Control Service so that you don't have to implement your own token provider. That way, you have "outsourced" the implementation of a secure token provider. Last I checked Azure ACS was still free. There is a lot of clutter when you look for ACS documentation because people mostly use it to plug into another provider like Facebook or Google, but you can tweak it to just be a token provider for your own services.
You seem to worry a lot about replay attacks. Replay attacks almost always are a possibility. I have to just listen to the data passing the wire and send it to your server, even over SSL. Replay attacks are something you need to deal with regardless. Typically what I do is to track a cache of coming requests and add the hash signature to my cache. If I see another request with the same hash within 5 minutes, I ignore it. For this to work, I add the timestamp (millisecond granularity) of the request and some derivative of the URL as my hash parameters. This allows one operation per millisecond to the same address from the same client without the request being marked as replay attack.
You mentioned jQuery which puzzles me a bit if you are using the hashing method. That would mean you actually have your hash algorithm and your signature logic on the client. That's a serious flaw because by just inspecting javascript, I can now know exactly how to sign a request and send it to your server.
Simply said; there is not much special in ASP.NET WebAPI when it comes to authentication.
What I can say is that if you are hosting it inside ASP.NET you'll get support by ASP.NET for the authentication and authorization. In case you have chosen for self-hosting, you will have the option to enable WCF Binding Security options.
When you host your WebAPI in ASP.NET, you will have several authentication options:
Basic Authentication
Forms Authentication - e.g. from any ASP.Net project you can enable Authentication_JSON_AppService.axd in order to the forms authentication
Windows Authentication - HttpClient/WebHttpRequest/WebClient
Or explicitly allow anonymous access to a method of your WebAPI