I need to upload files on AWS S3 via a mobile app. I found 2 solutions to deal with it.
Both solutions work, but I am not competent enough to determine what is the most secure one.
Using temporary credentials provided by Secure Token Service (STS) Amazon Web Services.
My server asks for temporary credentials (with restricted rights) to STS using the AWS account access_key_id & secret_access_key
My server then send the temporary credentials (access_key_id, secret_access_key & session_token) to the mobile app
The mobile app send the file on S3 using the temporary credentials with a specific request signature (computed on the mobile side)
Using permanent credentials (AWS account access_key_id & secret_access_key)
My server directly create a request signature (using the AWS account access_key_id & secret_access_key) and send the request "elements/structure" (included the generated signature, the needed headers,...) to the mobile app
The mobile app send the file on S3 using the "elements" with the signature provided by the server
The second solution is simpler. But that solution seems to be less secure:
the account access_key_id is exposed and the signature directly generated with the account secret_access_key.
The digest algorithm used to generate the signature is HMAC-SHA1. Is it secure enough ?
The second solution expose temporary credentials with expiration: it is much more secure to expose limited credentials. If the HMAC-SHA1 algorithm is secure enough to make the secret_access_key impossible to retrieve, I do not see why I would chose this solution.
Thank you for your inputs
Your temporary solution is essentially a Token Vending Machine. This is our recommended method for getting credentials onto the device for use with our AWS Mobile SDKs. The inherent benefit of shipping temporary credentials is that they could be used to access other services besides S3.
Related
I need to secure my s3 bucket objects. In my web application I'm using aws-sdk to upload media to s3 bucket and get an http link back to access that object. This http link is public by default and I want to make it secure so that only authorized users can access the media. aws s3 allows to make the object private but it wont let anyone with the link access the object.
This link will be accessed from a mobile app where I dont want to use aws-sdk, Instead I want to execute some logic on aws side whenever someone tries to access the http link for the object.
What I would like to happen is, before the user gets access to s3 object, Some authorizer code would execute (like a jwt token authorizer) and depending on it user would be granted/denied access.
I'm currently looking into Amazon API Gateways, I believe they can be accessed as an http link and AWS Lambda could be used to secure them(where i would execute my jwt authorizer). Then these apis would have access to s3 internally.
If someone could point me in the right direction, If this is at all possible.
If I could use the same jwt token issued from my web-application to send along the request to Amazon API Gateway, that would be great.
I would make the bucket private, and place a CloudFront distribution in front of it. Using an Origin access identity to allow only CloudFront to directly access the S3 bucket.
Then to provide security I would use either CloudFront signed cookies, or Lambda#Edge with a custom JWT token validation.
The easiest solution to expose private objects in an S3 bucket is to create a pre-signed URL. Pre-signed URLs use the permissions from the service (which pre-signs the URL) to determine access and have only a limited duration in which they can be used. They can also be used to upload an object directly to S3 instead of having to proxy the upload through a lambda function.
For a download functionality and a smooth user experience, you can - for example - have a lambda function that generates a pre-signed URL and returns it as an HTTP 302 response, which should instruct the browser to automatically download the file from the new URL.
(Edit)
Following on what I've stated in the comments on this answer, if you're proxying the upload/download of the objects through services such as API Gateway or Lambda, you will be severely limited in the size of files that you are able to upload to S3. The payload size limit on an API Gateway is 10 MB and for requests to lambda your payload is capped at 6MB for synchronous invocations. If you want to upload something larger than 10 MB, you will need to use direct upload to S3 for which pre-signed URLs are the safest solution.
I know I am bit late here, but I wanted to give my opinion in case someone has the same problems.
Your mobile app should communicate with a server app (backend app) for authentication and authorization. let's say you are deploying your server app on AWS VPC. Now, it's simple to manage the files access by creating a policy which allow just your server app (IP, or VPC) to access the bucket. the authorization part will be managed on your application.
I have a use case where I need arbitrary clients to receive AWS credentials (key and secret) that I generate and pass to it. The credentials should expire after a few minutes. The clients need to post to an s3 bucket.
The clients will not be a part of any AWS account and cannot use any multi factor auth. This seems to prevent me from using IAM roles.
It seems that the Security Token Service is what Amazon provides for similar use cases, but I can't massage it to get what I need out of it. I either need a role ARN, or to pass the session token on to the clients to use in their requests. The clients can have no concept of a session token- only AWS key/secret.
In short, I want to be able to generate a temporary AWS key/secret pair that needs no multifactor auth or session token.
Is this possible? Thanks!
This is exactly the use-case for Uploading Objects Using Pre-Signed URLs - Amazon Simple Storage Service.
Basically:
Your application determines whether the user is authorized to upload/download a file
It generates a Pre-signed URL that includes an expiration time
The clients use the URL to upload/download to S3
After the expiry time, the URL no longer works
I am creating a backend service which will be getting requests from an Android application regarding creating of some service requests. These service requests will contain details about the the service items and also some images related to the request. We want to use S3 for storing the images directly from the android application and getting the key of the image saved through an API call on the backend service.
The problem with this approach is the authorization of the mobile application to access the shared bucket.
If we save the access key of the shared bucket in the application, this code can be decompiled and the secret will be compromised.
Another option is to create an API on the backend service which will give back the authorization key to the mobile application before it needs to put the image to S3. In this way we can also rotate the secrets periodically.
Which of these approach is better in terms of security? Is there any other approach which I am missing? It sounds like a standard access practice of using S3 for saving files, so there must be something for this particular scenario.
You don't need to invent an API to do this - AWS provides its STS service for just this use case.
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html
To request temporary security credentials, you can use the AWS STS API actions.
To call the APIs, you can use one of the AWS SDKs, which are available
for a variety of programming languages and environments, including
Java, .NET, Python, Ruby, Android, and iOS. The SDKs take care of
tasks such as cryptographically signing your requests, retrying
requests if necessary, and handling error responses. You can also use
the AWS STS Query API, which is described in the AWS Security Token
Service API Reference. Finally, two command line tools support the AWS
STS commands: the AWS Command Line Interface, and the AWS Tools for
Windows PowerShell.
The AWS STS API actions return temporary security credentials that
consist of an access key and a session token. The access key consists
of an access key ID and a secret key. Users (or an application that
the user runs) can use these credentials to access your resources.
When the credentials are created, they are associated with an IAM
access control policy that limits what the user can do when using the
credentials. For more information, see Using Temporary Security
Credentials to Request Access to AWS Resources.
So since parse is shutting down we are moving our website / mobile app that we've been developing to AWS. We are primarily going to use the following services:
SNS, SES, Dynamo, S3, Lambda.
Now I am still a bit confused on:
what cognito is used for? Do we really need cognito to authenticate users and use DynamoDB, S3, SNS ? Or can we just use specific APIs for each of these services and connect directly (using Js SDK)?
If we do have to use cognito how do we save local data i.e logged in user/ identity? is that what cognito sync is for or do we have to use cookies ?
In summary why do I need cognito when I can directly connect to DynamoDB using the JavaScript SDK?!
Thank you in Advance.
Amazon Cognito can be decomposed in two sub-services: Amazon Cognito Identity and Amazon Cognito Sync.
Think of the former as an authentication service and a credentials provider. The latter is just a service to store user data and keep it synchronized between multiple devices.
What is the purpose of Amazon Cognito Identity?
Suppose that you have a table in DynamoDB. Let's say that you have a web application that will store an item on that table.
You can create an user in IAM, embed the credential information on the web application, and then put the item on the table using the AWS SDK.
There are three things going on here:
The credentials are embedded in the application
The credentials do not expire.
Every user in your application has the same access rights on your table
This may be fine for some applications, but Amazon Cognito Identity offers a solution to these common problems.
Let me explain Cognito Identity's workflow:
An user registers an account on your application, sending all the information (username, password, other data...) to your server.
The server stores the user in some back-end database (it could be a DynamoDB table) and creates a new identity on the Cognito service. This identity is then mapped to this user.
The user can now login into your application. The user logins and sends username and password to your server. (This process could be done automatically after account registration)
The server checks the username and password against your back-end database. If everything is right, then the server makes a request to Amazon Cognito for a temporary access token.
The web application receives the token and makes a request to Amazon Cognito (using that access token) to get the user credentials. These credentials are basically a temporary IAM user that was created specifically for this user. It will have an expiration (usually an hour).
The web application uses these credentials to make operations on AWS, such as putting an item on a DynamoDB table, or calling a Lambda.
When the credentials expire, the user must re-login into the application. This might be done automatically or not, depending on your application's requirements.
On the Amazon Cognito dashboard, you can configure roles and policies for your "identities" (an user in Cognito). This way you can specify which services it can access. It even allows you to create access roles for your users (Admin users may be able to access some services that normal users should not).
I should also note that Amazon Cognito can be easily adapted to support Facebook / Google+ / Amazon accounts, which will be mapped to the same identity, so the user can login via multiple sources.
What is the purpose of Amazon Cognito Sync?
Consider it like a DynamoDB table where you store information for a specific user. These information is shared between multiple devices and is always synchronized. This means that when a web application updates an user value, then the mobile application will automatically reflect this change.
There is a limit on how much user data you can store (I don't remember now), so it's not something you would use to persist information (such as an user password), but rather a mean to share information.
I have a website where I use AWS S3 JS sdk to upload/delete images from S3 server buckets.
Currently I am passing the credentials in raw format in JS file only, which is not secured. And AWS suggests to use web identity federation technique to make it secured.
I read about them, and have some query.
Does this technique means, each user of my website who is going to use it to upload image, needs to verify their logins ?
There is something called, pre-signed in URLs too. Which let us hide the credentials too.
But I am confused on what exactly to be followed to achieve my goal that is,
I do not want to show my credentials to end user in js file. ALSO I don't want my end users to authenticate themselves of any kind.
Is it possible and how?
You should indeed use some Identity Federation to let somehow authenticate your users and to get temporary access key / secret key for your user.
AWS has a service to help you to implement this : AWS Cognito (http://aws.amazon.com/cognito/)
Cognito Identity is an identity federation service that let authenticate your users on well known web identity services such as Facebook, Google, Amazon, any OpenID Connect service (SalesForce...) or your own authentication backend. Once a user is authenticated in one of these services, Cognito will trade the federation token for an AWS Access Key and Secret Key. These Access Keys will be limited in scope to whatever permission you have defined in your Cognito Role and limited in time (15 min by default)
This blog post describes how to use AWS Cognito Identity with your own backend authentication service. It provided server side sample code for Java and .Net : http://mobile.awsblog.com/post/TxBVEDL5Z8JKAC/Use-Amazon-Cognito-in-your-website-for-simple-AWS-authentication
AWS Cognito Identity also allows you to work with unauthenticated users, i.e. to receive an Access Key / Secret Key for users before they are authenticated.
AWS Cognito will maintain an unique identity ID for your users, whatever authentication method they will use (i.e. the same person authenticates once with Google, once with Facebook and will have the same identity ID)
https://identity-demo.aws-emea.info is a web site that demonstrates user authentication and identity federation. This web site implements several federation techniques : Server Side Web Identity Federation (tab #1), Client Side (JavaScript) Web Identity Federation (tab #2) and Client Side (JavaSCript) AWS Cognito Authentication (tab #3)
To answer your second question : S3 Signed URL : these are URL allowing to download / upload content from / to S3. They are typically generated by an App Server and embedded in web pages. S3 Signed URL does not required to have your user authenticated nor to have one key per user. It is your implementation choice to decide between using a user specific key or an app generic key to generate your S3 signed URL. All AWS SDK have methods to help you to generate the pre-signed URL.
Giving your requirement of not authenticating your users, you have two choices. Either use unauthenticated users w/ AWS Cognito or to use S3 pre-signed URLs. Signature must be then generated on the server side, using a servers side key (or a EC2 Role if your app server runs on Amazon EC2)