Architecture(s) et application(s) Web - CSC4101 - Apports du framework Symfony - Contrôle d'accès - Télécom SudParis

Architecture(s) et application(s)
                 Web

             Télécom SudParis

                 (26/10/2018)

CSC4101 - Apports du framework Symfony

          - Contrôle d'accès

CSC4101 2018-2019                                                                                       CM 7

Table des matières
1 Rappel : Où en sommes-nous                                                                               1
2 Contrôle des accès                                                                                       1
3 Authentication Web                                                                                      3
4 Contrôle d'accès et permissions                                                                          6
5 Symfony                                                                                                  7
6 Ensuite. . .                                                                                             9

1 Rappel : Où en sommes-nous
1.1 Récapitulatif
       Gabarits Twig pour le HTML
       CSS avec Bootstrap pour la présentation
       ORM Doctrine pour l'interface avec la BD
       Contrôleurs Symfony (routage)
       Gestion CRUD basique
       Formulaires
       API

1.2 Que manque-t-il ?
     Authentication / contrôle d'accès (S 7)
     Gestion avancée des données soumises : données liées (S 8)
     Sécurité, gestion des erreurs (S 9)
     Déploiement
    Approfondir la compréhension des apports du framework

2       Contrôle des accès
    Cette section présente le principe des mécanismes de contrôle d'accès qui seront mis en ÷uvre
    pour reconnaître les utilisateurs de l'application et leur donner la permission d'utiliser ou non
    les fonctionnalités de celle-ci.

2.1 Protéger les données / fonctions
     Condentialité : application accessible sur Internet, même si processus / données privés
     Privilèges : qui fait quoi
        Spécications fonctionnelles (prols utilisateurs)
        Contrôle par l'application (HATEOS)
     Contrôle d'accès : reconnaître les utilisateurs, et mettre ne place les restrictions (sans nuire à
       l'utilisabilité, mobilité, etc.)
    Autres aspects sécurité vus dans une séance ultérieure

2.2 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)

Poly étudiant                                                                                              1

CSC4101 2018-2019                                                                                         CM 7

   Dans la vie d'une entreprise, on peut déployer des applications sans nécessairement les déployer
   sur le Web, sur Internet, donc ouvertes à tous les vents. . .
   Mais on rend alors l'accès délicat : intranet/extranet, nécessité d'un VPN, compatibilité avec
   terminaux mobiles, utilisateurs nomades, etc.
   Déployer sur le Web garde des avantages.

2.2.1 Sécurité par obscurcissement ?
    Ne pas protéger spéciquement,
    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
   Il faut partir d'un principe de mise en place de contrôles eectifs, d'autant plus si le code source
   de certains éléments de l'application est facilement récupérable (HTML, JS).
   Attention aussi à protéger l'accès aux  couches basses  : middleware, base de données, code
   source, chiers de conguration.
   Le Cloud n'aide pas, de ce point de vue (repositories de code publics, stockage Cloud non-
   protégé).

2.2.2 Contrôle eectif
    Au niveau de la conguration du serveur (ne pas permettre aux clients de découvrir les failles en
     regardant le source)
    Dans les fonctionnalités du logiciel :  rewall  Symfony
    Mesures complémentaires (audit, etc.)

2.3 Modèle contrôle des accès
   Identication l'utilisateur fournit à un service un moyen de le reconnaître : identité
   Authentication le service vérie cette identité
   Autorisation le service donne à l'utilisateur certaines permissions
   Cette section ne vise pas à un cours théorique exhaustif sur le sujet, mais juste à rappeler
   quelques éléments importants, généraux, et illustrés dans le contexte particulier des applications
   déployées en contexte Web.

2.3.1 Identication
    Identiants :
      email
      identiant d'utilisateur (login )
      certicat client X509 (TLS)
      Jeton dans un en-tête HTTP
      ...
    L'identication doit être conrmée par l'authentication
   Importance des standards : compatibilité avec tous les clients Web.
   Les certicats clients X509, par exemple, ont posé des problèmes du fait d'une ergonomie
   discutable dans la mise en ÷uvre dans les navigateurs. . . et de la méconaissance des utilisateurs
   des mécanismes associés (révocation, non-dissémination, etc.).

