IAM_system_design.md

Identity and Access Management Our customers trust us with some of their most sensitive data, but with thousands of systems and employees around the globe, we've never been systematic about access control. We want to give employees exactly the right set of privileges they need to do their work.

Welcome! You have been appointed the technical lead of a project to build an identity and access management (IAM) system. At a high level, the components are:

• A way of storing access policies (who can do what); • An API to query these access policies; and • An APl to manage these access policies.

Examples of requests that the system should serve

• Example 1: Should [jdoe] be allowed to [list all customers] in our [customer list]? • Example 2: Should users in the group [engineers] be allowed to [delete administrators] in the [payroll service]?

Your task Design a globally distributed system that stores access policies and answers authorization queries like "should user U be allowed to do action A on service X?"

Deliverables: A system architecture, a set of APis, and a storage schema.

Requirements: Your system should have the following properties:

• Authorization checks are easy to integrate into existing services, even those that are not web applications. (I.e., a solution that depends on HTTP cookies is not suitable.) • The system facilitates auditing: who did what, when? • It is easy to create new policies or change existing ones. • The system should be resilient in the face of outages - no single point of failure.

Assume that authentication is already addressed: every user and service presents a trustworthy certificate of its identity and all connections are appropriately encrypted.

System Architecture

1. Policy Storage Service: A globally distributed database to store the policies. This could be a NoSQL database like DynamoDB or Cassandra which supports multi-region replication.

2. Authorization Service: A service that interacts with the Policy Storage Service to fetch policies and evaluate them. This service should be stateless and horizontally scalable to handle large volumes of requests.

3. Audit Service: A service that logs all the authorization checks for auditing purposes. This could be a simple logging service that writes to a distributed log storage system like Kafka.

4. Policy Management Service: A service that provides APIs to create, update, and delete policies in the Policy Storage Service.

APIs

1. Check Authorization API: Takes a user, action, and service as input and returns whether the user is authorized to perform the action on the service.

2. Create Policy API: Takes a policy as input and creates a new policy.

3. Update Policy API: Takes a policy as input and updates the existing policy.

4. Delete Policy API: Takes a policy ID as input and deletes the policy.

Storage Schema

The policies could be stored in a simple key-value format where the key is a combination of the user, action, and service, and the value is whether the action is allowed or not.

{
  "user": "jdoe",
  "action": "list",
  "service": "customer list",
  "allowed": true
}

Integration

Services can integrate with the Authorization Service by making a simple API call to check if a user is authorized to perform an action. This makes it easy to integrate with any type of service, not just web applications.

Auditing

Every authorization check is logged by the Audit Service, including the user, action, service, whether the action was allowed, and the timestamp. This makes it easy to audit who did what and when.

Resilience

The system is designed to be resilient with no single point of failure. The Policy Storage Service is a globally distributed database that can handle regional outages. The Authorization Service and Audit Service are stateless and can be horizontally scaled to handle failures. The Policy Management Service interacts with the Policy Storage Service, which is resilient.

The IAM system can handle policy updates and changes through the Policy Management Service. Here's how it works:

1. Create Policy API: When a new policy needs to be created, the Create Policy API is called with the new policy details. The Policy Management Service then writes this new policy to the Policy Storage.

{
  "user": "jdoe",
  "action": "create",
  "service": "customer list",
  "allowed": true
}

2. Update Policy API: When an existing policy needs to be updated, the Update Policy API is called with the updated policy details. The Policy Management Service then updates the existing policy in the Policy Storage.

{
  "policyId": "123",
  "user": "jdoe",
  "action": "create",
  "service": "customer list",
  "allowed": false
}

3. Delete Policy API: When a policy needs to be deleted, the Delete Policy API is called with the policy ID. The Policy Management Service then deletes the policy from the Policy Storage.

{
  "policyId": "123"
}

These APIs ensure that the IAM system can easily handle policy updates and changes. The changes are immediately reflected in the Policy Storage and are taken into account by the Authorization Service when it checks for authorizations.

System Design Architecture