Architecture(s) et application(s) Web

Architecture(s) et
application(s) Web

CSC4101 - Sessions, Contrôle d'accès

12/10/2024

Plan de la séquence

Objectifs de cette séance (1h) :

Sessions applicatives
Contrôle d'accès
Mécanismes d'authentification
Rôles et permissions
Mise en œuvre avec Symfony

Session (en informatique)

« session n. f. (télécommunications, informatique) : Période de temps continue qui s’écoule entre la connexion et la déconnexion à un réseau ou à un système, ou encore l’ouverture et la fermeture d’un logiciel d’application. »

Source : Grand dictionnaire terminologique - Office Québécois de la langue française
« In computer science and networking in particular, a session is a time-delimited two-way link, a practical (relatively high) layer in the TCP/IP protocol enabling interactive expression and information exchange between two or more communication devices or ends – be they computers, automated systems, or live active users (see login session). […] »

Source : https://en.wikipedia.org/wiki/Session_(computer_science)

Paradoxe : applications sur protocole sans état

L’expérience utilisateur suppose une instance unique d’exécution d’application, comme dans un programme « sur le bureau »
Faciliter la contextualisation du HATEOS : quelles transitions sont valides à partir de l’état courant ?
Pourtant, HTTP est stateless (sans état) : chaque requête recrée un nouveau contexte d’exécution

L’application n’arrête pas de s’arrêter

À chaque requête :

démarrage application
routage vers méthode Contrôleur
1. chargement depuis base et/ou session
2. traitements
3. sauvegarde en base et/ou session
envoi Réponse
mort

Sans la session, continuité entre deux requêtes ?

Application peut garder la mémoire

Le programme Web peut stocker un état (par ex. en base de données) à la fin de chaque réponse à une requête
Il peut le retrouver au début de la requête suivante
- Le client doit pour cela se faire reconnaître
Simule une session d’exécution unique comprenant une séquence d’actions de l’utilisateur

Le client HTTP peut s’identifier

Argument d’invocation dans URL
en-tête particulier ?
Cookie
…

Identification du client par cookie

Identifie le client
Commun à un ensemble d’URLs

Cookies

Juste un « jeton » unique sur un certain périmètre (serveur, chemin d’URL, application, …)
Format choisi par le serveur
Taille limitée :
- peut contenir des données de l’application
- pas un état de l’application complet
Données en clair dans le stockage de cookies du navigateur
Durée de vie potentiellement grande

Reconnaître le client HTTP

Données du cookie stockées sur client, envoyées avec la requête au serveur
Le serveur peut trouver des données plus complètes stockées de son côté (une session), sur présentation d’un identifiant (présent dans le cookie).
À chaque requête, le cookie permet relier :
- nouvelle requête d’un client HTTP (en-têtes HTTP : valeur d’un cookie existant)
- mémoire de l’état précédent sauvegardé côté serveur à la fin de la réponse HTTP précédente du même client

Stocker une session

Session : espace de stockage unique côté serveur
Objets du modèle de l’application stockés dans la session (pas contrainte taille), sérialisés
Session retrouvée via un identifiant
- Identifiant fourni par un cookie (local au client)
Durée de vie et unicité des sessions au choix du serveur

Figure 2 : Stockage session côté serveur

La « même » page Web accédée par deux clients présentant des ID de cookies différents, ne sera peut-être pas le même document, s’il est généré dynamiquement en fonction des informations présentes dans la session.

Là où le cookie est stocké côté client HTTP, la session correspondante est stockée côté serveur.

La session est potentiellement grosse, peut-être stockée en base de données, ou dans des fichiers… Mais pas dans la même base de données que le Modèle de l’application.

En pratique, le plus souvent, cette session est stockée sur un système de fichiers ou dans une mémoire partagées (pour la gestion de cohérence si le serveur d’application est dans un environnement d’exécution distribuée avec des exécutions successives sur des serveurs différents).

La plate-forme du langage de programmation rend l’utilisation de la session très facile pour le programmeur, en masquant la complexité sous-jacente. Cf. https://symfony.com/doc/current/session.html pour Symfony.