2.3.2 Authentication
    Valide le fait que celui qui essaye d'utiliser le service est bien le propriétaire légitime de l'iden-
     tiant présenté
    Protocole de vérication :

Poly étudiant                                                                                                2

CSC4101 2018-2019                                                                                    CM 7

        mot-de-passe
        signature valide d'une donnée quelconque (challenge ) avec la clé privée associée au certicat
         client
        délégation à service externe (Shibboleth/CAS, OAuth 2, . . . )
        nouveaus standards : U2F, Fido
        ...
Importance des mécanismes de double facteur d'authentication (2FA).
Problème des mots-de-passe : évolution vers un monde sans mots-de-passe sur le Web : diusion
de nouveaux standards.
Attention à déléguer à un service tiers : est-il able ?

2.3.3 Autorisations
     Permissions applicatives associées à l'identiant
     Pour une certaine période
     Génération d'un jeton temporaire (session authentiée)
       Cookie
    Alors que l'authentication peut être déléguée, la gestion des autorisations est du ressort du
    développeur de l'application.

2.4 Dans protocole HTTP
     Identication / authentication de  bas niveau  dans le protocole HTTP (cf. RFC2617 : HTTP
      Authentication: Basic and Digest Access Authentication )
     Rappel : HTTP est sans état
       Le client HTTP doit se réauthentier à chaque requête
     Permet de transporter l'authentication dans les en-têtes
     Alternative : authentication applicative + session applicative

3      Authentication Web
    Cette section présente un mécanisme d'authentication de base, l'authentication applicative,
    via un formulaire dédié construit par l'application, dans une de ses pages Web.

3.1 Mécanismes
     Authentication HTTP
       Authentication  Basic 
       autres
     Authentication applicative

3.2 Authentication applicative
3.2.1 Gestion de l'identication et de l'authentication par l'application
     L'authentication est une des fonctionnnalités de l'application, via la session
     Formulaire d'authentication
       Login
       Mot-de-passe
      base de données  de comptes
    C'est un module particulièrement sensible : ne pas improviser son développement.
    Atention aux contraintes juridiques en plus de techniques.

Poly étudiant                                                                                           3

CSC4101 2018-2019                                                                                          CM 7

3.2.2 Formulaire d'authentication
    Formulaire  standard 
    Champs :
      Login ou email
      Mot-de-passe (saisie cachée)

3.2.3 Vérication de l'authentication
    Comparer avec prol 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/prol, ou faire une gestion de surcharge qui désactive les tentatives (throt-
        tling, blacklist réseau, etc.)

3.2.4 Dans Symfony
    Composant Security
    Flexible : gestion souple et extensible de l'authentication
    Utilisera le bundle FOSUserBundle pour nous simplier la vie en gérant les utilisateurs via la base
     de données

3.2.5 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)
    Conrmations d'authentication pour sections critiques de l'application
    Garder des traces (audit, obligations légales)
    Conformité RGPD (données personnelles dans les prols)
   Complexe, donc tentative de déléguer à un tiers. . . mais ce tiers est-il able ?
   Augmentation des risques pour les utilisateurs.
   Si on est piraté, seuls nos clients sont victimes. Mais est-ce que ça vaut le coup pour les pirates ?
   Il vaut peut-être mieux qu'ils essayent de pirater FaceBook, et ce jour-là gare à nous (tous)
   qui avons intégré une authentication via FaceBook. . . ?

3.2.6 Captcha
   Completely Automated Public Turing test to tell Computers and Humans Apart
   Vérier qu'un humain est aux commandes

    Pas infaillible
    Problèmes accessibilité

Poly étudiant                                                                                                 4

CSC4101 2018-2019                                     CM 7

    Travail dissimulé
    Surveillance

3.2.7 Authentication à double facteur
    Pas uniquement élément connu
plus
    Élément en possession
   Exemples
    carte bancaire (possession) + code PIN (connu)

Poly étudiant                                            5

CSC4101 2018-2019                                                                                     CM 7

     login + mdp (connu) + SMS reçu (possession mobile)
     login + mdp (connu) + badge de sécurité générant un code unique (possession)
    Authentication plus forte.
    Attention : certains mécanismes s'avèrent moins able que prévu (SMS)
    Attention aux exigences de sécurité réglementaires.

