Skip to content

Commit ae9959e

Browse files
committed
Update README to document the new user administration module
1 parent 1f4b7f4 commit ae9959e

File tree

3 files changed

+193
-54
lines changed

3 files changed

+193
-54
lines changed

README.md

Lines changed: 117 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -1,38 +1,51 @@
1-
A generic service featuring RBAC (Role Based Access Control).
1+
# User Roles
22

3-
## Documentation
3+
The User Roles Service is a core data service responsible for storing user roles for RBAC (
4+
Role-Based Access Control), and integrating with AWS Cognito to provide a user administration API.
45

5-
<!-- Optional links to other pages -->
6-
More information is found here:
6+
* [Documentation](#documentation)
7+
* [Architecture](#architecture)
8+
* [Endpoints](#endpoints)
9+
* [Roles API](#roles-api)
10+
* [Administration API](#administration-api)
11+
* [Deploying User Roles service in your project](#deploying-user-roles-service-in-your-project)
12+
* [Running locally](#running-locally)
13+
* [Linting](#linting)
714

8-
<!-- Add links that suits your project. These are just exammples: -->
15+
## Documentation
916

10-
- [Main confluence page](https://liflig.atlassian.net/wiki/x/AQC3)
17+
- [Main confluence page](https://liflig.atlassian.net/wiki/x/AQC3) (Liflig-internal)
1118

12-
# Example architecture
19+
## Architecture
1320

14-
Can be used in conjunction with e.g. AWS Cognito and
15-
a [pretoken generation trigger lambda](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html)
16-
to add custom claims to an identity token.
21+
The User Roles service has 2 modules:
1722

18-
_Note that this repo only contains the User Roles service_
19-
![img.png](architecture.png)
23+
- The `roles` module provides simple CRUD on user roles
24+
- The `administration` module integrates with Cognito (the identity provider service from AWS), to
25+
allow clients to do CRUD on users and their associated roles
2026

21-
# Endpoints
27+
When verifying a user's JWT, only the roles module is used. An important design principle here is
28+
that authentication should not be blocked when there are problems in the administration module.
29+
Therefore, the User Roles service has been designed to make the roles module independent from the
30+
administration module. For example, if the administration module is misconfigured, then the service
31+
will still start, and only the administration API will respond with 500 Internal Server Error.
2232

23-
## CRUD endpoints
33+
![Architecture diagram](architecture.svg)
2434

25-
| Endpoint | What |
26-
|------------------------------|:------------------------------------:|
27-
| PUT /userroles/{username} | create or update user roles for user |
28-
| GET /userroles/{username} | get user roles for user |
29-
| DELETE /userroles/{username} | |
35+
## Endpoints
3036

31-
**NB!** Currently no support for post, but can be implemented later.
37+
### Roles API
3238

33-
## Data structure for PUT and GET
39+
| Endpoint | What |
40+
|-------------------------------------------------------|:-------------------------------:|
41+
| GET /api/userroles/{username} | Get roles for user |
42+
| PUT /api/userroles/{username} | Create or update roles for user |
43+
| DELETE /api/userroles/{username} | Delete roles for user |
44+
| GET /api/userroles?roleName={roleName}&orgId={orgId2} | List/query user roles |
3445

35-
```
46+
#### Data structure of user role
47+
48+
```json
3649
{
3750
"username": "user123",
3851
"roles": [
@@ -50,7 +63,7 @@ _Note that this repo only contains the User Roles service_
5063
"applicationName": "application2",
5164
"orgId": "orgId3",
5265
"roleName": "orgMember",
53-
"roleValue": "{"boards": [1,2,3]}"
66+
"roleValue": "<value>"
5467
},
5568
{
5669
"roleName": "admin"
@@ -59,45 +72,95 @@ _Note that this repo only contains the User Roles service_
5972
}
6073
```
6174

62-
## Query endpoints
63-
64-
| Endpoint | What |
65-
|---------------------------------------------------|:----------------------------------------------:|
66-
| GET /userroles | List all users |
67-
| GET /userroles?orgId={orgId1} | List users with access to a given organization |
68-
| GET /userroles?roleName=admin | List users with a given role |
69-
| GET /userroles?roleName={roleName}&orgId={orgId2} | List users with a given role |
70-
71-
## Running locally
72-
73-
1. Start the database
74-
75-
```bash
76-
docker-compose up -d
77-
```
75+
### Administration API
7876

79-
1. Build and run the application
77+
When referring to “our identity provider” below, we mean AWS Cognito. But User Roles may be expanded
78+
in the future to support other identity providers.
8079

81-
All of these will skip tests to be quick.
80+
The user administration API does not take responsibility for verifying that a requesting user is
81+
authorized to assign the given roles. That is the responsibility of the BFF (Backend-For-Frontend)
82+
service in your project. This is because the User Roles service does not know the content or
83+
hierarchy of roles in your project, so only a project-specific service has the knowledge to perform
84+
authorization.
8285

83-
1. Option 1: In IDE
86+
| Endpoint | What | Cognito API used |
87+
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|
88+
| GET /api/administration/users/{username} | Get user data from our identity provider along with their roles | [AdminGetUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminGetUser.html) |
89+
| POST /api/administration/users | Register user in our identity provider, along with roles | [AdminCreateUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html) |
90+
| PUT /api/administration/users | Update existing user in our identity provider, along with their roles | [AdminUpdateUserAttributes](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html) |
91+
| DELETE /api/administration/users/{username} | Delete user in our identity provider, along with their roles | [AdminDeleteUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminDeleteUser.html) |
92+
| POST /api/administration/users/{username}/reset-password | Reset a user's password | [AdminResetUserPassword](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminResetUserPassword.html) |
93+
| GET /api/administration/users<br/>?limit={page size}<br/>&cursor={nextCursor from previous response}<br/>&searchString={searchString}<br/>&searchField={USERNAME \| EMAIL \| etc.}<br/>&orgId={role orgId}<br/>&applicationName={role applicationName}<br/>&roleName={roleName} | List/query users from our identity provider, along with their roles.<br/><br/>Uses cursor-based pagination: The response body includes a `nextCursor` field, which can be passed in the `cursor` query parameter to get the next page. When `nextCursor` is `null`, then there are no more users to fetch. | [ListUsers](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUsers.html) |
8494

85-
Run the `Main` file.
95+
#### Data structure of user data with roles
8696

87-
1. Option 2: Via Maven
88-
89-
```bash
90-
./build-and-run.sh
91-
```
97+
```json
98+
{
99+
"username": "test.testesen",
100+
"userId": "4b670e7f-0ae9-4ce8-9a8b-b27d00d2f31d",
101+
"email": {
102+
"value": "test@example.org",
103+
"verified": true
104+
},
105+
"phoneNumber": {
106+
"value": "12345678",
107+
"verified": false
108+
},
109+
"userStatus": "CONFIRMED",
110+
"enabled": true,
111+
"createdAt": "2025-12-04T07:25:11Z",
112+
"attributes": {
113+
// Attributes are arbitrary key-value data submitted by your BFF.
114+
// Cognito supports certain standard attributes, such as "name".
115+
"name": "Test Testesen"
116+
},
117+
"roles": [
118+
{
119+
"applicationName": "test-application",
120+
"orgId": "liflig",
121+
"roleName": "admin",
122+
"roleValue": null
123+
}
124+
]
125+
}
126+
```
92127

93-
1. Option 3: Package and run with the actual Docker image
128+
## Deploying User Roles service in your project
129+
130+
- Set up a Cognito user pool
131+
- Deploy User Roles service, using Docker image published on GitHub, along with a Postgres database
132+
- For the user administration module to be enabled, the service needs the following:
133+
- Config parameter `aws.cognito.userPoolId`
134+
- These permissions:
135+
- `cognito-idp:AdminGetUser`
136+
- `cognito-idp:AdminCreateUser`
137+
- `cognito-idp:AdminUpdateUserAttributes`
138+
- `cognito-idp:AdminDeleteUser`
139+
- `cognito-idp:AdminResetUserPassword`
140+
- `cognito-idp:ListUsers`
141+
- Implement a "pre-token generation lambda" that fetches roles from User Roles to populate Cognito
142+
JWTs
143+
- Implement JWT verification and role parsing for authentication and authorization in your APIs
144+
- For the user administration module:
145+
- Implement an API client in your BFF that calls the administration API of the User Roles service
146+
- Your BFF should verify that the requesting user has permission to update roles. This is where
147+
you enforce your project’s hierarchy of roles (i.e., which roles are allowed to change other
148+
roles)
149+
- Implement UI for user management
150+
151+
For example implementations of the points above, see the
152+
[Liflig-internal Confluence page](https://liflig.atlassian.net/wiki/spaces/CALS/pages/16164029/User+Roles+Service#Deploying-User-Roles-service-in-your-project).
94153

95-
```bash
96-
# See the script for details.
97-
./build-and-run-docker.sh
98-
```
154+
## Running locally
99155

100-
1. Access the service at http://localhost:8080/health
156+
<!-- @formatter:off -->
157+
1. Start the database: `docker-compose up -d`
158+
2. Build and run the application
159+
- Option 1: Run the `Main.kt` file from your IDE
160+
- Option 2: Via Maven, `./build-and-run.sh`
161+
- Option 3: Package and run with the actual Docker image, `./build-and-run-docker.sh`
162+
3. Access the service at http://localhost:8080/health
163+
<!-- @formatter:on -->
101164

102165
## Linting
103166

architecture.png

-45.3 KB
Binary file not shown.

0 commit comments

Comments
 (0)