Détails cookie

Créé lors de la première requête d’un client (n’ayant pas fourni ce cookie)
Le serveur délivre les cookies en les intégrant dans en-têtes de réponse HTTP
- utilise l’en-tête particulier « Set-Cookie » (sur une ligne)
```
Set-Cookie: <nom>=<valeur>;expires=<Date>;domain=<NomDeDomaine>; path=<Path>
```
Le client stocke le cookie reçu dans la réponse, pour pouvoir le renvoyer aux prochaines requêtes vers ce serveur

Exemple de réponse HTTP :

HTTP/1.1 200 OK
Server: Netscape-Entreprise/2.01
Content-Type: text/html
Content-Length: 100
Set-Cookie: clientID=6969;domain=unsite.com; path=/jeux

<HTML>...

Par la suite, ce cookie sera renvoyé par le client au serveur, dans chaque requête ayant comme URL de début :

http://www.unsite.com/jeux/...

Wrap-up sessions

Requêtes HTTP déclenchées lors demandes de transition d’un état à l’autre de l’application
L’exécution (PHP) résultante s’effectue sur serveur HTTP sans mémoire des interactions précédentes entre client et serveur (stateless)
L’utilisateur a une impression de continuité : une seule session d’utilisation de l’application, où requêtes successives ont des relations de causalité
Différentes solutions techniques, dont les cookies

Plan de la séquence

Objectifs de cette séance (1h) :

Sessions applicatives
Contrôle des accès
Mécanismes d'authentification
Rôles et permissions
Mise en œuvre avec Symfony

Protéger les données / fonctions

Confidentialité : application accessible sur Internet, même si processus / données privés
Privilèges : qui fait quoi
- Spécifications fonctionnelles (profils utilisateurs)
- Contrôle par l’application (HATEOS)
Contrôle d’accès : reconnaître les utilisateurs, et mettre en place les restrictions (sans nuire à l’utilisabilité, mobilité, etc.)

Autres aspects sécurité vus dans une séance ultérieure

Contrôle des accès

Protéger l’accès aux fonctionnalités de l’application
Qui est autorisé à faire quoi

Dans un monde ouvert (Internet, Web, standards)

Sécurité par obscurcissement ?

Ne pas protéger spécifiquement,
et ne pas documenter / expliquer / rendre visible ?

Ce n’est pas parce que le code de l’application est caché sur le serveur que les méchants ne trouveront pas des failles !

#Fail

Contrôle effectif

Au niveau de la configuration du serveur (ne pas permettre aux clients de découvrir les failles en regardant le source)
Dans les fonctionnalités du logiciel : configuration dans le code du projet Symfony (module « firewall »)
Mesures complémentaires (audit, etc.)

Modèle contrôle des accès

Identification: l’utilisateur fournit à un service un moyen de le reconnaître : identité
Authentification: le service vérifie cette identité
Autorisation: le service donne à l’utilisateur certaines permissions

1) Identification

Identifiants :
- email
- identifiant d’utilisateur (login)
- certificat client X509 (TLS)
- Jeton dans un en-tête HTTP
- …
L’identification doit être confirmée par l’authentification

2) Authentification

Vérifie client agit bien pour le propriétaire légitime de l’identifiant présenté
Protocole de vérification :
- mot-de-passe
- signature valide d’une donnée quelconque (challenge) avec la clé privée associée au certificat client
- délégation à service externe (Shibboleth/CAS, OAuth 2, …)
- 2FA (two-factor authentication)
- nouveaux standards : U2F, Fido, TOTP, …
- …

3) Autorisations

Permissions applicatives associées à l’identifiant
Pour une certaine période
Génération d’un jeton temporaire (session authentifiée)
- Cookie

Dans protocole HTTP

Identification / authentification de « bas niveau » dans le protocole HTTP (cf. ~~RFC2617~~ RFC 7617: The ’Basic’ HTTP Authentication Scheme)
Rappel : HTTP est sans état
- Le client HTTP doit se réauthentifier à chaque requête
Permet de transporter l’authentification dans les en-têtes
Alternative : authentification applicative + session applicative