4      Contrôle d'accès et permissions
    Cette section présente le principal modèle de dénition de permissions utilisé pour le contrôle
    d'accès, à base de rôles.

4.1    Role-Based Access Control             (RBAC)
    Contrôle d'accès à base de rôles
     Utilisateur
     Rôle
     Permissions

    Au-lieu d'attribuer des permissions à un utilisateur, on les attribue à un rôle, qu'on délègue
    à un utilisateur : les permission sont gérées en fonction de la structure de l'organisation,
    indépendamment des embauches, départs ou changement de responsabilité des individus.

4.2 Permissions
     Modèle applicatif de permissions
     Vérier les permissions à chaque traitement de requête
       Routage
       Dans les traitements fonctionnels
    Module  Firewall  de Symfony

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

Poly étudiant                                                                                            6

CSC4101 2018-2019                                                                                   CM 7

5       Symfony
    Cette section présente la façon dont on peut mettre en ÷uvre les mécanismes d'authentication
    et de contrôle d'accès dans Symfony.

5.1 Flexibilité
     Symfony permet de gérer plein de modalités de l'authentication
     Choix : utiliser un module prêt à l'emploi : FOSUserBundle

5.2 Gestion des utilisateurs avec FOSUserBundle
       Classe User du Modèle (et mapping Doctrine en base)
       Dénition de règles dans le rewall Symfony
       Rôles
       Routes et templates standards :
         Login + password
         Logout
         Inscription, rappel du mot-de-passe,
    Cf. documentation FOSUserBundle

5.3 Classe User
use FOS\UserBundle\Model\User as BaseUser;
use Doctrine\ORM\Mapping as ORM;

/**
  * @ORM\Entity
  * @ORM\Table(name="fos_user")
  */
class User extends BaseUser
{
     // ...

     FOS\UserBundle\Model\User fournit déjà :
        username
        email
        password
    Sera sérialisé dans la session à la n de chaque réponse

5.4 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]

Poly étudiant                                                                                          7

CSC4101 2018-2019                                                                               CM 7

5.5    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 }

   Expressions rationnelles : "^/admin" signie tout chemin de route qui commence par /admin.
   D'autres possibilités existent (programmées).

5.6 Utilisation dans les contrôleurs
    Contrôle d'accès sur les routes :
       @Route("/comment/{postSlug}/new", name="comment_new")
       @Security("is_granted('IS_AUTHENTICATED_FULLY')")
     Encore une fois, importance des annotations
    Contrôle d'autorisation dans le code des méthodes :
       $this->denyAccessUnlessGranted('ROLE_ADMIN', null, 'Access denied!');
       Entrée interdite, à moins que. . .

5.7 Prol de l'utilisateur
    Accès aux propriétés de l'utilisateur :
       $this->getUser()

       // ...

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

5.8 Personnalisation apparence
   Gabarits Twig
{% if is_granted('ROLE_ADMIN') %}
  Delete
{% endif %}

5.9 Gestion ne
    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

Poly étudiant                                                                                      8

CSC4101 2018-2019                                                                                    CM 7

5.9.1 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)

5.10 Gestion des utilisateurs
    Via du code PHP (API de Symfony)
    Par console en ligne de commande :
      création utilisateur
         php bin/console fos:user:create testuser test@example.com p@ssword
       dénition de rôle :
         php bin/console fos:user:promote testuser ROLE_ADMIN

6 Ensuite. . .
6.1 TP n° 7
   Mise en ÷uvre de l'authentication et du contrôle d'accès

6.2 Q / R
Copyright
   Ce cours est la propriété de ses auteurs et de Télécom SudParis.
   Cependant, une partie des illustrations incluses est protégée par les droits de ses auteurs, et
   pas nécessairement librement diusable.
   En conséquence, le contenu du présent polycopié est réservé à l'utilisation pour la formation
   initiale à Télécom SudParis.
   Merci de contacter les auteurs pour tout besoin de réutilisation dans un autre contexte.

Poly étudiant                                                                                           9