Module Connexion

Isotope utilise spring-security et repose sur JWT (https://jwt.io/). Cela signifie qu'à chaque échange entre le frontend et le backend, un token doit être envoyé. Ce token contient les informations sur l'utilisateur connecté et suit la spécification JWT.

Connexion standard

Avec la connexion standard, pour obtenir un token le client React présente un formulaire avec login et mot de passe.

source

La configuration

# Header utilisé dans la request pour envoyé le token 
jwt.header=Authorization
# Clé utilisée pour chiffrer le mot de passe
jwt.secret=i501oP3
# attention, pour le moment, cette valeur d'expiration doit aussi être utilisée dans le fichier App.jsx du front en
# enlevant quelques secondes
jwt.expiration=1800
# Valeur à changer pour modifier l'url de base du controller de connexion
jwt.route.authentication.path=/auth
# exemple d'utilisation de la whitelist
#security.paths.whitelist=/api/admin/bo/modelemodules/media/**

Les classes Java importantes

• JwtAuthenticationTokenFilter correspond au filtre utilisé dans chaque action pour vérifier la présence du token et insérer un JwtUser dans spring security.
• JwtUserDetailsServiceImpl correspond à l'implémentation de UserDetailsService pour Isotope.
• JwtTokenUtil gère, crée, signe et vérifie le token JWT Isotope.
• JwtUser est l'implémentation du UserDetails de sring security pour Isotope.
• SecurityConfig contient toute la configuration de spring security pour Isotope.
• AuthenticationRestController correspond au controller qui contient la méthode login et la méthode user

Connexion Google

Isotope intègre la connexion à une API Google pour la connexion de ses utilisateurs via la librairie Isotope Security Google.

Pour l'utiliser, ajoutez dans votre POM la dépendance maven suivante:

<dependency>
    <groupId>com.ipsosenso</groupId>
    <artifactId>isotope-security-google</artifactId>
</dependency>

Le principe

Pour la connexion à Google, le client React s'occupe de réaliser l'appel à l'API Google par l'intermédiaire de la librairie react-google-login.

Le token est ensuite envoyé au serveur isotope avec la même méthode que la connexion standard : /auth/login. Isotope vérifie que le domaine du compte correspond à celui renseigné en configuration, il vérifie ensuite le token auprès des serveurs Google avec le Google id renseigné en conf également et pour finir si le login existe en BDD isotope, le token est renvoyé.

Le principe reste par la suite le même que pour la connexion standard (mis à part que le filtre Google GoogleJwtAuthenticationTokenFilter vérifie le token auprès de Google).

La configuration

# Google ID à renseigner
google.client.id=851856015255-unhs3m3xxxxxxxj8i6bcds9812hlp8.apps.googleusercontent.com

# Exemple
google.client.domainRestrictions[0]=petitforestier.fr
google.client.domainRestrictions[1]=ipsosenso.com

À la première connexion

Lors de la première connexion, une fois que le token a été vérifié auprès de Google et qu'il est valide, l'application crée un compte en base (en lui plaçant le rôle INVITE uniquement).

Les classes Java importantes

• GoogleJwtAuthenticationTokenFilter surcharge du token filter d'isotope.
• GoogleJwtUser surcharge du JwtUser d'isotope pour intégrer le Google Id et la Locale issue de Google en supplément.
• GoogleOAuth2RestController surcharge du controller d'isotope pour appeler les services Google.
• GoogleSecurityConfig contient la configuration propre à Isotope Google
• GoogleServiceImpl contient les méthodes qui vérifient le compte auprès de Google.

Connexion LDAP

Isotope intègre l'utilisation d'un annuaire LDAP pour la connexion de ses utilisateurs via la librairie Isotope Security LDAP. Pour l'utiliser, ajoutez dans votre POM la dépendance maven suivante:

<dependency>
    <groupId>com.ipsosenso</groupId>
    <artifactId>isotope-security-ldap</artifactId>
</dependency>

Le principe

Lorsque le serveur reçoit du client les identifiants de connexion, il commence par rechercher l'utilisateur dans le LDAP. Si celui-ci existe, il en récupère le DN (Distinguished Name).

Il vérifie ensuite que l'utilisateur existe en BDD, et le cas échéant récupère via le DN de l'utilisateur ses profils renseignés dans le LDAP.

Enfin, il construit un JWTUser à partir de l'utilisateur en base, et de l'intersection des profils de l'utilisateur dans le LDAP et dans la BDD. Cet utilisateur est ensuite exploitable comme dans le cadre d'une connexion classique.

La configuration

# l'URL d'accès au LDAP
isotope.security.ldap.url=ldap://url:port

# Identifiants du gestionnaire du LDAP
isotope.security.ldap.manager-dn=cn=Manager,dc=isotope,dc=com
isotope.security.ldap.manager-password=password

# Le noeud racine de la partie du LDAP contenant les utilisateur
# Utilisé pour la recherche du DN de l'utilisateur à authentifier
isotope.security.ldap.base-recherche-personnes=dc=ipsosenso,dc=com

# Le noeud racine de la partie du LDAP contenant les profils
isotope.security.ldap.base-recherche-profils=sn=ISOTOPE,sn=applications,dc=ipsosenso,dc=com

Les classes Java importantes

• LdapAuthenticationController surcharge du controller d'isotope pour authentifier l'utilisateur via le LDAP.
• LdapSecurityConfig contient la configuration propre à Isotope security LDAP
• LdapService contient les méthodes de connexion au LDAP, d'authentification de l'utilisateur, et de récupération des profils.

Téléchargement de fichiers / Affichage d'images et sécurité

Dans Isotope, il est possible de :

1. télécharger un fichier
2. afficher une image

qui sont protégés : non accessible en mode déconnecté.

Le principe

Un service générique de génération de Ticket (TicketService) qui permet de récupérer un ticket valable un certain temps (en conf) pour une url donnée. Ce service reçoit en entrée le user et l'url et génère un ticket qu'il renvoie. On requête ensuite le serveur pour télécharger notre fichier avec son URL à laquelle on passe en paramètre GET ce fameux ticket. Il y a un filtre (TicketFilter pour lequel on indique sur quelles URLs ce filtre fonctionne dans la configuration) qui autorise la récupération du fichier s'il reconnait l'url et que le ticket est bien valide.

Le ticket est au format JWT et contient un paramètre "path" qui correspond au path demandé. Il est possible de changer la clé qui identifie ce paramètre dans le token.

Côté client, dans isotope, on a déjà un composant (qui s'utilise comme un <a href=''>test</a>) qui s'occupe pour nous de faire l'appel au service de ticket et de télécharger ensuite le fichier (https://git.ipsosenso.com/isotope/isotope-client-react/blob/master/src/components/download/IsotopeLink.jsx).

La configuration

# Temps en ms pendant lequel le token sera valide (par défaut 30000ms) 
#security.ticket.validity
# Identifiant utilisé dans le token JWT pour le path
#security.ticket.jwt.key=path
# Correspond au paramètre GET à utiliser pour envoyer le ticket sur une URL protégée
#security.ticket.parameterkey
# Exemple de surcharge de la liste des url qui fonctionnent par ticket
#security.ticket.urlliste=/export/**,/download/**

Les classes Java importantes

• TicketController permet de récupérer un ticket pour un path donné.
• TicketService contient le code de création des tickets pour le système de ticket d'Isotope.
• TicketSecurityConfig contient la surcharge de la sécurité isotope pour autoriser certaines URLs à utiliser le service de ticket.
• TicketFilter s'occupe de vérifier le ticket pour les URLs indiquées en conf.