Used a "JWT token exchange" concept to allow access to the "Queues
Admin", considering an IDIR(Ministry) user already authenticated and
with a specific role.
> A JWT (JSON Web Token) exchange is a process where an existing JWT is
used to obtain a new JWT, often with different claims or for accessing
different resources.
_Note:_ Keycloak has a [token exchange preview
feature](https://www.keycloak.org/securing-apps/token-exchange) that
seems what was needed but is not enabled right now. Also, it would be
possible to use our Keycloak js lib and authenticate a second token, but
it does not seem to be recommendable and the current approach of
SIMS-API issuing a token seems good enough for now.
The SIMS-API will allow access to a specific endpoint
`users/queue-admin-token-exchange`, protected under a Ministry role
(`aest-queue-dashboard-admin`), to generate a cookie with a SIMS-API
issued token where its sole purpose is to allow access to the "Queues
Admin". Queues admin is now able to validate the generated token based
on a shared secret between the SIMS-API and queue-consumers that allows
the token to be signed and validated.
This token is saved in a cookie that will also be accessible by the
"Queues Admin", allowing its validation. The token has the security
properties sets (`httpOnly`, `secure`, and `sameSite`) to prevent
different security vulnerabilities. Some of those must be relaxed for
local development only.
_Note:_ `credentials: true` was added under the `app.enableCors` to
allow the generated cookie to be saved on the client, otherwise `Axios`
would not save it.
Please see below an example of what the generated token looks like, the
known [registered
claims](https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-token-claims#registered-claims)
were used.
```json
{
"iss": "sims-api",
"sub": "some-user-guid@idir",
"aud": "queues-dashboard",
"iat": 1739839795,
"exp": 1739839915
}
```
The new way of accessing the "Queues Admin" is using the new link in the
Ministry portal. Once accessed, it will generate the token to allow the
user to access the queues dashboard.
The new Ministry role (`aest-queue-dashboard-admin`) is intended to
show/hide the button to avoid confusion to other users since this is
supposed to be accessible to only a few users.
## Possible next steps
- Share some API minor utils for the access log.
- Add a GUID to the token to allow a "session" control using a shared
resource (like Redis), to invalidate the cookie after a few minutes of
inactivity.
## Notes on secret generation
The secret key to be saved to the GitHub should be generated using some
strong random generator, for instance, executing the `openssl rand
-base64 32`. The value should be sent to the PODs as base64 which means
it should be added to GitHub secrets as a base64 string.
