Upgrading some legacy code using the old SDK, I would access dynamoDB using an AWS_KEY and Secret_KEY packaged in credentials that were then given to an AWSDynamoDbClient object. In version 2.0 of the SDK this client object is no longer available in AWSDynamoDB.h. All the documentation now points to Cognito for authentication so is the old way of access deprecated and the Keys not used anymore?
When you use Amazon Cognito, the service takes care of all the steps necessary to create a unique identifier for your app’s users and retrieve temporary, limited privilege AWS credentials. This means that you can follow security best practices, and use these temporary, limited privilege credentials instead of having to hardcode credentials into your app.
You can still use AccessKey and SecretKey with AWSStaticCredentialsProvider, but we discourage its use in production apps for security concerns.
Related
I am currently working on a few services that uses keyvault, authenticating with ClientCertificateCredential / Registered Apps. These are running on-premise.
Looking into using Azure App Configuration in a similar way, combined with keyvault. So a couple of questions arises:
Can i authorize against App Configuration the same way as with KeyVault, using ClientCertificateCredential ? If yes, how ?
If not, another option is to use a connection string against App Config. However, this is a secret, and should be stored in keyvault (absolutely not in appsettings.json). That means I have to access keyvault before setting up App Config. Is there a clean way to do this ?
Or, perhaps there is something else I should consider.
• Yes, you can surely authorize against App configuration as you do against key vault to retrieve client secrets, connection strings and other sensitive information with the help of managed identities. Managed identities create a service principal for the said application when enabled depending on the user to be assigned to that application or directly to the application itself as a system assigned managed identity that is created for the lifetime of that application.
By leveraging managed identity, it eliminates the need for an access token that contains secrets. Your code can access the App Configuration store using only the service endpoint. You can embed this URL in your code directly without exposing any secret.
• For more information on configuring managed identity to access the application configuration without exposing or leveraging any type of access token, please refer to the documentation link below for more details: -
https://learn.microsoft.com/en-us/azure/azure-app-configuration/howto-integrate-azure-managed-service-identity?tabs=core5x
I'm using Parse as my backend but I'm also using the AWS s3 service so I need to also use Amazon Cognito. So far Amazon Cognito integrates with 3rd party identity providers such as Facebook, Google, and Twitter but not Parse. So I'm guessing I would use the Basic flow which
"Uses Cognito + STS and requires identity pool plus IAM roles"
https://docs.aws.amazon.com/AWSiOSSDK/latest/Classes/AWSCognitoCredentialsProvider.html#//api/name/getIdentityId
since I'm using Parse as my backend I won't be able to use the Developer authenticated identities method. But I'm not entirely sure.
But my only issue is how I could get session tokens for temporary AWS Service access for users? Most of the tutorials/blogs I find online explain how to access the tokens on the server side but not on ios unless I'm missing a crucial concept here
If you're authenticating users with Parse, you should be able to use Developer Authenticated Identities, having the user send login credentials to your backend which would then validate those with Parse.
The mobile SDKs can get credentials to access AWS resources. These are vended for users based on their state, which is where the roles you mentioned come in. If you log in (with Parse, for example), your credentials would allow you to access what the auth role dictates, but if you don't, they'd be scoped to what the unauth role dictates. The developer guide has more information on getting credentials.
As far as your backend, have you looked into Cognito Sync? If you have and opted to go with Parse instead, was there a particular feature it was lacking that caused you to not use it?
I am currently trying to use amazon s3 for uploading images from IOS app with a Rails Back-end.
I currently don't understand how security works. In their docs
http://docs.aws.amazon.com/mobile/sdkforios/developerguide/s3transfermanager.html
it's not clear to me how to upload/destroy safely objects in sync with the back-end. For instance, in order to post/destroy, I was expecting a mechanism of asking a signature to the Rails server, and only then be able to upload the image to amazon. But I can't find this kind of mechanism.
Has someone gone through this kind with aws?
If you are using your server to generate temporary credentials for the AWS Mobile SDK, we recommend the following approach:
Generate the access key, secret key, and session token on your server. You have many language options including Java, .NET, PHP, Ruby, Python, and Node.js.
Implement your credentials provider by conforming to AWSCredentialsProvider. Take a look at the implementations of AWSWebIdentityCredentialsProvider and AWSCognitoCredentialsProvider as examples. This credentials provider should:
Retrieve the access key, secret key, and session key from your server.
Persist them locally until they expire.
Return the credentials when requested.
Re-retrieve them from your server if they are expired.
Initiate the credentials refreshing process when - refresh is called.
I encourage you to take a look at Amazon Cognito Identity. With Amazon Cognito, you can create unique end user identifiers for accessing AWS cloud services by using public login providers such as Amazon, Facebook, Google, and any OpenID Connect compatible provider, or by using your own user identity system. It covers many of the custom server use cases, and it is easier to use and manage.
I've followed the instructions in this post http://mobile.awsblog.com/post/Tx371Y7CA0QJ95X/Simplifying-Token-Vending-Machine-Deployment-with-AWS-CloudFormation
And I can see that it's working somewhat, and i understand the overall concept of what TVM is and why it's needed, however I still have hard time understanding how this works in practicality. I read a post somewhere that anonymous token vending machine is designed for read-only and if I wanted to actually provide write access I need to use identity TVM.
In the demo app it makes me register my account on the cloudformation server i set up, but I don't understand how this works with say my own web app. I have a mobile app that connects to rails app where I need users to upload their profile images as well as post photo content. I already have the app running except for the integration part with the TVM (basically my aws credentials are embedded in the app which Amazon doesn't recommend)
So my question is how do i integrate an existing REST based iOS app with identity token vending machine to upload photos to S3? How can i integrate it without making users separately create an "account" for the identity token vending machine on top of registering for my app?
We recently launched Amazon Cognito, which obviates the need for the TVM in many cases, particularly in the "anonymous TVM" case. Through Cognito's unauthenticated access you can grant users of your application limited access privileges to various AWS resources. Cognito leverages existing functionality of IAM Roles and STS to deliver these credentials.
If you want to maintain the integration with your existing backend authentication solution, you will need to generate and maintain the list of identity ids for your application. You can read more about the APIs involved in our API documentation.
Your app can act as the TVM, mapping your user identities to the IAM Roles with the permissions they need. Then can use the AssumeRole calls on STS to create temporary credentials for these users. Your app then creates a S3Client object with these credentials and use it to upload the photo.
See the "Identity federation" and "Web identity federation" sections of the of IAM Roles documentation
The AWS Web Identity Federation Playground is a nice example app to see it at work.
CoudFormation will automate the creation, updates and deletion of AWS Resources, including EC2 Instances and IAM Roles, but will not be directly related to the user authentication.
I am using amazon S3 to provide IAP content.
Is there a "Safe" way to store the secretAccessKey inside my app so hackers can't use it to get the files?
The best way to do this is not to give out normal secret access keys at all.
First create an IAM user that has access to only what is needed, so that even if someone does get their hands on the credentials they can only access what you want them too (e.g. get files from a specific S3 bucket, but not modify them)
When the iOS app needs to access the S3 files it connects to a web server you control. That web server users STS to generate a set of credentials that will expire after the desired amount of time. These look like normal aws credentials (access key, secret, session id) but will eventually expire.
Amazon provide some reference implementations of these token vending machines and has an article discussing the setup in more detail.
Did you look for appropriate method using Keychain framework? Keychain Services Tasks for iOS