Using IAM for user authentication

Question

I've read lots and lots of posts that touch on what I think should be a very common use case - but without finding exactly what I want, or a simple reason why it can't be done.

I have some files on S3. I want to be able to grant certain users access to certain files, via a front end that I build.

So far, I've made it work this way:

• I built the front end in Django, using it's built-in Users and Groups
• I have a model for Buckets, in which I mirror my S3 buckets.
• I have a m2m relationship from groups to buckets representing the S3 permissions.
• The user logs in and authenticates against Django's users.
• I grab from Django the list of buckets that the user is allowed to see
• I use boto to grab a list of links to files from those buckets and display to user.

This works, but isn't ideal, and also just doesn't feel right. I've got to keep a mirror of the buckets, and I also have to maintain my own list of user/passwords and permissions, when AWS already has all that built in.

What I really want is to simply create the users in IAM and use group permissions in IAM to control access to the S3 buckets. No duplication of data or function. My app would request a UN/PW from the user and use that to connect to IAM/S3 to pull the list of buckets and files, then display links to the user. Simple.

How can I, or why can't I?

Am I looking at this the wrong way?

What's the "right" way to address this (I assume) very common use case?

Answer 1

Your line of thoughts is correct, let's take a look at alternatives:

1. Your app store the api keys and secrets of all the users and delegate everything to AWS IAM permissions system. While being architecturally simpler solution, the details can kill it. Your app should be really secured, and host the secret api keys in a very secured way. This actually depends on the use-cases:

   • If all the work happens with an interactive user - then your system can store an encrypted key with the user's password decrypting it as part of the login process. This means that if your DB get compromised - there is no enough info there to compromise the keys.
   • If the system needs to do background non-interactive stuff then there is a need to develop complex procedures in order to securely store this info. Companies like Rightscale and Dome9 have developed these kind of processes. This option is not recommended unless you have security specialists on your team.

2. Your app connects to AWS with a single 'strong' api key - but queries AWS API if the specific user is allowed for that action on that resource. Sadly, I'm not familiar with similar AWS api - so maybe some of the other reader would like to comment on that. This(if possible) will be the most simple and secured solution.

3. Grow your exiting solution to use the data stored at AWS : users, groups, user->groups assignment and use the user/group policies as the data source for your permissions checks. This way, you'll have some logic duplication with AWS (which is fine) but will not have data duplication which is the real pain.