IAM Core Concepts: Access Control Explained

IAM is fundamentally about managing who can do what on which resources, and it’s far more nuanced than just assigning users to groups.

Let’s see it in action. Imagine you have a web application and you want to allow users to upload files to a cloud storage bucket.

Here’s a simplified, conceptual flow:

1. User Authentication: A user logs into your application. This is typically handled by an Identity Provider (IdP) like Auth0, Okta, or even a custom solution. The IdP issues a token (e.g., JWT) confirming the user’s identity.
2. Authorization Check: When the user tries to upload a file, your application needs to check if this authenticated user has permission to write to the specific storage bucket. This is where IAM policies come in.
3. Policy Evaluation: The IAM system evaluates policies associated with the user (or the application acting on their behalf) and the target resource (the storage bucket). If the policies grant the s3:PutObject action for that bucket, access is allowed.

The core problem IAM solves is the secure and scalable management of access control in complex systems. Without it, you’d have a tangled mess of individual permissions, making it impossible to audit, revoke, or manage access effectively as your system grows.

Internally, IAM systems often rely on a combination of:

• Principals: These are the "who" – users, services, applications, or even anonymous entities.
• Resources: These are the "which" – databases, files, APIs, virtual machines, or specific data within them.
• Actions: These are the "what" – read, write, delete, execute, list, etc.
• Policies: These are the rules that define the relationship between principals, resources, and actions. Policies are often expressed in JSON and can be attached to principals (identity-based policies) or resources (resource-based policies).

Consider an AWS IAM policy. It’s a JSON document.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-example-bucket/*"
    }
  ]
}

This policy, when attached to a user or role, allows them to PutObject (upload) to any object within the my-example-bucket. The Resource field uses an Amazon Resource Name (ARN) to precisely identify the target.

The levers you control are the granularity of your policies. You can grant broad access, like the example above, or restrict it to specific actions, specific resources, or even specific conditions (e.g., only allow access from a certain IP address, or only if the request is encrypted).

Most people understand that policies grant permissions, but they often overlook the implicit deny. Unless a policy explicitly grants an action on a resource to a principal, that access is denied by default. This "least privilege" principle is fundamental to IAM’s security model. A common mistake is to create overly broad "allow" policies without considering all the ways they might be interpreted, leading to unintended access.

The next concept you’ll grapple with is the distinction between authentication and authorization, and how they work together.