Implement endpoint authorization and CRUD endpoint for roles #39

New issue

Open

opened 2025-09-04 07:10:37 +00:00 by hurui200320 · 0 comments

hurui200320 commented

2025-09-04 07:10:37 +00:00

Member

This ticket should add a headers field (type: Map<String, List<String>) to the incoming request message. Then implement the following endpoints for role-service-v1:

createClientRole(clientRole: ClientRole)
- Create a role in the client
deleteClientRole(client: String, roleName: String)
- Delete a role in the client
listClientRole(client: String, first: Int, max: Int): List<ClientRole>
- List roles in the client with pagination.
getClientRole(client: String, roleName: String): ClientRole
- Get a role by name in the client.
updateClientRole(client: String, roleName: String, role: ClientRole)
- Update a role

The ClientRole fields:

id: ClientRole.Id: the id of this role
The ClientRole.Id fields:
name: String: name of the role
client: String: the client name of the client role

Right now the get and update endpoints are useless, but we still need to implement the code to pull data from keycloak and construct the response. In the future we may extend the client role object with attributes, that's when the get and update will be useful.

The role service requires authentication, all requests must contain a Authorization, the value will be Bearer your_client_token (just like any http request). You can have multiple values, but at least one of them should match the client you're given. For example, if you want to add a role to client cleverbrag, then you must provide one token that is issued to the cleverbrag client service account.

This ticket should focus on the implementation of the endpoint authorization, along with some simple CRUD role management. The rest of the role management endpoints will be implemented in separate tickets.

This ticket includes unit tests.

This ticket should add a `headers` field (type: `Map<String, List<String>`) to the incoming request message. Then implement the following endpoints for `role-service-v1`: + `createClientRole(clientRole: ClientRole)` + Create a role in the client + `deleteClientRole(client: String, roleName: String)` + Delete a role in the client + `listClientRole(client: String, first: Int, max: Int): List<ClientRole>` + List roles in the client with pagination. + `getClientRole(client: String, roleName: String): ClientRole` + Get a role by name in the client. + `updateClientRole(client: String, roleName: String, role: ClientRole)` + Update a role The ClientRole fields: + `id: ClientRole.Id`: the id of this role The `ClientRole.Id` fields: + `name: String`: name of the role + `client: String`: the client name of the client role Right now the get and update endpoints are useless, but we still need to implement the code to pull data from keycloak and construct the response. In the future we may extend the client role object with attributes, that's when the get and update will be useful. The role service requires authentication, all requests must contain a `Authorization`, the value will be `Bearer your_client_token` (just like any http request). You can have multiple values, but at least one of them should match the client you're given. For example, if you want to add a role to client `cleverbrag`, then you must provide one token that is issued to the cleverbrag client service account. This ticket should focus on the implementation of the endpoint authorization, along with some simple CRUD role management. The rest of the role management endpoints will be implemented in separate tickets. This ticket includes unit tests.

Rows
Columns