</controle_acces>

Plan de la séquence

Objectifs de cette séance (1h) :

Sessions applicatives
Contrôle des accès
Mécanismes d'authentification
Rôles et permissions
Mise en œuvre avec Symfony

Mécanismes

Authentification HTTP
- Authentification « Basic »
- autres
Authentification applicative

Basic Auth

Inconvénient : pas de logout

Authentification applicative

Gestion de l’identification et de l’authentification par l’application

L’authentification est une des fonctionnalités de l’application, via la session
Formulaire d’authentification
- Login
- Mot-de-passe
« base de données » de comptes

Formulaire d’authentification

Formulaire « standard »
Champs :
- Login ou email
- Mot-de-passe (saisie cachée)

Vérification de l’authentification

Comparer avec profil d’utilisateur connu (en base de données)
Générer une session pour reconnaître l’utilisateur par la suite
Attention : attaques « force brute »
- Invalider un compte/profil, ou faire une gestion de surcharge qui désactive les tentatives (throttling, blacklist réseau, etc.)

Dans Symfony

Composant Security
Flexible : gestion souple et extensible de l’authentification

Gère par exemple les utilisateurs dans la base de données via classe User + Doctrine
Assistants générateurs de code pour les dialogues

Procédures ?

Gestion des mots-de-passe (qualité aléa, longueur, stockage approprié, etc.)
Récupération de compte si oubli mot-de-passe
- Canal sécurisé ou envoi jeton de réinitialisation sur email (implique gestion emails)
Confirmations d’authentification pour sections critiques de l’application
Garder des traces (audit, obligations légales)
Conformité RGPD (données personnelles dans les profils)

Captcha

Completely Automated Public Turing test to tell Computers and Humans Apart

Vérifier qu’un humain est aux commandes

Pas infaillible
Problèmes accessibilité

Travail dissimulé
Surveillance

Tout comme pour les CDN (Content Delivery Network) ces Captcha sont opérés par des tiers, et peuvent donc leur servir à tracer les utilisateurs des applications, ce qui est potentiellement problématique à l’ère post-Snowden, et au regard du RGPD.

De plus, pour l’exemple de l’illustration « CAPTCHA et digital labo », les Captcha de ce type peuvent permettre à leurs opérateurs (ici Google) d’entrainer des mécanismes d’IA grâce au travail « bénévole » (contraint) des utilisateurs qui essayent de résoudre le puzzle… en espérant que ça ne serve pas in-fine à des applications militaires, par exemple (véhicules ou systèmes d’armes autonomes) !

Pour une ressource récente sur le sujet, voir CAPTCHA : les machines « prouvent » plus rapidement qu’elles sont des humains (NextImpact août 2023)

Authentification à double facteur

2FA (Two factor authentication)

+ robuste :
1. élémént connu
2. élément possédé
Exemples :
- carte bancaire (possession) + code PIN (connu)
- login + mdp (connu) + SMS reçu (possession mobile)
- login + mdp (connu) + badge de sécurité générant un code unique (possession)
- login + mdp (connu) + code TOTP récupéré dans appli sur ordiphone

</authentification>

Plan de la séquence

Objectifs de cette séance (1h) :

Sessions applicatives
Contrôle des accès
Mécanismes d'authentification
Rôles et permissions
Mise en œuvre avec Symfony

Role-Based Access Control (RBAC)

Contrôle d’accès à base de rôles

Utilisateur
Rôle
Permissions

Figure 6 : Exemple d’affectation de rôles

Permissions

Modèle applicatif de permissions
Vérifier les permissions à chaque traitement de requête
- Routage
- Dans les traitements fonctionnels

Module « Firewall » de Symfony

Réponses Web

Code 200 + Page mentionnant problème de permissions
Code 403 (et peut-être un message dans la page) ?

</RBAC>

Plan de la séquence

Objectifs de cette séance (1h) :

Sessions applicatives
Contrôle des accès
Mécanismes d'authentification
Rôles et permissions
Mise en œuvre avec Symfony

Flexibilité

