Authorisation middleware to check for user roles and Services

[Ajeyakrishna-k]

Problem:

Suppose we have a route which needs to be accessed by a super user and a service, currently we do not have any function to do that.

Issue Description:

We have growing services and we will need to authenticate each requests among these services. Currently our backend employ's a middleware which will either authorise a user based on their roles or can authenticate only a service.

To improve these authorisation flow's we need to create a common middleware to authorise both user and a service so that we can easily add conditions like either a super user or say cron-jobs service can have access to a certain API.

Code Link: website-backend

Proposed Solution:

• RSA256 asymmetric encryption will be used to validate authentication tokens.
• Users will be authenticated based on the cookie received.
• Services will have to share a unique string with their Bearer token using which PUBLIC KEY will be selected to validate the token signature.

Create a middleware with the following parameters:

• allowedServices (Array of Strings): A list of service names that are allowed to access the API. Example services could include 'DISCORD_COMMANDS', 'CRON_JOBS'.
• allowedUserRoles (Array of Strings): A list of user roles that are permitted to access the API. Example roles could include 'SUPER_USER', 'APP_OWNER'.

// allowedUserRoles = ['SUPER_USER','APP_OWNER'];
// allowedServices = ['DISCORD_COMMANDS',CRON_JOBS'];

const authorizeRoles = (allowedUserRoles, allowedServices) => {

};

Acceptance Criteria:

• The middleware must correctly identify if a request is coming from a user or a service.
• When the request is from a user, the middleware should verify the user's role against theallowedUserRoles array.
• When the request is from a service, the middleware should check the service name against the allowedServices array.
• If a user's role is found in allowedUserRoles, the request proceeds to the next middleware or handler without interruption.
• If a service name is found in allowedServices, the request should be allowed to continue without interruption.
• If a user's role is not in allowedUserRoles and the service name is not in allowedServices, the middleware should reject the request and send a response with a 403 Forbidden status code.
• The middleware must be integrable with the existing backend system without causing disruptions or conflicts.
• Middleware will throw an error if both allowedServices and allowedUserRoles are empty arrays

[vikhyat187]

The middleware must correctly identify if a request is coming from a user or a service.

How are we planning to pass this service info to the other service? via headers or other way?

The middleware must be integrable with the existing backend system without causing disruptions or conflicts.

Now the flow should look like user calling the middleware and that middleware calling the backend right?

Should we also think of having few methods which can check if the user is a super user, say I use the same user data in skill tree and I wanted to understand if the user is a super user, then this middleware should help us.

[Ajeyakrishna-k]

How are we planning to pass this service info to the other service? via headers or other way?

Since we are using JWT to for authorisation. We can add the details of the service which sent the request in payload.

Now the flow should look like user calling the middleware and that middleware calling the backend right?

Middleware is just a function in our RDS backend.

Should we also think of having few methods which can check if the user is a super user, say I use the same user data in skill tree and I wanted to understand if the user is a super user, then this middleware should help us.

• Not sure about this question.
• If we want to get user details then there is a separate API in our backend which provides all details along with roles.

[yesyash]

• how are we going to authenticate a service? how will the public key be used when i make a request from my service to the rds backend?

[vikhyat187]

If we want to get user details then there is a separate API in our backend which provides all details along with roles.

We can also think of a new API which only does the roles validation, given a user and role validate if that exists. This will be a seperate ticket.

[Ajeyakrishna-k]

how are we going to authenticate a service? how will the public key be used when i make a request from my service to the rds backend?

Your service will need to generate a JWT token and sign it using the respective private key.

[yesyash]

how are we going to authenticate a service? how will the public key be used when i make a request from my service to the rds backend?

Your service will need to generate a JWT token and sign it using the respective private key.

can we not have a auth service which takes care of authentication from multiple clients?

[Ajeyakrishna-k]

can we not have a auth service which takes care of authentication from multiple clients?

Yes, we definitely can! Since that is out of scope for this issue, not interested to discuss that here.

Note: Not addressing the issue of adding authentication to newly created services here. This is just a refactor which will consume around 1hr of development time.

[vikhyat187]

how are we going to authenticate a service? how will the public key be used when i make a request from my service to the rds backend?

Your service will need to generate a JWT token and sign it using the respective private key.

can we not have a auth service which takes care of authentication from multiple clients?

Yes I think, if we are building this, we can reuse it over multiple places, can you ask Ankush / Tejas on this once