L’authentification d’une démarche peut se faire, de manière paramétrables, selon deux modes d’authentification.
Le premier mode authentification, systématiquement utilisée à l’accès par l’utilisateur à une démarche, est le mode anonyme. Ce mode anonyme consiste en la création d’un token JWT (appel au micro-service SECURITE) dès le chargement de la démarche. Avec ce token, l’application WEB peut appeler les autres API du socle (configuration/brouillon/…).
Une fois la configuration chargée, selon le contenu de cette dernière, une authentification supplémentaire peut être demandée. Celle-ci se fait via le protocole OIDC avec le fournisseur d’identité ServicePublic.fr ou FranceConnect.
Si la démarche le nécessite, une fois les échanges OIDC réalisés et l’usager connecté, le token généré est transmis au socle pour être ajouté au token propre au socle.
Selon le couple “paramètres de l’URL” et “points d’entrée de la configuration”, l’authentification anonyme suffit (passez au chapitre suivant) ou une authentification OIDC est nécessaire (lisez ce chapitre).
Cette authentification OIDC est alors réalisée exclusivement dans le navigateur WEB avec un implicit flow OIDC avec le framework angular-oauth2-oidc (documentation).
Pour rappel, l’application WEB d’une démarche ne sait pas faire grand chose (voire rien) avant d’avoir chargé la configuration. S’enchaînent donc :
Il est possible, dans la configuration d’une démarche, d’imposer, à l’accès à la démarche, une authentification SP et/ou FC. Cette configuration est modulable, à travers les points d’entrée, en fonction des paramètres d’accès la démarche (cf. exemple de la démarche biliothèque accessible sans authentification ou avec.
Techniquement, l’application FRONT se charge puis elle :
L’application FRONT n’a pas besoin de disposer d’un token SP. Donc, pour éviter de divulguer une information inutile, l’API de création de token exposée par le socle PSL va :
Une fois la démarche pleinement chargée (configuration & authentification), le brouillon (si un identifiant est fourni dans l’URL d’accès initial) est chargé. Si la version de la configuration de la démarche est différente entre la sauvegarde du brouillon et son chargement, l’usager redémarre à la première étape. Sinon, il reprend à l’étage à laquelle il s’est arrêté.
L’usager peut alors avancer/reculer dans les étapes de la démarche à son rythme.
Du fait que tout token expire (PSL, SP comme FC), une mécanique régulière (toutes les 5 minutes) appelle lance le raffraichissement du token :
A la soumission, la recherche du point d’entrée cohérent depuis la liste présente dans la configuration publique de la démarche est réalisé dans le code Java sur le même modèle que dans le code TS.
Une fois le point d’entrée trouvé, si ce dernier demande une authentification, l’email présent dans les données soumises et comparé à celui présent dans les données soumises.
Aucune autre donnée soumise n’est contrôlée car, dans la démarche, il est tout à fait autorisé de modifier les données récupérées depuis SP.
Le SI contient plusieurs keystore et truststore utilisés pour différents besoin de chiffrement/authentification :
TLS/HTTPs : toutes les APIs sont exposées (par la gateway comme par les micro-services) en HTTPs. Pour cela, un certificat est présent dans 2-code/.certificatsLocaux/keystore.p12 et utilisé dans les scripts de démarrage (demarrer.sh et tous les _launch Eclipse)
service-configuration : toutes les données sensibles de configuration stockées par service-configuration sont chiffrées. Avant d’envoyer les informations au micro-service, le service déchiffre les données à partir de la clef présente dans keystoreconfig/service-config.jks. Ces éléments de configuration sont présents
authentification mutuelle : les APIs d’administration ne sont accessibles qu’à travers un appel HTTPs contenant un certificat client valide. Les certificats CLIENT valides sont stockés dans 2-code/.certificatsLocaux/truststore.jks et utilisé dans les scripts de démarrage (demarrer.sh et tous les _launch Eclipse)