Symfony permet de gérer plein de modalités d’authentification
Choix : s’appuyer sur la base de données, et des contrôleurs d’authentification générés par les assistants

Gestion des utilisateurs avec Doctrine

Classe User du Modèle (et mapping Doctrine en base)
Définition de règles dans le firewall Symfony
Rôles
Ajouter des formulaires (+ templates) :
- Login + password
- Logout
- (Inscription, rappel du mot-de-passe, …)

Classe `User`

symfony console make:user

namespace App\Entity;

use App\Repository\UserRepository;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface;
use Symfony\Component\Security\Core\User\UserInterface;

#[ORM\Entity(repositoryClass: UserRepository::class)]
class User implements UserInterface, PasswordAuthenticatedUserInterface
{
    // ...

    #[ORM\Column(length: 180, unique: true)]
    private ?string $email = null;

(appelée Member dans le projet)

Hiérarchie de rôles

Arbitraire, selon les besoins de l’application
Exemple :
1. ROLE_SUPER_ADMIN
2. ROLE_ADMIN
3. ROLE_CLIENT
4. ROLE_USER

# security.yml

role_hierarchy:
    ROLE_CLIENT:      ROLE_USER
    ROLE_ADMIN:       ROLE_USER
    ROLE_SUPER_ADMIN: [ROLE_USER, ROLE_ADMIN]

Firewall

Contrôle l’accès aux URLs en fonction des rôles :

# app/config/security.yml
security:
    # ...

    firewalls:
        # ...
        default:
            # ...

    access_control:
        # require ROLE_ADMIN for /admin*
        - { path: ^/admin, roles: ROLE_ADMIN }

Utilisation dans les contrôleurs

Contrôle d’accès sur les routes :

#[Route('/comment/{postId}/new', name: 'comment_new', methods: ['GET', 'POST'])]
#[IsGranted('IS_AUTHENTICATED_FULLY')]
function addComment(Post $post): Response {
    //...

IS_AUTHENTICATED_FULLY : un utilisateur qui vient vraiment de se reconnecter

Contrôle d’autorisation dans le code des méthodes :

public function adminDashboard(): Response {
    $this->denyAccessUnlessGranted('ROLE_ADMIN', null, 'Access denied!');

« Entrée interdite, à moins que… »

Profil de l’utilisateur

Accès aux propriétés de l’utilisateur :

$this->getUser()

// ...

$email = $this->getUser()->getEmail();
$post->setAuthorEmail($email);

Personnalisation apparence

Gabarits Twig

{% if is_granted('ROLE_ADMIN') %}
  <a href="...">Delete</a>
{% endif %}

Gestion fine

Dans code d’une méthode de contrôleur :

$this->denyAccessUnlessGranted('ROLE_ADMIN', null, 'Access denied!');

équivalent à :

if (! $this->get('security.authorization_checker')->isGranted('ROLE_ADMIN')) {
    throw $this->createAccessDeniedException('Access denied!');
}

Déclenche une exception :

erreur 403
ou redirection vers login

Exceptions et codes retour

try {
    // faire quelque chose qui appelle : throw
} catch (Exception $e) {
    echo 'Exception reçue : ',  $e->getMessage(), "\n";
}

Permet d’intercepter de façon standard les exceptions :

AccessDeniedException (403)
NotFoundHttpException (404)

</symfony>

Take away

Sessions
- Cookies
- Session Symfony
Contrôle d’accès
- Principes
  - Identification
  - Authentification
  - Autorisations
- Rôles (RBAC)
- Contrôle dans Symfony

Récap

[X] HTTP (GET)
[X] PHP
[X] Doctrine
[X] Routeur Symfony
[X] HTML
[X] Twig
[X] CSS
[X] Formulaires
[X] Sessions
[X] Contrôle d’accès

Tout ce qu’il faut pour un site mis en ligne

Postface

Crédits illustrations et vidéos

Illustration copie écran Basic Auth HTTP via Joel Dare

Copyright

Document propriété de ses auteurs et de Télécom SudParis (sauf exceptions explicitement mentionnées).
Réservé à l’utilisation pour la formation initiale à Télécom SudParis.