After discovering how easy it was to integrate the API Key, I thought this would not be complicated. However, that was not the case and I had to jump over a couple of hurdles. Ultimately, I found 99% of my answers in the Amazon documentation. They really keep their documentation site(s) up to date from what I can see 🙂
The high-level process is as follows:
- Select ‘AWS_IAM’ from the Authorization drop down
- Deploy (or redeploy) the API
- Once this is set up and deployed (funny how often I forget this step :)), the API Key only option no longer works (as expected)
- Create a policy (see reference #1)
- Mine looks like this
- Mine looks like this
NOTE: Version failed when updated to today’s data which is what I originally put in. It has to be “Version”: “2012-10-17” (see reference #7)
- Create user
- Apply Policy to user
NOTE: There is a ‘Simulate Policy’ option that I found useful. By clicking here, you can simulate this policy against any of the existing resources (as far as I could see) from this test.
- Make your call
- Set up the headers – This is a little complicated, but this is also one of the reasons I love Postman. I am not sure when it was added, but there is a AWS option under Authorization. I added my ‘stuff’ to it and it started working. I took the header values created by Postman and replicated it in another REST client called Advanced Rest Client (see reference #8) that works pretty well.
- Post Man Results
- Advanced Rest Client
- Part of this was rethinking how I viewed authorization. In the past, if my user was authenticated, I would then allow them access to whatever they were allowed access too. This was determined by what roles and/or groups w/roles the user was part of. Creating a ‘policy’ and applying it directly to the user is an little unorthodox to me…or at least, it was not how I had been taught to do authorization. Especially since IAM has groups and roles. Historically, roles have responsibilities that are applied to groups. If you want a user to have access to them, you add them to that group. Just something different 🙂
- Figuring out the headers with Postman’s AWS option is still black box to me and I will need to figure this out for the next step in this blog series. I am assuming it is something similar to how Azure calculates some of its access signatures (see reference # 9).
Next on the Amazon Lambda blog series will be an application that implements basic Create Read Update Delete (CRUD) operations for the satellite table. I am also thinking about moving the TGIMBA site to use the Amazon Dynamo DB back end with an API managed by the gateway. Overall, the Amazon cloud seems very resilient and dependable.