[RFC] Put into production "Portail-des-eleves" and "SSO" applications

[delmaass]

• Feature Name: production
• Start Date: 2022-04-04

Summary

One paragraph explanation of the feature.

Some adjustments and additions should be made both on the “Portail-des-élèves” and the “SSO” repositories in order to be able to put into production.

Through this document, we propose a design for the production architecture in order to have a global view on the interactions between the different services.

Motivation

Why are we doing this? What use cases does it support? What is the expected outcome?

The “SSO” and the “Portail des élèves” application are both functional and ready to be deployed in production with few adjustments to do. The arrival of the new “portail” is expected as a major event for the “Mineurs”.

All the expected features are not implemented yet on the “Portail des élèves”. The priority is the deployment in order to collect the first feedbacks by the associations and the beta testing users.

Following the implementation of crucial lacking features requested in the feedback phase, the production deployment will be done, and these new applications will replace the actual “portail”.

Guide-level explanation

Explain the proposal as if it was already implemented and you were teaching it to a user. That generally means:

• Introducing new named concepts.
• Explaining the feature largely in terms of examples.
• Explaining how users should think about the feature, and how it should impact the way they use the “portail”. It should explain the impact as concretely as possible.
• If applicable, provide sample error messages, deprecation warnings, or migration guidance.
• If applicable, describe the differences between teaching this to current users and new users.

For implementation-oriented RFCs (e.g. for compiler internals), this section should focus on how compiler contributors should think about the change, and give examples of its concrete impact. For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms.

As an user, when accessing the actual URL of the “portail” eleves.mines-paris.eu, you should be redirected to the SSO application referenced at the URL sso.mines-paris.eu/portail.

This SSO application will be used by every future applications developed by the Mines-Paristech-Student (Rezal - MinT - Anonymines) team. It allows you to do a single sign in to access all of these applications. For instance, there is a plan to log into the Rezal network used in the “Meuh” with this SSO application.

For your first login, you will receive an email to set up your password.

Once logged, you are redirected to the new “portail” where you have every access as an authenticated user.

Reference-level explanation

This is the technical portion of the RFC. Explain the design in sufficient detail that:

• Its interaction with other features is clear.
• It is reasonably clear how the feature would be implemented.
• Corner cases are dissected by example.

The section should return to the examples given in the
previous section, and explain more fully how the detailed proposal makes
those examples work.

Here is the architecture proposed for the production deployment. Both “SSO” and “Portail-des-élèves” applications are dockerized. Nginx is running as a service.

Edit the design using the following link : https://excalidraw.com/#room=a83595549fbe3e93d554,RcEI12dFhjKima9Tbfdy-Q

As we don’t want to modify the local ports used during the development, we use Docker to publish on specific ports. Here is the list of the public ports :

• SSO :

Service	Port
Backend	8001
Frontend	3001

• Portail-des-élèves :

Service	Port
API (backend)	8000
Frontend	3000
Chat server	4000

• Games :

Service	Port
Pictionary	4001

Nginx is used as a reverse proxy to redirect the HTTP request over specific hosts on the correct application.

We add a security layer with the firewall ufw to ensure other ports are close.

For the beta testing phase, this whole architecture would be deployed on a Rezal VM named Gaïa with few allocated ressources. We will create accounts for the associations which want to give their feedback and for the beta testing users. The whole database would be dropped after this phase.

Once we will deploy this architecture in production, we will migrate the content which can be recovered from the old “portail” as the list of users, associations and other. Users will have to create a new password on the first sign in.

Drawbacks

Why should we not use it ?

This design may not be the best. Dockerizing each application seems to me a good idea when going to production, but there may be better alternatives.

Rationale and alternatives

Questions:

• Why is this design the best in the space of possible designs?
• What other designs have been considered and what is the rationale for not choosing them?
• What is the impact of not doing this?

I don’t have enough experience to answer these questions ☹️

Prior art

Discuss prior art, both the good and the bad, in relation to this proposal.
A few examples of what this can include are:

• Does this design exist in for other projects?
• What are the main recommendation when implementing such a design?
• Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.

This section is intended to encourage you as an author to think about the lessons from other designs, provide readers of your RFC with a fuller picture.
If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other designs.

We should compare this design with other projects which have a SSO server and multiple applications.

Unresolved questions

Questions:

• What parts of the design do you expect to resolve through the RFC process before this gets merged?
• What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
• What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?

Because I don’t have the experience to validate this design by my own, this RFC process should open a discussion around this design. In particular, we have to answer the security questions before going into production.

At the end, we will have a final design of a production pipeline and we will be able to do the necessary adjustments on both “SSO” and “Portail-des-élèves” applications.