Design and Implementation of OpenIAM: A Cloud Identity and Access Management Service Inspired by AWS IAM

As part of Lianjia's infrastructure team, the authors observed a strong early need for resource isolation and a later need for permission management between business services and foundational services, prompting the search for a generic, low‑cost identity and access management solution.

AWS Identity and Access Management (IAM) provides a mature SaaS solution that separates accounts, users, groups, and roles, supports credential types (username/password and AccessKeyId/SecretAccessKey), and uses stateless request signing for secure authentication.

IAM policies are expressed as JSON documents, allowing programmers to write and combine permissions using arrays, maps, and condition statements; policies can be attached inline or as managed policies to accounts, users, groups, or roles.

To avoid reinventing the wheel, the team examined OpenStack Keystone but found its role‑centric design too heavyweight, so they built OpenIAM from scratch in Go, delivering a service compatible with the AWS CLI and a Vue.js admin console.

OpenIAM exposes JSON/XML HTTP APIs for everyday management and high‑performance gRPC APIs for service integration. Service providers only pass AccessKeyId, signature method, resource, and action to OpenIAM, which handles authentication and authorization without exposing secret keys or policy details.

1. 基于Session，Session过期后重新登录。 2. 对每次请求加密，一次一密。

The following example shows an AWS‑style IAM policy in JSON format:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:ListAllMyBuckets", "s3:GetBucketLocation"], "Resource": "arn:aws:s3:::*" }, { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::BUCKET-NAME", "Condition": {"StringLike": {"s3:prefix": ["", "home/", "home/${aws:username}/"]}} }, { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::BUCKET-NAME/home/${aws:username}", "arn:aws:s3:::BUCKET-NAME/home/${aws:username}/*" ] } ] }

OpenIAM’s architecture enables service providers to declare only the account that creates resources; all subsequent authorization is handled transparently by OpenIAM, allowing resource owners to manage permissions directly.

Typical usage scenarios include mapping RESTful API entities to resources and actions, and handling cases where business systems either use a single set of AK/SK for third‑party services or map application‑level users to distinct IAM sub‑users for fine‑grained access control.

In summary, OpenIAM aims to simplify authentication and authorization across an expanding microservice landscape, providing a unified, low‑cost IAM layer that reduces integration effort and improves security consistency.