Important notice

THIS PROJECT IS UNDER ACTIVE DEVELOPMENT AND IS NOT STABLE NOR READY.

Please view the first page of the wiki for more informations about this project.

Objectives

As for now, the NASS has completed it's first step: a basic authentication system based on a 4-layers security:

• Routes are pre-defined and not any other route can be accessed.
• The service (backend, API) must be registered to the NASS and valid at the time of the request.
• The user must be registered to the NASS (via the API or the service), as well as its tokens and sessions.
• Any action is monitored and logged by the NASS via the "contracts" system, which is a set of rules that the service must follow to be able to do anything with the NASS.

Now, the NASS has to be extended to allow the following features:

• Contract management: Allow services to ask for contracts to the NASS, which includes:
  • Secure tokenization for APIs, renewing the token at some given times (and so, allowing the service to have x ∈ [1,2] tokens at the same time in order to prevent system interruptions).
  • Actions monitoring and logging, which is allowing the APIs to perform the requested actions by the user.
• User management: Allow users to manage their own accounts, including changing passwords, updating profile information, and managing sessions. Users must be able to register, log in, and log out securely. Users can also connect themselves to the NASS via the API they are using if it is not a NAFLOWS service, in order to manage their data.
• Service management: Allow services to manage their own registrations, including updating service information and managing service tokens. Any user can register a service and manage it by themselves. The API key, also considered as a "service token", is used to authenticate the service with the NASS and is meant to be the sold product.

Production Notice

See the following file before production deployment:

• ./mongo-init/init.js - Contains dummy data that can cause security issues if not removed or modified before going live.
• ./.env - Contains sensitive environment variables that should be configured correctly for production use.
• ./TODO.TODO - Contains a list of tasks that need to be completed before production deployment.
• stv.ts - The line token.id === "3" is a temporary condition to test the frozen token feature. This should be removed or modified before production deployment. It is made to exclude the other tokens from being frozen, and make the tests work.
• ssv.ts - The variable allInformationsCorrect are to be compared with the hashed values in the database. This can be done later.

Pre-production checklist

• Remove or modify dummy data in ./mongo-init/init.js.
• Configure sensitive environment variables in ./.env.
• Set ./api/.env to AUTH_API_URL_DEV=http://auth-api-1:3000
• Set ./frontend/vite.config.ts to VITE_AUTH_API_URL=https://nass.naflows.com/client-service:3000