Les droits d’accès dans l’application

Actuellement le canal DossierWeb est décliné pour 2 usages :

  • la partie visible par chaque étudiant sachant bien qu’un étudiant ne peut voir que son propre dossier
  • la partie visible aux enseignants et aux personnels qui peuvent consulter le dossier de tous les étudiants

Pour la partie enseignants/personnels nous faisons actuellement un double test :

  • la personne appartient-elle à un groupe uPortal précisé en configuration?
  • si non, la personne possède-t-elle un compte actif dans Apogée? Cela fonctionne si et seulement si les logins LDAP et Apogée sont identiques

Actuellement le contrôle d’accès à l’un de ces modules est fait très simplement :

  • il y a deux channels uPortal : l’une pour les étudiants et l’autre pour les enseignants
  • la channel enseignant utilise la channel étudiant en mode servant
  • la channel enseignant est réservée au profil personnel et affichera un message d’erreur si l’utilisateur n’est pas autorisé

Dans le cadre de la migration vers esup-commons, MonDossierWeb pourra être déployé en servlet ou portlet et la problématique de gestion des accès est plus compliquée car il faut empêcher tout accès aux pages réservées aux enseignants par des étudiants qui en connaitraient les URLs

A priori nous aurons une arborescence pour les pages découpées en deux sou-répertoires : ens et etu

Plusieurs solutions s’offrent à nous pour la gestion des droits d’accès aux différentes pages :

  • le mécanisme d’esup-commons mais qui implique l’utilisation des tags qui ne sont pas pour l’instant compatible avec facelets
  • l’utilisation d’acegi, module puissant mais complexe à mettre en oeuvre compte-tenu de nos besoins assez simples. Des composants JSF pour Acegi existent déjà : acegi-jsf. Acegi bénéficie toutefois d’une excellente intégration avec Spring et CAS.
  • l’utilisation d’un composant JSF onload qui s’appuie sur le mécanisme des PhaseListener qui permettent de placer des hooks sur les évenements JSF de rendu des pages et donc, par exemple, de faire des contrôles préalables à tout affichage pour vérifier que l’utilisateur a bien accès

Il est donc maintenant nécessaire d’approfondir la question et notamment :

  • parmi ces 3 possibilités, laquelle est la plus adaptée à notre contexte
  • comment tester l’appartenance d’un utilisateur à un groupe uPortal
  • comment, une fois l’utilisateur ayant été identifié par CAS, alimenter un bean qui stockera des informations sur :
    • son profil : enseignant ou étudiant
    • le code étudiant

Laisser un commentaire