This is sort of a simple question but I can't find any docs on this, or if its even possible.
I understand you need to sign the request for the document endpoint, but is it possible to do the same for the search endpoint?
I need this because I want to privately allow searches from within an application, but I do not want the outside world to search this data.
I understand I can restrict by IP address, but this is limited because the machines are shared and will not restrict others using that IP address. I also understand I could proxy the request and do checks on the proxy.
The best solution would be to sign the search for me in the same way I can sign the document push.
Is this even possible?
I've run into the exact problem but there's unfortunately no way around this. Cloudsearch only allows search access control using IP addresses as mentioned in the documentation.
One possible solution could be to use API Gateway as frontend (where you control and api-key for instance) in your application and restrict the CloudSearch access to Lambda only.
The design is then:
API Gateway <-> Lambda function <-> CloudSearch
Related
I'm building a service that provide some readonly information that is going to be used in multiples websites, some with login and some public.
I dont want to make the api public to any website so I'm not sure what auth method i should use. I have some ideas but I don't want to reinvent the wheel.
I was thinking on have the backend of this sites request a token to my server using a secret/password/private_key then they should pass this token to their front end and pass it with each request to my server(their front end will comunicate directly with my API)
If your public non-authenticated API is accessible by your site, there's no way to stop other people from consuming this API and stealing your data.
You can stop other websites from directly taking data from your API (by not using CORS headers), but if your website is showing data from your API publicly, then assume anyone else can.
If your business relies on not being possible, rethink your business model. If data appears on the screen of a random user, it means that user can take that data and put it somewhere else. It's how the web works.
I totally agree with #Evert. Having said that, there are some ways you can use to make public API accessible to some and not to all. It will not be perfect, and using some kind of API tokens will be a better solution most of the time, but it might suit your needs.
First of all you can use firewall rules and allow connections from certain IPs only. Simple and will work as long as the source IPs do not change.
Another idea you can use: look at youtube and how private videos work. There is a secret in the URL. With enough entropy you can build publicly accessible URLs this way which can be used to share a simple link with friends, but will be hard to guess by others. There are drawbacks to this technique. You may only allow people to share their content this way, as they have always the rights to make the link public by pasting it into their tweeter/yt/other.
I have followed the tutorial for enforcing policies on API calls
http://wso2.com/library/tutorials/2016/02/tutorial-how-to-enable-role-based-access-control-for-wso2-api-manager-using-xacml/
It wasn't easy but I got something up and running. I can change access to different endpoints of an API depending on the user's role.
I have a question. Here's a fictional setup to complete the tutorial:
API EduCollege, with endpoints /student/info and /staff/info (tutorial)
API Prison, with endpoints /prisoner/info and /staff/info (note that it's the same endpoint)
I write a policy EDUCollegePolicy that enables only those with role college_admin to access /staff/info (tutorial).
But there seems to be no way to restrict these college admins from accessing staff info of the prison!
The field resource only contains info about the endpoint.
Is there any way, using this setup, to limit by API?
Or does it maybe require a different JAR add-in, that would send a resource value set to API/version/endpoint instead of just /endpoint?
Oh, by the way: I couldn't set policies according to the endpoints provided in the tutorial. It doesn't seem that it's /staff/info, but I got it to work with regexp .*staff.*info.*. Not nice. I wonder what the actual resource sent from JAR to PDP is, I couldn't find it in any logs, including IDS logs (the IDS acts as PDP)
I have created an app and some REST API on Google Appengine and deployed it to
www.my-appspot-id.appspot.com
I'm using Google Datastore to store my data and have created API's to access that data.
However, i can access my API directly also using
www.my-appspot-id.appspot.com/_ah/api/explorer
which means anyone can access them and can manipulate the data which i don't want.
How to restrict access so that nobody but some particular registered set of users can only use it?
I stumbled upon this tutorial recently, might be of some help.
I think you need to authenticate your endpoints and authorize only some client id.
OAuth 2 authentication : https://developers.google.com/appengine/docs/python/endpoints/getstarted/backend/auth
Allowed client ids and audience : https://developers.google.com/appengine/docs/python/endpoints/create_api#allowed_client_ids_and_audiences
To answer your question : you can't.
Google Cloud Endpoints is based on the explorer api: everybody will be able to navigate into your API, and see the differents methods available.
BUT if you add an authentication to your methods, the visitor will not be able to execute them.
I have an API that provides an Account resource based on the authentication (login) that is supplied. As a user can only have one account, and can only see it's own account and not those of others, this API will basically be a single resource API in all cases.
So to keep things simple, I have this resource under the url accounts/ and when you access accounts/?username=dude&password=veryhard you'll get your account data (if you dohn't supply authentication you'll get a 403).
Now I wonder if this is RESTful. Also, you should be able to update your account info, and I wonder if PUT would be appropriate. In my knowledge, PUT should be done on a unique URI for the resource. Well, is this a unique URI for the resource? Generally a URI for an account would look like accounts/3515/ where 3515 is the account id. However, users don't know their account id. Also, there should be more ways to log in, instead of a username + password you should also be able to use a token (like accounts/?token=d3r90jfhda139hg). So then we got 2 URL's that point to the same resource, which also isn't really beautiful for a RESTful URI, is it?
So, what would be the most RESTful solution? Or should I not do this RESTful?
REST purists will consider that use of /accounts/ to obtain a single account is bad practice as it should specify a collection. Instead consider a key which cannot be mistaken for an ID, for example if your IDs are UUIDs then use a token such as 'me' so your URL is /accounts/me. This has the advantage that if later on you wish to obtain different account information, say for example you need to list users or you have an administration system using the same API, then you can expand it easily.
Putting username and password in the URL is also not pure REST. The query parameters should be directly related to the resource you are obtaining; commonly filtering and limiting the resources returned. Instead you should seriously consider using something like HTTP Basic authentication over an encrypted (HTTPS) connection so that you separate out your authentication/authorisation and resource systems. If you prefer to use a token system then take a look at oauth or hawk.
Finally, yes if you use PUT you should supply a full resource identifier. Given that it is very common for systems to read data before updating it the lack of ID won't be a problem as that will come back as part of the prior GET.
Yes accounts/?username=dude&password=veryhard is a correct REST URL.
PUT is used with an id if it used to update a resource, if you use it to create you must supply an ID. otherwise you use post to create a resource without id
I'm running a static website completely from an Amazon S3 bucket, but I want to password protect my content. Is this possible? The type of authentication doesn't bother me, it just needs to be there, so that people can't just 'discover' my website.
At the moment, I don't have a domain name set up, which I believe rules out http://www.s3auth.com/ as a possible solution. Are there any others?
AWS doesn't provide a way to do this directly right now. The S3auth solution you mentioned is nice in that your bucket/objects remain private so that a direct access to the bucket does not allow objects to be read without your private credentials. The disadvantage of the s3auth approach is that it relies on you trusting s3auth with your private credentials. If your credentials are compromised at any stage, it could be costly depending on how someone might abuse your access rights.
If you make your objects publicly readable (as you do when you create a website), anyone who learns/guesses/knows your objects names etc can access them. Or indeed if the bucket is readable, then all they need is the bucket name. There is no real way around this except by tightening the S3 access permissions.
If you only access your website from certain IP addresses, perhaps looking at Bucket Policies may help. Scroll down to Restricting Access to Specific IP Addresses. This is not a password but it does allow you to restrict where accesses can come from at least.
Another common technique for providing temporary access to objects is Query String Request Authentication. This does not however match your original requirement of password protecting your S3 bucket website.
This is possible using CloudFront and Lambda#Edge. See the answer here: https://stackoverflow.com/a/45971193/4550880
I think the AWS SDK for Javascript is what you're looking for. To be fair, it wasn't available when you posted this question 2 years ago. It allows you to login with Facebook, Google or Amazon. Here's another resource using AWS login.