Identity and Access Management

6 Identity and Access Management

6.1 Overview

Users and applications interact with AWS by using security credentials. These are associated with every AWS account whether it is root or IAM user account. Upon creation of new AWS account a user uses his email address and password to log in and get full access to every resource AWS offer. This AWS account is known as user’s root account and it is usually a good practice not to use its credentials directly but instead to create an IAS account/s with administrator privileges. When a new IAM account is created, it is given its own login, password, sign-in URL, permissions and security credentials. These can be used to access services in applications and also from AWS management console (since it is technically just an application with web UI²⁰) [17].

By default, every newly-created IAM user doesn’t possess any permission. Therefore, it is necessary to have root account or another user with permissions to control IAM to assign him permissions before he can start using AWS. Generally, there are two ways of assigning permissions to a user – either by attaching permission to specific user or group (user-based permissions) or by attaching it to specific resource (resource-based permissions). To be able to assign permission for Amazon Web Service, a policy must be created. Policy refers to a JSON document explicitly listing permissions. It contains either one or multiple statements that usually specify what kind of actions can be/cannot be performed for a particular resource. Later, the policy can be assigned to a user or group [16, Permissions and Policies]. In each policy, both Amazon resources and users (groups …) are uniquely identified by their Amazon Resource Names (ARN). ARN is just a user-friendly name that can be used to reference any entity on AWS because of its unique format (arn:aws:service:region:account:resource), [17].

To ensure security, each individual call to Amazon Web Service uses an encrypted communication protocol. To use this protocol, each request must be signed by user’s access keys, which is a generated pair of unique keys belonging to one AWS account (it doesn’t matter whether it is a root AWS account or an IAM user account). Access keys can be generated via management console and consist of access key ID and secret access key. A user can generate as many pairs of access keys as he wants, however he can only use them to call those services his user account is entitled to use. Any attempt to use any other service results either in an unauthorized access response or in a corresponding exception [18].

6.2 IAM in Kentico AWS Manager

As mentioned before, requests to Amazon Web Services are encrypted. This applies to every form of interacting with AWS let it be AWS Management Console, Query API or SDKs. Since Kentico AWS Manager uses AWS SDK for .NET it is required for all the requests to be signed by user’s access keys. Since SDKs function as higher layer of abstraction by offering developers high-level function/method calls and by shielding them from low-level API calls, .NET SDK greatly simplifies the task of signing individual requests. Instead of adding access keys to the header of every single API call, these are only required to specify when a new service client is created. AWS SDK for .NET provide factory methods to create clients for every Amazon service, which serve to encapsulate usage of service’s corresponding actions. Therefore, each time a new client needs to be created it suffices to pass user’s access key ID and secret access key to factory method. More preferable approach however is to store access key ID and secret access key for each application in its Web.config file (for web applications) or App.config file (for other applications). SDK’s overloaded factory methods automatically locate both keys, which greatly improves code’s maintainability since this way when access key change, I no longer need to modify various parts of my code. Additionally, this approach allows me to modify access keys while application is running.

Since the application is meant to serve many users using different AWS accounts it would be highly impractical to have every user modify configuration files before they can start using it. For this very reason on the first launch KAM prompts its user to specify both access keys. These are verified and stored to the configuration file by the application itself and are used for any consecutive API call. Also, the next time KAM is launched it offers a choice to the user to either utilize previously stored credentials or to enter new ones. After credentials are confirmed the application asks the user to choose his default region. As mentioned, AWS regions function as independent environments encapsulating services and resources both logically and geographically. Once a region is specified, it is stored in application’s configuration file and just as access keys it is remembered for any consecutive run. Additionally, the region can be changed from main window of the application.

One issue I encountered while working with IAM API was the inability to verify permissions for every IAM account. Since permissions for every account may vary, there is no insurance that provided credentials can access IAM to determine whether these credentials are sufficient for calling Amazon services upon which KAM relies. Moreover, if the user is unauthorized to make certain API call, SDK throws an exception. Since KAM is a wizard-like application we cannot wait for the application to fail in order to determine whether current credentials are enough. And even if permissions to access IAM API are in place it can be tedious and time-consuming to verify if the credentials satisfy all the conditions since an IAM user can also belong to IAM groups. That is why it would be necessary to obtain every single policy a user account is associated with, parse every policy’s JSON document and at the end aggregate results to unambiguously determine whether all conditions were met. Because of this complexity my current implementation only allows root credentials to be used with KAM as each root account can access any resource or service. I believe that this verification is a feature that should be implemented on server side rather than on client side. Each user account should be allowed to query Amazon server to learn which resources and services it can access. Result of this query could be a JSON document containing an aggregated list of all the available actions and resources no matter where the permissions originated from.

Download 150.94 Kb.

Share with your friends: