Choisissez une rubrique dans la colonne de gauche ou bien

1.Présentation générale de GRR

1.1.Qu'est-ce que GRR ?

GRR est un système de Gestion et de Réservations de Ressources.

GRR est particulièrement adapté à la gestion et la réservation de salles et de matériels, mais il peut également être utilisé comme mini-agenda partagé.

Il s'agit d'une adaptation d'une application PHP/SQL sous licence GPL : MRBS (http://mrbs.sourceforge.net).

Cette adaptation est également sous licence GPL  donc libre et gratuite.

Les principales fonctionnalités de GRR sont :

• l'accès à l'outil de gestion partagée via n'importe quel navigateur web,
• l’administration de plusieurs types de ressources partagées (salles, voitures, matériels, ...),
• la gestion des réservations de ces ressources (création, modification, suppression),
• la gestion du type d'accès à une ressource ; accès restreint à certains utilisateurs ou non,
• la possibilité d’effectuer des réservations périodiques,
• la possibilité de configurer un calendrier des jours « fériés », inaccessible aux réservations,
• la possibilité de poser des réservations « sous réserve », à confirmer avant une date fixée,
• la possibilité de poser des réservations « avec modération »,
• la possibilité d'effectuer des réservations au nom d'autres utilisateurs ou de personnes extérieures
• la possibilité de définir, domaine par domaine, des champs additionnels,
• la possibilité de définir des  "jours cycle" (voir documentation),
• la gestion fine d'envoi de mails automatiques,
• la délégation à des utilisateurs, de l'administration de certains domaines,
• la délégation à des utilisateurs, de la gestion des réservations pour certaines ressources,
• la possibilité pour un gestionnaire, d'afficher une réservation comme étant « en cours d'utilisation »,
• la possibilité de rendre temporairement indisponible une ressource pour maintenance par exemple,
• la possibilité de configurer une fiche de présentation avec image pour chaque ressource,
• la visualisation du planning des réservations des ressources sous différentes formes,
• la possibilité de paramétrer le type d'accès à l'application (obligation ou non de se connecter pour accéder au site),
• la possibilité de personnalisation par domaine les paramètres d'affichage du planning des réservations (heures de début et fin de journée, plus petit bloc réservable, ... ou bien créneaux pré-définis).
• la possibilité de fixer, pour chaque ressource, un nombre maximal de jours au-delà duquel l'utilisateur ne peut pas réserver ou modifier une réservation existante.
• la possibilité de fixer, pour chaque ressource, un temps, en-deçà duquel l'utilisateur ne peut pas réserver ou modifier une réservation existante.
• La possibilité de réserver ou de libérer très rapidement des journées entières simultanément sur plusieurs ressources de plusieurs domaines et selon un calendrier.
• Compatibilité avec UTF-8.

1.2.Les utilisateurs

Les différentes catégories d’utilisateurs sont :

a) Les administrateurs

L'administrateur a accès à l’ensemble des fonctionnalités de l’application : il gère les ressources, la base de données et les autres utilisateurs. Il peut tout voir, réserver et modifier ou effacer toutes les réservations. Il a accès à l'ensemble des paramètres de configuration de GRR.

b) Les administrateurs restreints de sites (version 1.9.6)

Lorsque la fonctionnalité "multi-sites" est activée, il est possible de définir des "sites", qui sont des unités qui regroupent des domaines. Il est alors possible de définir des administrateurs de sites.
En plus de ses droits normaux, l'administrateur d'un site a la possibilité de gérer entièrement un site : création, suppression, modification d'un domaine ou d'une ressource, ajout et suppression de gestionnaires des réservations, d'administrateur de domaines, gestion des mails automatiques.

c) Les administrateurs restreints de domaines

L'administrateur de domaines est à la base un « usager » (voir plus bas) à qui l'administrateur a donné des droits supplémentaires pour administrer tel ou tel domaine.

Concernant les domaines dont ils ont la charge, les administrateurs restreints peuvent, pour le(s) domaine(s) qu'ils administrent :

• créer, modifier ou supprimer des ressources,

• dans le cas d'un domaine à accès restreint, ajouter ou supprimer des utilisateurs autorisés à avoir accès au domaine,

• gérer la liste des utilisateurs à avertir automatiquement par mail lors des réservations d'une ressources donnée,

• gérer la liste des gestionnaires pour chaque ressource du domaine (voir plus bas),

• activer ou désactiver un ou plusieurs types de réservation pour le domaine.

d) Les gestionnaires

Le gestionnaire est à la base un « usager » (voir plus bas) à qui l'administrateur a donné des droits supplémentaires pour gérer telle ou telle ressource.

Concernant les ressources dont ils ont la charge, les gestionnaires peuvent :

• supprimer ou modifier n'importe quelle réservation,

• être prévenus par mail de la réservation d'une ressource ou de la modification/suppression de la réservation (voir rubrique plus bas),

• signaler qu'une réservation est en cours d'utilisation (sur les plannings, un symbole spécifique apparaît alors dans la case de la réservation),

• rendre temporairement indisponible à la réservation une ressource (pour maintenance par exemple).

e) Les usagers

l'usager :

• peut voir les réservations dans les domaines publics, réserver et modifier ou effacer ses propres réservations,
• peut être prévenu par mail de la réservation d'une ressource ou de la modification/suppression de la réservation (voir rubrique plus bas),
• a accès à la consultation de la disponibilité ou indisponibilité des ressources des domaines publics,
• a accès au détail des réservations,
• a accès à l'outil "Recherche - Rapports - Statistiques" (selon le paramétrage dans la configuration générale) ,
• a accès à la gestion de son compte pour modifier ses paramètres personnels (mot de passe, email, affichage par défaut, ...)

Pour les domaines à accès restreint, seuls les usagers spécifiés par l'administrateur y ont accès. Les usagers autorisés y ont alors les même possibilités que dans les domaines publics.

Par défaut, un usager (ni même un gestionnaire ou un administrateur restreint de domaines) ne peut effectuer une réservation dans le passé, ni modifier ou supprimer une réservation passée. Seul l'administrateur a cette possibilité. Il est néanmoins possible de permettre pour une ressource donnée, réservation dans le passé ainsi que les modifications/suppressions de réservations passées.

f) Les usagers "gestionnaires d'utilisateurs"

Le gestionnaire d'utilisateurs, en plus des possibilités d'un usager normal peut :

• ajouter des utilisateurs ayant pour statut "usager" ou "visiteur",
• modifier un utilisateur ayant pour statut "usager" ou "visiteur", (nom, prénom, mot de passe, email, statut, etat),
• supprimer un utilisateur ayant pour statut "usager" ou "visiteur",
• importer dans GRR un fichier d'utilisateurs (format CSV)

g) Les visiteurs

Un « visiteur » peut voir les réservations dans les domaines publics (et dans les domaines à accès restreints selon la configuration) ainsi que le détail des réservations mais ne peut ni réserver, ni effacer, ni modifier une réservation. Le visiteur n'a pas accès à son compte et ne peut donc pas modifier son mot de passe. Selon le paramétrage dans la configuration générale, le visiteur a ou non accès à l'outil "Recherche - Rapports - Statistiques".

1.3.Propriétaires et bénéficiaires

Pour chaque réservation effectuée,  GRR distingue le propriétaire de la réservation (celui qui a effectué la réservation) et le bénéficiaire de  la réservation celui au nom duquel la réservation a été effectuée.

La plupart du temps (fonctionnement par défaut), le propriétaire et le bénéficiaire sont une même  personne.

Mais il est possible d'autoriser, ressource par ressource, des utilisateurs à réserver (ils sont alors propriétaires de la réservation) au nom d'autres utilisateurs (qui deviennent alors bénéficiaires de la réservation).

Délégation

L'administrateur général a toujours cette possibilité, mais il peut déléguer ce droit :

• uniquement aux administrateurs restreints du domaine,
• ou bien aux gestionnaires de la ressource (et aux administrateurs restreints du domaine),
• ou encore à tous les utilisateurs de la ressource.

Par défaut, seul l'administrateur général dispose de ce droit.

Bénéficiaires : des utilisateurs de GRR ou bien des personnes extérieures

 

Les bénéficiaires sont en général des utilisateurs enregistrés dans GRR. Mais il est également possible de réserver au nom de personnes extérieures. Dans ce cas, le créateur de la réservation dispose de deux champs supplémentaire dans l'interface de réservation :

• un champ obligatoire pour préciser les nom et prénom du bénéficiaire,
• un champ facultatif pour préciser l'adresse email du bénéficiare.

Remarques

• Dans le cas où une réservation est effectuée au nom d'une personne extérieure, celle-ci ne dispose pas de la possibilité de modifier la réservation.
• Les personnes extérieures sont des personnes ne disposant pas de compte dans GRR. Par conséquent, un utilisateur qui s'authentifie par LDAP n'est pas une personne extérieure. Mais, si un utilisateur "LDAP" ne s'est jamais connecté à GRR, il n'a pas encore de compte dans GRR et par conséquent, il n'apparaît pas dans la liste déroulante des personnes au nom desquelles on peut effectuer une réservation.

Règles de fonctionnement

• Le propriétaire d'un réservation, même s'il n'en est pas bénéficiaire, a le droit de la modifier ou de la supprimer.
• De même le bénéficiaire d'un réservation, même s'il n'en est pas le propriétaire, a le droit de la modifier ou de la supprimer.
• Lorsque qu'un utilisateur effectue une réservation au nom d'un autre utilisateur ou bien modifie ou supprime une réservation existante faite  au nom d'un autre utilisateur, un mail de notification est  automatiquement envoyé au bénéficiaire de la réservation (à condition que l'envoi de mails automatiques soit activé et que le champ email du bénéficiaire soit correctement renseigné).

1.4.Type d'accès

L'administrateur a le choix entre deux types d'accès à l'application GRR, selon le paramétrage dans la configuration générale :

• Accès libre en consultation : il n'est alors pas nécessaire de se connecter pour consulter le planning des réservations. L'internaute a les mêmes possibilités qu'un « visiteur » connecté (hormis l'outil "Recherche - Rapports - Statistiques"). Dans ce type de configuration GRR est accessible librement et vos ressources et les réservations sont alors visibles de tous.

• Accès avec authentification : il est obligatoire de se connecter pour accéder au site, même pour une simple consultation des réservations.

1.5.Liste des fonctionnalités et droits associés

Fonctionnalités	Administrateurs	Administrateur restreint de sites (module "multi-sites" activé)	Administrateur restreint de domaines	Gestionnaires de ressources	Gestionnaires d'utilisateurs	Usagers	Visiteurs
Paramétrage général, suivi des connexions, calendrier des jours fériés ...	X
Actions sur la base de données (restauration, sauvegarde, mise à jour)	X
Création, modification, suppression des utilisateurs	X				X
Création, modification, suppression des types de réservation..	X
Création, modification, suppression des domaines, des utilisateurs.	X	X (6)
Activation/désactivation d'un type de ressource	X	X (6)	X (4)
Création, modification, suppression des ressources.	X	X (6)	X (4)
Gestion des droits (mail automatique, accès aux domaines restreints, désignation des gestionnaires).	X	X (6)	X (4)
Création, modification, suppression des champs additionnels	X	X (6)	X (4)
Configuration des ressources Modération des réservations d'une ressource	X	X (6)	X (4)	X (1)
Signaler qu'une réservation est en cours d'utilisation	X	X (6)	X (4)	X (1)
Rendre temporairement indisponible une ressource	X	X (6)	X (4)	X (1)
Création des réservations	X	X	X	X	X	X
Modification, suppression des réservations	X	X	X (4)	X (2)	X (3)	X (3)
Gérer son compte	X	X	X	X	X	X
Visualisation des réservations	X	X	X	X	X	X	X
Utilisation de l'outil "Recherche - Rapports - Statistiques"	X	X	X (5)	X (5)	X (5)	X (5)	X (5)

 

(1) uniquement les ressources gérées par lui-même.

(2) uniquement ses propres réservations ou bien les réservations sur des ressources gérées par lui-même.

(3) uniquement ses propres réservations et sur des ressources disponibles.

(4) uniquement pour les domaines dont il a la charge.

(5) selon le paramétrage dans la configuration générale.

(6) uniquement pour les sites dont il a la charge.

1.6.Licence (conditions d'utilisation)

Le code de GRR est couvert par la GNU General Public License.

GRR inclue des programmes et librairies protégés par leurs licences respectives. En voici la liste ci-dessous. Ils appartiennent tous à la famille des logiciels libres et leurs licences respectives sont compatibles avec la GNU General Public License.

• fckeditor version 2.6.4 GNU General Public License - Le site : http://www.fckeditor.net/

• phpmailer version 1.73. GNU Library or Lesser General Public License (LGPL) - Le site  : http://sourceforge.net/projects/phpmailer

• tooltip-0.2.js .BSD licence,  compatible avec la GPL. - Le site : http://blog.innerewut.de/tooltip

• prototype version 1.6.0.3 (September 29, 2008). Licence MIT (compatible avec la GPL) - Le site : http://www.prototypejs.org

2.Installation de GRR

2.1.Pré-requis

Du côté serveur

• Pour fonctionner, GRR a besoin d'un serveur web/php et d'un serveur mysql.

• La version de PHP doit être supérieure ou égale à la version 4.1.0 (gestion des variables de type $_SESSION, ...)

• Pour installer GRR, vous devez disposer d'un espace FTP sur le serveur web, pour y transférer les fichiers et d'une base de données MySQL (adresse du serveur MySQL, login, mot de passe)

• Il est préférable que le serveur web autorise l'utilisation des fichiers .htaccess (protection du fichier connect.inc.php)

Du côté client (navigateur)

• GRR devrait fonctionner avec tout type de navigateurs récents (FireFox, Mozilla, Internet Explorer,Safari, ...).

• L'activation de javascript dans le navigateur est nécessaire au bon fonctionnement de GRR.

• Enfin le navigateur doit autoriser les cookies afin que lors de la connexion à GRR, un identifiant de session puisse être stocké dans le cookie. Le cookie est détruit dès que l'utilisateur se déconnecte.

2.2.Avant l'installation : configuration du fichier config.inc.php

Le fichier "config.inc.php" contient un certain nombre de paramètres qui normalement, n'ont pas besoin d'être modifiés. Le cas échéant, il faut le configurer avant d'«uploader» tous les fichiers vers le serveur web.

• $nb_year_calendar : permet de fixer la plage de choix de l'année dans le choix des dates de début et fin des réservations dans la page de configuration générale. La plage s'étend de « l'année en cours - $nb_year_calendar » à « l'année en cours + $nb_year_calendar ». Par exemple, si on fixe $nb_year_calendar = 5 et que l'on est en 2005, la plage de choix de l'année s'étendra de 2000 à 2010.

• $correct_diff_time_local_serveur : avance en nombre d'heure du serveur sur les postes clients. Ce paramètre permet de corriger une différence d'heure entre le serveur et les postes clients.
  Exemple : Grr est installé sur un serveur configuré sur le fuseau GMT+1 alors qu'il est utilisé dans un pays dont le fuseau horaire est GMT-5. Le serveur a donc six heures d'avance sur les postes clients. On indique alors : $correct_diff_time_local_serveur=6;

• Paramétrage du fuseau horaire (imposer à GRR un fuseau horaire différent de celui du serveur) :
  TZ (Time Zone) est une variable permettant de préciser dans quel fuseau horaire, GRR travaille.L'ajustement de cette variable TZ permet au programme GRR de travailler dans la zone de votre choix.la valeur à donner à TZ diffère d'un système à un autre (Windows, Linux, ...).
  
  Par exemple, sur un système Linux, si on désire retarder de 7 heures l'heure système de GRR, on aura : putenv("TZ=posix/Etc/GMT-7").
  
  Remarque : putenv() est la fonction phpqui permet de fixer la valeur d'une variable d'environnement. Cette valeur n'existe que durant la vie du script courant, et l'environnement initial sera restauré lorsque le script sera terminé.
  
  En résumé, pour activer cette fonctionnalité, décommentez dans config.inc.php la ligne putenv("TZ=posix/Etc/GMT-7"); et remplacez -7 par +n ou -n où "n" est le nombre d'heures d'avance ou de retard de GRR sur l'heure système du serveur.

• OPTION_IP_ADR : lorsque cette variable est égale à 1, une option supplémentaire est offerte pour la gestion de l'affichage des domaines par défaut :
  - Pour chaque domaine, on spécifie une adresse IP différente dans la page de configuration des domaines.
  - Si l'adresse IP de la machine cliente est identique à cette adresse, ce domaine devient le domaine par défaut. Attention, cette procédure ne fonctionne que si l'administrateur n'a pas défini un domaine par défaut dans la page de configuration générale. De même pour un utilisateur connecté, si celui-ci a défini un domaine par défaut qui lui est propre dans la page de gestion de son compte, la procédure ne fonctionnera pas.

• $correct_heure_ete_hiver : paramètre permettant de prendre en compte on non le changement d'heure été/hiver.
  Si ce paramètre prend la valeur « 1 », ou bien si ce paramètre n'est pas défini, GRR prend en compte les changements d'heure. Dans le cas contraire, GRR ne prend en compte les changements d'heure.

• Nom de la session PHP: define('SESSION_NAME', "GRR"). Le nom de session fait référence à l'identifiant de session dans les cookies. Il ne doit contenir que des caractères alpha-numériques; si possible, il doit être court et descriptif. Normalement, vous n'avez pas à modifier ce paramètre. Mais si un navigateur est amené à se connecter au cours de la même session, à deux sites GRR différents, ces deux sites GRR doivent avoir des noms de session différents. Dans ce cas, il vous faudra changer la valeur GRR par une autre valeur.

• $max_rep_entrys :  cette variable fixe le nombre maximum de réservations autorisés lors d'une réservation avec périodicité (366 par défaut).

• $unicode_encoding : positionner la valeur $unicode_encoding à 1 pour utiliser l'UTF-8 dans toutes les pages et dans la base. Dans le cas contraire, les textes stockés dans la base dépendent des différents encodage selon la langue selectionnée par l'utilisateur. Il est fortement conseillé de lire le fichier notes-utf8.txt à la racine de l'archive de GRR.

• $use_function_mysql_real_escape_string : après installation de GRR, si vous avez le message "Fatal error: Call to undefined function: mysql_real_escape_string() ...", votre version de PHP est inférieure à 4.3.0.
  En effet, la fonction mysql_real_escape_string() est disponible à partir de la version 4.3.0 de php. Vous devriez mettre à jour votre version de php. Sinon, positionnez la variable $use_function_mysql_real_escape_string à "0"

• .$use_function_html_entity_decode : après installation de GRR, si vous avez le message "Fatal error: Call to undefined function: html_entity_decode() ...",  votre version de PHP est inferieure a 4.3.0.
  En effet, la fonction html_entity_decode() est disponible a partir de la version 4.3.0 de php. Vous devriez mettre a jour votre version de php. Sinon, positionnez la variable $use_function_html_entity_decode à "0".

2.3.Avant l'installation : configuration du fichier connect.inc.php

La configuration du fichier "connect.inc.php" n'est pas obligatoire si vous optez pour une installation automatisée de la base de donnée. En effet, la procédure d'installation vous invitera alors à entrer dans un formulaire vos paramètres de connexion.

Dans le cas contraire :

• Renommer le fichier "connect.inc.php.ori" en "connect.inc.php",

• Editer le fichier "connect.inc.php" afin de le compléter les différentes valeurs suivantes :

• $dbHost : le nom du serveur qui héberge votre base de donnée mysql. Si c'est le même que celui qui héberge les fichiers php, mettre "localhost".

• $dbDb : le nom de votre base mysql.

• $dbUser : le nom de l'utilisateur mysql qui a les droits sur la base.

• $dbPass : le mot de passe de l'utilisateur mysql ci-dessus.

2.4.Installation - Etape 1 : transfert des fichiers

La première étape de l'installation consiste à transférer tous les fichiers de l'archive que vous avez téléchargée vers le serveur web/php.

Pour cela, munissez-vous des codes des paramètres de connexion au serveur et utilisez un logiciel de transfert de fichiers tel que « FileZilla ».

On pourra par exemple créer un répertoire "grr" dans le répertoire web du serveur ("htdocs" dans le cas d'Apache).

Une fois les fichiers transférés, vous devez modifier le cas échéant les droits d'accès à certainsfichiers et répertoires. Les droits d'écriture doivent être attribués

•   au répertoire "/images" (chargement d'images pour les fiches de présentation des ressources)
•   au fichier "include/connect.inc.php.ori"(dans le cas d'une installation automatisée)
•   au fichier "include/config_ldap.inc.php.ori"(dans le cas d'une configuration LDAP)

2.5.Installation - Etape 2 : création de la base Mysql

Si vous optez pour cette installation, il est nécessaire d'avoir renseigné le fichier "connect.inc.php".
Dans l'archive figure le fichier tables.my.sql à exécuter sur le serveur mysql et qui contient l'ensemble des tables mysql ainsi que les données minimales pour que ça fonctionne.

• Sur le serveur mysql :
  
  1. créez une base mysql (avec phpMyAdmin par exemple) en lui donnant un nom par exemple "grr"
  2. créez un utilisateur de cette base,
  3. n'oubliez pas de relancer le serveur.

• Connectez-vous à cette base.

• Exécutez le fichier "tables.my.sql" dans cette base (toujours avec phpMyAdmin par exemple)

3.Configuration de GRR en ligne

Une fois le système installé, la première chose à faire est de configurer GRR à l'aide de l'interface web. Pour cela :

• Connectez-vous à GRR, (nom de connexion "administrateur" et mot de passe "azerty"),
• Par sécurité, changez le mot de passe de administrateur grâce au lien "gérer mon compte" dans le bandeau en haut !
• allez dans la partie "administration" (lien dans le bandeau en haut)

Vous avez alors la possibilité d'accéder à un certain nombre de rubriques réservées aux administrateurs :

Nous allons passer en revue quelques-unes de ces rubriques :

3.1.Configuration générale

La configuration générale de GRR s'organise en cinq parties : "Contenu / Apparence", "Accès et droits", "Interactivité",  "Sécurité / Connexions" et "Activation de modules"

Contenu / Apparence

• Renseignements divers : Nom de l'établissement, adresse du site, nom et prénom du gestionnaire du site, adresse email du gestionnaire du site et adresse email du support technique.
• Dates de début et fin des réservations : pas de réservation possible en dehors de ces dates. De plus les réservations déjà effectuées en dehors de ces dates sont effacées de la base.
• Choix des paramètres d'affichage par défaut :  dans cette rubrique, on peut choisir l'affichage par défaut de la page d'accueil. Ce sont les paramètres qui s'appliqueront si l'utilisateur n'a pas lui-même choisi des paramètres d'affichage par défaut.
• Choix de l'affichage des "info-bulles" des réservations, dans les vues journées, semaine et mois.
• Choix de l'affichage du champ "description complète" de la réservation dans les vues semaine et mois.
• Comportement du navigateur lors de l'ouverture des "pages au format imprimable".
• Paramétrage de l'outil "Recherche - Rapports - Stats." (valeur par défaut de l'intervalle de temps entre la date de début de recherche et la date de fin).

Accès et droits

Interactivité

• Envoi de mails automatiques :
  L'administrateur peut activer ou désactiver l'option permettant l'envoi d'emails automatiques.
• Si cette option est activée, dans un certain nombre de cas (création d'une réservation, suppression/modification, modération, ...), GRR envoie automatiquement des mails à certains utilisateurs.
  
  Par ailleurs, dans la page de gestion des mails automatiques, toujours si cette option est activée, l'administrateur peut affecter à chaque ressource un ou plusieurs utilisateurs à prévenir par mail automatique lorsqu'une réservation est effectuée ou lorsque qu'il y a modification ou suppression de la réservation.
  
  Pour en savoir plus...
  
  Certains hébergeurs désactivent l'envoi automatique de mails depuis leurs serveurs. Dans ce cas, cette fonctionnalité sera inopérante.

• Affichage (oui ou non) des "pop-up" de confirmation après la création/modification/suppression d'une réservation.

• Affichage (oui ou non) des "pop-up" de confirmation dans les menu d'administration.

Sécurité / Connexions

• Sauvegarde de la base GRR : création d'un fichier de sauvegarde complet de la base mysql.
  Une sauvegarde automatique peut être déclenchée par l'exécution du script « admin_save_mysql.php »,
  * par exemple en programmant son exécution à l'aide d'une tâche « cron » sur un serveur Linux. avec une commande du type :
  php -f /chemin_complet_du_site_grr/admin_save_mysql.php mot_de_passe
  * ou bien en exécutant dans un navigateur l'URL du type : http://mon-site.fr/grr/admin_save_mysql.php?mdp=mot_de_passe.
• Restauration de la base GRR
  En cas de perte de donnée ou de problème sur la base GRR, cette fonction vous permet de la retrouver dans l'état antérieur lors d'une sauvegarde.

• Activation/désactivation des connexions :
  
  En désactivant les connexions, vous rendez impossible la connexion au site pour les utilisateurs, hormis les administrateurs. De plus, les utilisateurs actuellement connectés sont automatiquement déconnectés. Néanmoins, si la connexion n'est pas obligatoire pour l'accès au site en visualisation, cet accès reste possible.

• Durée d'une session : l'administrateur fixe la durée maximum d'inactivité. Cette durée indique le temps maximum d'inactivité au bout duquel un utilisateur est automatiquement déconnecté.

• Mot de passe : définition de la longueur minimale du mot de passe.

• Url de Déconnexion : Lorsqu'un utilisateur se déconnecte, après fermeture de la session, le navigateur est redirigé vers la page dont l'URL est spécifiée dans ce champ.
  Si le champ est vide, selon le paramétrage du type d'accès dans la configuration générale, l'utilisateur est dirigé soit vers la page d'accueil soit vers la page de déconnexion.

Activation de modules

• Module "FckEditor" : le module "FckEditor" permet une mise en forme "wysiwyg" (comme un traitement de texte). Si le module est activé, vous avez accès à cet outil en administration, pour le remplissage de certains champs tels que la fiche de description d'une ressource.

• Activer les fonctionnalités jours cycle : la configuration par « jours cycle » offre la possibilité de réorganiser le calendrier de GRR pour qu'il corresponde non pas aux jours du calendrier « normal », mais à des « jours cycle ».

• Activer la fonctionnalité "multisite" (version 1.9.6) : lorsque la fonctionnalité "multi-sites" est activée, il est possible de définir des "sites", qui sont des unités qui regroupent des domaines. Ces sites peuvent par exemple correspondre à des localisations géographiques de plusieurs domaines.

3.2.Types de réservation

Dans cette partie, sont précisées les différents types de réservation. Il est possible de spécifier jusqu'à 100 types (de A à Z, puis AA, jusqu'à AZ, etc...). Chaque type a une couleur et un nom ainsi qu'un ordre d'affichage dans les différents plannings.

Lorsqu'un type est crée, celui-ci est actif pour tous les domaines. Ensuite, pour chaque domaine, il est possible d'activer ou de désactiver un ou plusieurs types de réservation. Il est également possible de spécifier un type par défaut lors d'une nouvelle réservation.

3.3.Calendrier hors réservation

Il est possible de spécifier un calendrier de journées hors réservation : les journées cochées dans cette interface  correspondent à des journées pendant lesquelles il n'est pas possible de réserver.
En ce qui concerne les réservations avec périodicité, ces journées sont ignorées lors de la validation de la réservation.

Remarque : lors de la configuration de ce calendrier, si des réservations ont déjà été enregistrées sur les journées que l'administrateur coche, celles-ci sont automatiquement et irrémédiablement supprimées (les personnes concernées par les suppressions ne sont pas prévenues par email).

3.4.Gestion des domaines (ajout/modification)

Nom : le nom du domaine.
Ordre d'affichage : dans les différentes interfaces, les domaines sont affichés selon l'ordre d'affichage.
Accès restreint :

• Si vous cochez cette case, seules les usagers spécifiés par l'administrateur (dans une autre rubrique) auront accès à ce domaine avec les même possibilités que dans les domaines publics.
• Si la case n'est pas cochée, le domaine sera accessible à tous les utilisateurs.

Configuration de l'affichage des plannings des ressources de ce domaine :

Début de la semaine : sur les plannings hebdomadaires, les semaines commencent par cette journée.
Jours à afficher sur les différents plannings : seuls les jours cochés apparaissent sur les différents plannings.

Les créneaux de réservation peuvent être soient basés sur le temps, soient basés sur des intitulés pré-définis.

Cas où les créneaux de réservation sont basés sur le temps.

• Heure de début de journée : choisir une valeur entière entre 0 et 23

• Heure de fin de journée : choisir une valeur entière entre 0 et 23, supérieure à l'heure de début de journée.

• Nombre de minutes à ajouter à l'heure de fin de journée pour avoir la fin réelle d'une journée : voir exemples ci-dessous

• Plus petit bloc réservable, en secondes (1800 secondes = 1/2 heure) : voir exemples ci-dessous

• Durée par défaut d'une réservation

Exemple 1

Pour mettre en place des réservations entre 8 h et 19 h, avec un pas de 15 minutes (900 secondes), la configuration doit être la suivante :

• Heure de début de journée : 8
• Heure de fin de journée : 18
• Nombre de minutes à ajouter à l'heure de fin de journée pour avoir la fin réelle d'une journée : 45
• Plus petit bloc réservable, en secondes (1800 secondes = 1/2 heure) : 900

Exemple 2

Pour mettre en place deux créneaux de réservations [8 h - 14 h] et [14 h - 20 h], soit des bloc de réservation de 6 h (21600 secondes), la configuration doit être la suivante :

• Heure de début de journée : 8
• Heure de fin de journée : 14
• Nombre de minutes à ajouter à l'heure de fin de journée pour avoir la fin réelle d'une journée : 0
• Plus petit bloc réservable, en secondes (1800 secondes = 1/2 heure) : 21600

Cas où les créneaux de réservation sont basés sur des intitulés pré-définis

Il ne s'agit pas du mode normal de fonctionnement de GRR. N'utilisez ce mode uniquement dans le cas où le mode précédent ne correspond pas à votre cas de figure, c'est-à-dire lorsque vos créneaux de réservation sont de taille inégales et ne peuvent pas se subdiviser en blocs de tailles égales ou bien lorsque les créneaux ne couvrent pas uniformément la plage de début à la fin.
Exemple :
Créneau 1 : 8h10 - 9h00
Créneau 2 : 9h00 - 9h50
Créneau 3 : 10h05 - 10h55
Créneau 4 : 10h55 - 11h45
Créneau 5 : 11h45 - 12h35
Créneau 7 : 12h35 - 13h00
Créneau 8 : 13h00 - 13h50
Créneau 9 : 13h50 - 14h40
Créneau 10 : 14h40 - 15h30
Créneau 11 : 15h45 - 16h35
Créneau 12 : 16h35 - 17h25
Créneau 13 : 17h25 - 18h30
Créneau 14 : 18h30 - 19h30

Durée maximale d'une réservation pour une ressource donnée

Il est possible de définir une durée maximale pour une réservation donnée. Dans ce cas, une réservation ne pourra pas excéder une durée limite, suivant les propriétés suivantes :

• Durée définie en nombre de minutes dans le cas où les créneaux sont basés sur le temps,
• Durée exprimée en nombre de jours dans le cas où les créneaux sont basés sur des intitulés pré-définis. 

Cette limitation ne touche pas les administrateurs et gestionnaires des ressources du domaine.

Remarque : actuellement, les journées hors réservation sont prises en compte dans le calcul de la longueur d’une réservation.

Exemple : supposons que la limite soit fixée à trois jours et que le week-end soit hors réservation. Une réservation débutant le vendredi matin et se terminant le lundi soir ne sera pas acceptée car GRR considère à tort que la réservation dure 4 jours. Il s'agit d'un là bug.

3.5.Gestion des ressources - Généralités

Pour chaque ressource :

on peut définir un nombre maximum de réservations par utilisateur, pour une ressource donnée. Par défaut (valeur -1) il n'y a pas de restriction. Attention : ces restrictions ne s'appliquent pas aux administrateurs généraux ainsi qu'aux administrateurs restreints du domaine ou aux gestionnaires chargés d'administrer la ressource. Vous pouvez également définir, dans la configuration générale de GRR, un nombre maximal de réservation qui s'applique toutes ressources confondues.

Possibilité de définir un nombre maximal de jours au-delà duquel l'utilisateur ne peut pas réserver ou modifier une réservation. Exemple : une valeur égale à 30 signifie qu'un utilisateur ne peut réserver une ressource que 30 jours à l'avance au maximum. Cette limitation ne touche pas les gestionnaires de la ressources ainsi que les administrateurs du domaine.

Possibilité de définir un temps en minutes en-deçà duquel l'utilisateur ne peut pas réserver ou modifier une réservation (0 si pas de restriction).
Exemple : une valeur égale à 60 signifie qu'un utilisateur ne peut pas réserver une ressource ou modifier une réservation moins de 60 minutes avant le début de la réservation.
Cette limitation ne touche pas les gestionnaires de la ressources ainsi que les administrateurs du domaine.

Possibilité (case à cocher) de permettre ou non les réservation dans le passé ainsi que les modifications et suppressions de réservations passées.
Si la case n'est pas cochée, un usager (ni même un gestionnaire ou un administrateur restreint de domaines) ne peut effectuer une réservation dans le passé, ni modifier ou supprimer une réservation passée. Seul l'administrateur général a cette possibilité.

L'administrateur et le(s) gestionnaire(s) désigné(s) ont la possibilité de déclarer la ressource « temporairement indisponible ». Ceci est alors clairement signalé sur les plannings de réservation (« jour » et « semaine ») et a pour effet de rendre impossible toute nouvelle réservation et toute modification de réservations existantes (sauf pour l'administrateur et les gestionnaires de la ressource).

L'administrateur et le(s) gestionnaire(s) désigné(s) peuvent choisir de rendre visible ou non la fiche de présentation d'une ressource. Pour cette fiche, ils disposent d'un champ permettant une description complète de la ressource. Ce champ dispose d'une barre d'outils de mise en forme utilisant l'application FckEditor. Il est possible de désactiver cette fonctionnalité dans la page de configuration générale de GRR. Le répertoire "fckeditor" et tout ce qu'il contient n'est alors pas nécessaire au bon fonctionnement de GRR).

On peut également choisir une image pour la ressource qui sera alors visible dans la fiche de présentation.

Dans la page de modification des paramètres d'une ressource, l'administrateur a la possibilité d'activer la fonction « Poser des réservations sous réserve ». Dans le cas, la personne effectuant une réservation a la possibilité de remplir un champ supplémentaire : « Réservation à confirmer au plus tard le ... ». Si l'utilisateur ne confirme pas sa réservation avant la date indiquée, la réservation est automatiquement supprimée et un mail automatique est envoyé aux personnes concernées.

3.6.Champs additionnels

Dans cette partie, vous avez la possibilité de définir, domaine par domaine, des champs additionnels de votre choix et qui apparaîtront dans les formulaires de saisie des réservations comme autant de champs supplémentaires.

Il est possible de définir trois types de champs : « text » (une seule ligne), « textarea » (champ multi-lignes), ou bien « liste ».

Il est également possible de :

• définir si le remplissage d'un champ additionnel est  obligatoire ou non,
• définir si le champ apparaît ou non dans les différents plannings (journée, semaine, mois),
• définir si le champ apparaît ou non dans les mails automatiques,
• définir si le champ est confidentiel (visible uniquement dans la fiche de réservation et seulement par le bénéficiaire de la réservation et par les administrateurs du domaine).

Cas particulier des listes

Dans le cas d'une liste, l'administrateur doit spécifier dans un champ spécifique la liste des choix possibles sous la forme d'une seule chaîne de caractères comportant les différents choix séparés par le caractère |.

Exemple : choix1|choix2|choix3 permet de définir une liste de trois items (choix1, choix2 et choix3).

Attention, une fois GRR en production, l'administrateur ne devrait pas être amené à changer la formulation d'un item de la liste car toutes les réservations déjà enregistrées avec cet items perdraient alors cette informations. Même chose si l'administrateur supprime un item de la liste.

3.7.Gestion des utilisateurs

La page [Administration]->[Utilisateurs] permet de gérer les utilisateurs de GRR.

Utilisateurs autorisés à modifier leur nom, prénom et email
L'administrateur choisit quels utilisateurs ont le droits de modifier leurs informations personnelles (nom, prénom, email). Il y a trois niveaux possibles :

• Tous
• Tous (sauf visiteurs)
• Seulement les administrateurs 

Remarques :

• Dans le cas où GRR est intégré dans un environnement LCS, ce paramètre n'a aucun effet sur les utilisateurs authentifié par LCS qui dans tous les cas, ne peuvent pas modifier leurs informations personnelles.
• Dans le cas où GRR est intégré dans un SSO (autre que LCS), ou que GRR est interfacé avec un annuaire LDAP, il arrive que des utilisateurs soient importés dans la base de GRR avec des données manquantes ou erronées, notamment les noms et prénoms. Si les utilisateurs sont autorisés à modifier leurs informations personnelles et qu'à l'ouverture d'une session, GRR constate que le champ nom ou le champ prénom est vide, alors GRR redirigera automatiquement l'utilisateur vers la page "gérer mon compte" afin qu'il renseigne les champs vides.

Utilisateurs autorisés à modifier leur mot de passe 
L'administrateur choisit quels utilisateurs ont le droits de modifier leur mot de passe. Il y a trois niveaux possibles :

• Tous
• Tous (sauf visiteurs)
• Seulement les administrateurs 

Remarques :

• Dans le cas où GRR est intégré dans un SSO, ou que GRR est interfacé avec un annuaire LDAP, ce paramètre est sans effet sur les utilisateurs "externes", c'est-à-dire non locaux, car dans ce cas, le mot de passe n'est pas stocké dans GRR et ne peut pas être modifié dans GRR.

tableau général
Le tableau général permet de visualiser d'un seul coup d'oeil l'ensemble des utilisateurs, de leur statut et des éventuels privilèges.

Privilèges :
La colonne « privilèges » affiche pour chaque utilisateur, jusqu'à six lettres A, S, G, U, E et R :

• S : l'utilisateur administrateur d'un ou plusieurs sites (version 1.9.6),
• A : l'utilisateur administrateur d'un ou plusieurs domaines,
• G : l'utilisateur est gestionnaire d'une ou plusieurs ressources,
• U : l'utilisateur est gestionnaire d'utilisateurs,
• E : l'utilisateur est automatiquement prévenu par mail pour une ou plusieurs ressources,
• R : l'utilisateur dispose d'un accès à un ou plusieurs domaines à accès restreint.

La présence de telle ou telle lettre signale que l'utilisateur dispose de certains privilèges. En cliquant sur le lien à gauche des nom et prénom de l'utilisateur, on a alors tous les détails liés à ces privilèges.

Statut :
Quatre statuts possibles (cliquez ici pour en savoir plus) :

• visiteur
• usager
• administrateur
• gestionnaire d'utilisateurs

Il est possible de modifier le statut d'un utilisateur en cliquant sur le lien à gauche des nom et prénom de l'utilisateur.

Authentification :
La colonne « authentification » affiche le type d'utilisateur : local ou ext. Voir aussi Authentification et ldap.

Suppression :
La suppression d'un utilisateur est définitive et irréversible. L'utilisateur est alors effacé de la base mais pas les réservations effectuées par celui-ci.

Mot de passe :
Les mots de passe sont stockés cryptés (MD5) donc pas de possibilité de les voir en clair, une fois qu'il sont définis. En cas de perte d'un mot de passe d'un utilisateur l'administrateur peut évidemment écraser l'ancien par un nouveau : en cliquant sur le lien des nom et prénom de l'utilisateur, il est possible de modifier le mot de passe d'un utilisateur.

Utilisateurs actifs/inactifs
Lorsqu'un utilisateur est ajouté à la base, il est actif par défaut. Par la suite, l'administrateur peut rendre inactif un utilisateur. Un utilisateur inactif reste présent dans la base mais ne peut pas se connecter à GRR. Dès qu'il est à nouveau actif, l'utilisateur peut à nouveau se connecter et retrouve le cas échéant tous ses privilèges.

3.8.Accès aux domaines restreints

Vous avez la possibilité de définir des domaines à accès restreint : [Administration] -> [Domaines et ressources] , puis cliquer sur l'icone de modification du domaine.
Par défaut, aucun utilisateur n'a accès à ces domaines (hormis les administrateurs).

L'administrateur du domaine doit explicitement désigné les personnes autorisées à accéder aux ressources de ces domaines ([Administration] -> [Accès aux domaines restreints]).

Remarque : les domaines à accès restreints peuvent notamment servir à rendre visible une ressource uniquement pour certains utilisateurs.

3.9.Gestion des ressources

Parmi les différentes catégories d'utilisateurs, il y a le gestionnaire de ressource. Par défaut, un simple utilisateur peut modifier ou effacer uniquement ses propres réservations. En revanche, s'il devient gestionnaire d'une ressource, il peut alors modifier ou effacer n'importe quelle réservation de cette ressource. Il a de plus de nombreux droits supplémentaires lui permettant de gérer cette ressource.

Voir aussi :

• Les utilisateurs

• Liste des fonctionnalités et droits associés

3.10.Nombre max. de réservations par utilisateur

Astuce : Comment rendre visible une ressource pour tous les utilisateurs, mais « réservable » par un nombre restreint de personnes ?

• Créer la ressource, et affecter, pour cette ressource, la valeur 0 au champ « Nombre max de réservations par utilisateur ». De cette façon, plus personne ne peut réserver.
• Ensuite, affecter aux utilisateurs de son choix, le droit de gérer la ressource. Comme les gestionnaires de ressources ne sont pas touchés par la limite de réservation, il pourront réserver cette ressource. Cependant, en tant que gestionnaire de cette ressource, chacun aura évidemment le droit d'éditer, supprimer ou créer n'importe quelle réservation.

3.11.Méthode d'exécution automatique de tâches

L'activation de certaines fonctionnalités de GRR nécessite la possibilité de mettre en place l'exécution automatiques de tâches.

C'est le cas par exemple lors de la suppression automatique de certaines réservations dans le cas des « réservations sous réserve », ou encore lors de l'envoi d'une notification de retard en cas de non restitution d'une ressource.

Pour effectuer ces tâches automatiques, rendez-vous dans Administration -> Configuration générale -> Interactivité.

Il y a deux configurations possibles, chacune ayant ses inconvénients et ses avantages.

La tâche  automatique est déclenchée une fois par jour lors de la connexion du premier utilisateur

La tâche automatique est réalisée une fois par jour, lorsqu'un utilisateur se connecte : chaque jour, lors de la première connexion, la procédure de vérification des tâches à effectuer est lancée. C'est donc la connexion du premier utilisateur qui déclenche l'exécution du script.

• Avantage : simplicité de mise en oeuvre.
• Inconvénient : vérification aléatoire (pas de vérification à heure fixe, voire pas de vérification certains jours si personne ne se connecte).

La tâche automatique est déclenchée par l'exécution du script « verif_auto_grr.php »

• Avantage : vérification systématique à heure fixe et envoi des mails à heure fixe, chaque jour.
• Inconvénient : difficulté de mise en oeuvre.

ATTENTION : dans ce cas, il faut avoir la possibilité de programmer l'exécution automatique et périodique du script verif_auto_grr.php. Sur un serveur Linux, par exemple, le script verif_auto_grr.php peut être programmé en tâche « cron » avec une commande du type :
php -f /chemin_complet_du_site_grr/verif_auto_grr.php mot_de_passe
La périodicité conseillée est de 1 jour, en début de journée avant les premières connexions.


Si GRR est installé sur un serveur mutualisé, l'accès aux tâches « cron » est exclue. La solution consiste alors à faire appel à une serveur conçu pour rendre ce genre de service. Il en existe plusieurs sur Internet. Parmi les service gratuits, citons :
htttp://webcron.org
http://cronjob4you.at
http://cronjob.de
Certains hébergeurs offrent également ce service à leurs clients.

Le principe est le suivant :
1) Inscription en ligne sur le site afin d'obtenir un compte avec login et mot de passe.
2) A l'aide du compte, créer des tâches en fournissant l'adresse du script à exécuter (dans notre cas, quelque chose du genre http://mon-site.fr/grr/verif_auto_grr.php?mdp=mot-de_passe), la périodicité et l'heure d'exécution du script.

Remarque : l'exécution du script verif_auto_grr.php requiert un mot de passe.
Le mot de passe  est défini dans la même page de configuration que le paramètre précédent.

3.12.Administration des sites

Lorsque le module "multi-sites" est activé (version 1.9.6), il est possible de définir des  administrateurs restreints de sites  habilités à administrer tel ou tel site.

Les sites sont des unités qui regroupent des domaines. Concrètement, il peuvent correspondre à des localisations géographiques de domaines.

Les administrateurs restreints de sites disposent, pour le ou les sites dont il a la charge, des même droits que l'administrateur général : création, suppression, modification de domaines, de ressources dans les domaines, ajout et suppression de gestionnaires des réservations, gestion des mails automatiques, etc...

3.13.Administration des domaines

Parmi les différentes catégories d'utilisateurs, il y a les administrateurs restreints de domaines. L'administrateur général de GRR peut désigner des personnes habilitées à administrer tel ou tel domaine. ces administrateurs restreints disposent, pour le ou les domaines dont il a la charge, des même droits que l'administrateur général : création, suppression, modification d'une ressource, ajout et suppression de gestionnaires des réservations, gestion des mails automatiques, etc...

Voir aussi :

• Les utilisateurs

• Liste des fonctionnalités et droits associés

4.Utilisation de GRR

4.1.Accéder à GRR

L'accès au logiciel se fait à partir d'un simple navigateur Internet (FireFox, Mozilla, Internet Explorer, Safari, ...). Selon la configuration du serveur, l'accès sera possible uniquement en Intranet ou bien  de l'Internet, à partir de n'importe quel poste connecté à Internet, en tapant l'adresse qui convient du type "http://votre.domaine.fr/dossierGRR/" dans la barre d'adresse du navigateur.

4.2.Consulter les plannings de réservation

Selon la configuration choisie par l'administrateur de GRR, la consultation des plannings est possible avec ou sans un identifiant et un mot de passe.
L'utilisateur a le choix entre plusieurs interfaces de visualisation.

L’utilisateur peut

• sélectionner le jour de la réservation dans un calendrier ou à l'aide d'un sélecteur de dates,
• choisir le domaine et la ressource du domaine à afficher,
• choisir le mode d'affichage des réservations (affichage « jour », « semaine », « mois »).

En cliquant sur une réservation dans le planning, l'utilisateur peut visualiser les détails de la réservation.

4.3.Réserver une ressource

Pour effectuer une réservation, il est nécessaire d'être connecté, quelle que soit la configuration de GRR.

Pour réserver une ressource sur une plage horaire donnée, l'utilisateur choisit le planning (vue "jour", "semaine" ou "mois") et la ressource à réserver. Puis il clique, dans le planning, sur la petite croix verte de la case qui correspond au début de la réservation. Une fiche de réservation apparaît alors, que l'utilisateur doit compléter avant de valider.

Remarque :
De façon générale, les réservations sont effectuées au nom de la personne connectée. Par défaut, hormis les administrateurs, personne de peut réserver au nom d'une autre personne. Mais il est possible de spécifier pour une ressource donnée, quels types d'utilisateurs ont le droit de faire des réservations au nom d'autres utilisateurs ("Administration" -> "Domaines et ressources" -> choix du domaine, puis propriétés de la ressource).

Voir aussi la rubrique "Propriétaires et bénéficiaires"

4.4.Modifier ou supprimer une réservation

Comme pour la réservation, il est nécessaire de s'identifier pour modifier ou supprimer une réservation.
Les personnes habilitées à supprimer ou modifier une réservation sont :

• le propriétaire de la réservation lui-même, à condition que la réservation ne soit pas passée,
• le gestionnaire de la ressource,
• l'administrateur général de GRR ou l'administrateur restreint du domaine concerné.

L'utilisateur clique sur la réservation à modifier ou supprimer puis, dans la nouvelle page qui s'ouvre, il clique sur le lien correspondant à l'action qu'il désire (suppression ou modification).

4.5.Poser des réservations sous réserve

Dans la page de modification des paramètres d'une ressource, l'administrateur a la possibilité d'activer la fonction « Poser des réservations sous réserve ».

• Lorsque la valeur est à zéro, la fonction n'est pas active. Une valeur différente de 0 permet d'activer cette fonctionnalité.

• Si cette valeur est positive, elle désigne alors le nombre maximal de jours dont dispose le réservant pour confirmer une réservation à compter de la date à laquelle la réservation a été effectuée.
  Quand cette fonction est activée, la personne effectuant une réservation a la possibilité, dans le formulaire de réservation, de remplir un champ supplémentaire : « Réservation à confirmer au plus tard le ... ».

• Si la valeur est négative (uniquement à partir de la version GRR198) : appelons alors N cette valeur. Le réservant doit confirmer sa réservation au moins (-N) jours avant la date de réservation.

Si l'utilisateur ne confirme pas sa réservation avant la date limite, la réservation est automatiquement supprimée et un mail automatique est envoyé aux personnes concernées.

il est possible de configurer dans les paramètres de configuration générale, la méthode suppression automatique utilisée.

4.6.Les périodicités (réservations qui se répètent)

Comment créer une réservation qui se répète ?

Après avoir cliqué sur l'heure désirée, l'écran de réservation s'affiche. En cliquant sur le lien en bas de la page, vous ouvrez les options de périodicité.
Choisissez le type de Périodicité approprié. La ressource sera réservée à la même heure, jusqu'à la date de fin de Périodicité, et seulement pour les jours spécifiés par le type de Périodicité.

• Le type "chaque jour" crée une réservation chaque jour.
• Le type "chaque semaine" répète la réservation pour les jours de la semaine que vous avez coché sur la ligne Jour.
  Par exemple, pour une périodicité hebdomadaire programmée pour chaque lundi, jeudi et vendredi, cochez ces jours sur la ligne Jour. Si vous ne cochez pas de jours, la périodicité aura lieu chaque semaine le même jour que celui initialement choisi.
• Le type "chaque mois à la même date" crée une périodicité le même jour chaque mois, par exemple le 15 de chaque mois.
• Le type "chaque année, même date" crée une périodicité le même jour du même mois, chaque année, par exemple chaque 15 mars.
• Le type "chaque mois, même jour semaine" crée une périodicité un jour par mois, le même jour de la semaine et avec la même position ordinale de la semaine dans le mois. Utilisez ce type pour créer des périodicité du type le premier lundi, le second jeudi ou le quatrième vendredi de chaque mois par exemple. N'utilisez pas ce type pour des réservations après le 28ème jour du mois.
• Enfin les types "une semaine sur 2", "une semaine sur 3", ... sont identiques au type type "chaque semaine" mais permettent de spécifier un intervalle de semaines, par exemple tous les mardi et jeudi toutes les 3 semaines.

Comment fonctionnent les périodicités ?

Prenons un exemple :

J'effectue une réservation "A1" avec périodicité. Supposons que cette périodicité entraîne la création de n créneaux de réservation. Que se passe-t-il au niveau de l'application ?

1. GRR génère les réservation "A1", "A2", .... "An" (correspondant à autant d'entrées dans une table de la base de données nommée grr_entry),
2. GRR génère une entrée supplémentaire dans une table spéciale grr_repeat qui mémorise les informations liées à la périodicité,
3. enfin, pour chaque réservation de la table grr_entry, un champ mémorise sous forme d'un identifiant, la périodicité à laquelle la réservation est rattachée.

Que se passe-t-il si je modifie une des réservations A1, A2, ... ?

L'entrée correspondante dans la table grr_entry est modifiée avec les nouvelles informations. C'est tout ! Cela signifie qu'il n'y a plus concordance entre cette réservation et les informations de périodicité. De même, je peux supprimer la réservation "A2". Il restera alors dans la table grr_entry, les réservations "A1", "A3", .... "An".

Que se passe-t-il alors si je modifie la périodicité ?

1. Toutes les réservations dans la table grr_entry sont mises à jour avec les nouvelles informations,
2. la périodicité dans la table grr_repeat est également mise à jour.

Il y a donc à nouveau concordance entre les informations individuelles de la table grr_entry et les informations de périodicité. Ainsi, si une réservation, par exemple "A2", avait auparavant été supprimée, elle est alors réinsérée dans la table.

Que se passe-t-il alors si je supprime la périodicité ?

1. GRR supprime l'information de périodicité dans la table grr_repeat,
2. pour chaque réservation de la table grr_entry, le champ qui mémorisait la périodicité à laquelle la réservation était rattachée, est vidé.

Les réservations "A1", "A2", .... "An" sont devenues complètement indépendantes les unes des autres.

4.7.Signaler qu'une ressource est empruntée

Dans la page de renseignement d'une réservation d'une ressource, une possibilité supplémentaire est offerte aux gestionnaires de cette ressource : en cochant une case, il peuvent signaler qu'une ressource est empruntée. une petite image (panneau représentant une main sur un fond rouge) apparaît alors dans les plannings de visualisation (« jour » et « semaine ») dans la case correspondante à la réservation.

Concrètement, le gestionnaire de la ressource a le choix entre trois possibilités :

1. La ressource a été restituée. (Sélectionner également cette option si vous n'utilisez pas cette fonctionnalité) ;
2. Signaler que la ressource est empruntée.
3. Signaler que la ressource est empruntée et envoyer un mail notifiant le retard  (nécessite que la fonction d'envoi automatique de mail soit activée).

En cochant la 2ème ou la 3ème option, le gestionnaire signale que la ressource est empruntée et n'est donc pas restituée. Lorsque la ressource a bien été restituée, le gestionnaire ne doit pas oublier de sélectionner l'option n° 1 ci-dessous.

Il est également possible, en cochant une case, d'envoyer immédiatement un mail de notification de retard.

Remarque : pour une ressource donnée, une seule réservation peut être signalée "empruntée".

Dans le cas où l'option n° 3 a été sélectionnée, un email notifiant le retard est envoyé quotidiennement à l'utilisateur ayant réservé la ressource et ceci dès le lendemain de la fin de réservation.
Un email est également envoyé aux gestionnaires de la ressource, ou  à défaut, aux administrateurs de la ressource (ou en dernier recours aux administrateurs généraux).

Pour mettre fin à l'envoi des email, un gestionnaire de la ressource ou un administrateur doit changer le statut de la réservation en sélectionnant l'option n°1 ( "La ressource a été restituée") dans la page de visualisation de la ressource.

4.8.Mise en forme du texte

Par sécurité, depuis la version 195, les balises HTML ne sont plus autorisées dans les champs "brève description", "description complète" et dans les champs additionnels.

En revanche, depuis la version 196, il est possible d'utiliser le BBcode pour mettre en forme le texte dans ces champs.

Le BBcode est une simplification du langage HTML dans lequel les balises sont délimitées par les crochets [ et ].
Voici la liste des balises BBcode autorisées dans GRR :

Fonction	Syntaxe
Texte en gras	[b]Texte[/b]
Texte en italique	[i]Texte[/i]
Texte souligné	[u]Texte[/u]
Texte barré	[s]Texte[/s]
Texte colorié (en rouge)	[color=red]Texte[/color]
Lien hypertexte (sauf dans le champ "brève description")	[url]URL du lien[/url] [url=URL du lien]Titre du lien[/url]
Image (sauf dans le champ "brève description")	[img]URL de l'image[/img]
Adresse email	[email]adresse email[/email] [email=adresse email] Nom prenom[/email]
Taille des caractères	[size=taille] Texte [/size]
Barre horizontale	[/] ou [hr]
Alignement centré	[center] Texte [/center]
Alignement à droite	[right] Texte [/right]
Alignement justifié	[justify] Texte [/justify]

5.Outils divers

5.1.Mails automatiques

Dans le panneau "interactivité" de la configuration générale, l'administrateur peut activer ou désactiver l'option permettant l'envoi d'emails automatiques. En effet, dans un certain nombre de cas (création d'une réservation, suppression/modification, modération, ...), GRR peut envoyer automatiquement des mails à certains utilisateurs.

Cas général

Un email est envoyé au bénéficiaire de la réservation lorsque :

• un autre utilisateur (ayant les droits requis) créée, modifie ou supprime une réservation au nom du bénéficiaire.
• GRR supprime automatiquement une réservation du bénéficiaire (cas des réservation "sous réserve")

Cas des réservations de ressources avec modération

• Lorsqu'un utilisateur effectue une demande de réservation d'un ressource modérée :

1. un mail est envoyé à l'utilisateur pour l'avertir que sa demande est en attente de modération,
2. un mail est également envoyé aux gestionnaires responsables de la ressource, ou à  défaut aux administrateurs de la ressource (ou en dernier recours aux administrateurs généraux) afin d'avertir qu'une demande est en attente de modération.

• Lorsqu'un utilisateur (ayant les droits requis) modère une réservation, un mail est envoyé au bénéficiaire de la réservation pour lui notifier la décision.

Notification d'un retard dans la restitution d'une ressource.

• Si une ressource n’a pas été rendue dans les délais, le gestionnaire peut signaler la ressource comme étant "non restituée", ce qui a pour effet l'envoi automatique d'un mail dès le lendemain afin de notifier le retard au bénéficiaire de la réservation.
• Un email est également envoyé aux gestionnaires de la ressource, ou à défaut, aux administrateurs de la ressource (ou en dernier recours aux administrateurs généraux)

Et des utilisateurs systématiquement avertis

Par ailleurs, certains utilisateurs désignés par l'administrateur peuvent également être prévenus par email pour chaque opération ci-dessus. Pour chaque ressource l'administrateur peut désigner un ou plusieurs utilisateurs à prévenir. La configuration des utilisateurs à prévenir par mail s'effectue dans : [Administration] -> [Mails automatiques].

5.2.Suivi des connexions

L'outil de suivi des connexions permet de :

• connaître les utilisateurs actuellement connectés,
  (Cela peut correspondre à des connexions closes, pour laquelle l'utilisateur ne s'est pas déconnecté correctement et qui ne sont pas encore marquées comme closes).
• connaître, grâce à un journal des connexions, les connexions passées et en cours (nom de login, heures et dates de début et fin de session, adresse IP, navigateur et provenance),
• nettoyer régulièrement le journal.

Concernant le journal des connexions :
- Les dates apparaissant en rouge marquent les utilisateurs déconnectés automatiquement après un trop long délai d'inactivité.
- Les lignes apparaissant en vert marquent les utilisateurs actuellement connectés (cela peut correspondre à une connexion actuellement close mais pour laquelle l'utilisateur ne s'est pas déconnecté correctement).
- Les lignes en noir signalent une session close normalement.

Remarque : il est possible à tout moment de  désactiver les connexions ([Administration] -> [Configuration générale]). En désactivant les connexions, vous rendez impossible la connexion au site pour les utilisateurs, hormis les administrateurs. De plus, les utilisateurs actuellement connectés sont automatiquement déconnectés. Néanmoins, si la connexion n'est pas obligatoire pour l'accès au site en visualisation, cet accès reste possible.

5.3.Modération des réservations

L'administrateur d'un domaine ou le gestionnaire d'une ressource peut décider de modérer les réservations d'une ressource dont il a la charge. L'activation de cette fonctionnalité se fait en cochant une case dans la page de configuration de la ressource. Ce qui suit explique le fonctionnement de la modération lorsque cette option est activée :

1) Un utilisateur fait une demande de réservation en remplissant normalement les différents champs du formulaire de réservation.

2) Une fois la demande enregistrée, le ou les gestionnaires responsables de la ressource, ou à défaut, le ou les administrateurs de la ressource (ou en dernier recours les administrateurs généraux) reçoivent un mail automatique leur indiquant qu'il y a une réservation à modérer.

Le demandeur reçoit également un mail lui rappelant sa demande et le fait que celle-ci est en attente de modération.

Remarques :

• Aucune autre demande n'est possible pour la même ressource sur le même créneau tant que la modération n'a pas été faite.
• La modération ne concerne que les utilisateurs qui ne sont pas administrateurs du domaine ou gestionnaires de la ressource.

Dans le mail envoyé aux gestionnaires de la ressource, un lien pointe vers la page de validation de GRR leur permettant de valider rapidement. Sur cette page, le gestionnaire choisit d'accepter la réservation ou bien de la refuser. Le refus entraîne la suppression de la réservation.

Dans le cas de plusieurs réservations liées par une périodicité, le gestionnaire peut accepter ou refuser en bloc l'ensemble des réservations qui n'ont pas encore été modérées individuellement.

Remarque : lorsque le gestionnaire refuse en bloc un ensemble de réservations, cela entraîne automatiquement la suppression des informations de périodicité pour les réservations qui auraient éventuellement déjà été validées individuellement.

L'interface de modération contient une zone de saisie texte facultative dans laquelle le gestionnaire peut motiver sa décision.

Lorsque le gestionnaire valide le formulaire de modération, une sauvegarde des informations liées à la réservation est effectuée dans une table prévue à cet effet. Dans cette même table sont enregistrées le motif de la décision ainsi que l'identifiant de l'utilisateur ayant procédé à la modération.

Une fois que le gestionnaire a validé, le demandeur reçoit par email la décision de modération ainsi qu'un rappel de la demande.

5.5.Réservation en blocs

cette procédure vous permet de réserver ou de libérer très rapidement des créneaux horaires simultanément sur plusieurs ressources de plusieurs domaines et selon un calendrier.

Exemple : Vous pouvez ainsi bloquer à l'année certains jours tels que les week-end, les vacances, les jours fériés ...

Attention : s'il y a conflit avec des réservations existantes, celles-ci seront automatiquement et irrémédiablement supprimées au profit de la nouvelle réservation. De plus, les personnes concernées par les suppressions ne seront pas prévenues par email.

Cette procédure se déroule en trois étapes :

• Choix du (des) domaine(s) et du type d'action
• Choix des ressources à réserver, nom du réservant, description et type des réservations
• Choix des dates et heures à réserver sur un calendrier

5.6.Recherche, rapports et statistiques

L'outil "Recherche - Rapports - Statistiques" permet d'effectuer des recherches sur les réservations déjà effectuées et d'afficher les résultats sous la forme d'un tableau de statistiques ou bien sous la forme d'un rapport donnant le détail des réservations.

Le résumé statistique

Le résumé statistique est un tableau à double entrée : une ressource par  colonne et un item par ligne correspondant selon la valeur du champ "résumé par".

Par exemple, dans le cas d'un résumé statistique par bénéficiaire, chaque cellule affiche pour chaque utilisateur (un utilisateur par ligne) et pour une ressource
donnée (colonne) :

• entre parenthèse le nombre de réservations effectuées par cet utilisateur,
• suivi du nombre d'heures de réservations correspondant, ou bien du nombre de créneaux correspondants (selon la configuration du domaine).

Autre exemple, dans le cas d'un résumé par "type" : chaque cellule affiche pour chaque type (un type par ligne) et pour une ressource donnée (colonne) :

• entre parenthèse, le nombre de réservations correspondant au type figurant dans l'en-tête de ligne,
• suivi du nombre d'heures de réservations correspondant, ou bien du nombre de créneaux correspondants (selon la configuration du domaine)

Fichier CSV

Les fichiers CSV permettent une exploitation des résultats à l'aide d'un tableur. Le séparateur utilisé est le point-virgule.

5.7.La configuration par « jours cycle »

La configuration par « jours cycle » offre la possibilité de réorganiser le calendrier de GRR pour qu'il corresponde non pas aux jours du calendrier « normal », mais à des « jours cycle ».

Ainsi, un établissement peut par exemple fonctionner sur des cycles de 9 jours, appelés « jours cycle ». Soient par exemple « J1 », « J2 », ... « J9 », chacun de ces « jours cycle ».

Dans GRR, une interface permet de faire correspondre, à chaque jour du calendrier « normal », un des « jours cycle » ou éventuellement aucun (jours fériés...).

Par exemple, au lundi 12 février peut correspondre « J1 », au mardi 13 févier, « J2 », au mercredi 14 février, aucun jour cycle, au lundi 20 février on peut faire correspondre « J3 », etc...

Une fois ce calendrier des « jours-cycle » créé, Il est alors possible d'effectuer des réservations avec périodicité selon ses jours cycle.

Dans certains établissements scolaires du Québec, cette organisation des horaires est habituelle.

La marche à suivre est la suivante

• Activer la fonctionnalité des « jours cycles » (« Administration », puis « Configuration générale », puis  « Activation de modules ».

• Paramétrage du calendrier (« Administration », puis « Calendrier des jours cycles », puis  « Paramétrage du calendrier ») afin de définir  les paramètres qui seront utilisés lors de la création à la volée du calendrier des "jours cycle".

• Création du calendrier (« Administration », puis « Calendrier des jours cycles », puis  « Création/Régénération du calendrier "jours cycle" »).

• Une fois le calendrier généré, vous pouvez modifier manuellement l'affectation des jours cycle pour chaque date du calendrier (« Administration », puis « Calendrier des jours cycles », puis  « Modification/Visualisation du calendrier "Jours cycle »).

 Du point de vue de l'utilisateur, celui-ci dispose, dans les options de périodicité, d'un type supplémentaire de périodicité selon les  "Jours Cycle".

5.8.Numéro de version et mise à jour de la base de donnée

Cet outil indique le numéro de la version de GRR utilisée et permet de mettre à jour la base de données en cas de besoin.

La mise à jour de GRR s'effectue en deux étapes :
- une mise à jour des scripts,
- suivi d'une mise à jour de la base de données

Une fois la mise à jour des scripts effectuées, connectez-vous en administrateur et rendez-vous sur la page de mise à jour de la base de données ([Administration] -> [Numéro de version et mise à jour]). La  page vous propose alors de mettre à jour la base Mysql.

Remarques :

• Il peut être nécessaire dans certains cas de forcer une mise à jour vers une version actuelle ou antérieure (cas où la mise à jour normale ne s'est pas bien passée). Supposons que l'adresse de votre site soit : http://www.monsite/grr/ et que vous vouliez forcer une mise à jour vers la version 1.9.4, bien qu'étant déjà à jour de cette version. Il suffit alors de taper dans la barre d'adresse : http://www.monsite/grr/admin_maj.php?force_maj=1.9.4
• Il peut être nécessaire dans certains cas d'accéder directement à l'interface de mise à jour de la base sans passer par l'interface normale de connexion. Supposons que l'adresse de votre site soit : http://www.monsite/grr/. Il suffit alors de taper dans la barre d'adresse : http://www.monsite/grr/admin_maj.php.Vous êtes ensuite invité à vous connecter en administrateur. Vous accédez alors directement à la page de mise à jour de la base de données.

6.Authentification et ldap

GRR s'intègre souvent dans un environnement comportant d'autres applications demandant également une identification. Un des soucis des  administrateurs est alors de mettre en place une structure évitant à l'utilisateur de s'identifier auprès de chaque application. La solution de ce genre de problème réside dans l'installation d'un système d'authentification unique qui "chapeaute" les applications telles que GRR, autrement dit un SSO (Single Sign-On).  SSO désigne des systèmes d'authentification unique permettant de simplifier pour l'utilisateur la gestion de ses mots de passe.

Il existe actuellement plusieurs solutions. Parmi celles-ci, on peut retenir :

• CAS (http://www.ja-sig.org/products/cas/index.html)
• LemonLDAP (http://wiki.lemonldap.objectweb.org/xwiki/bin/view/Main/WebHome)
• LASSO (http://lasso.entrouvert.org/)

Certaines plate-forme ont également développé leur propre SSO. C'est le cas du serveur de communication LCS (http://wwdeb.crdp.ac-caen.fr/LcsDoc/index.php/Accueil)

La difficulté consiste alors à adopter une solution SSO compatible avec les applications que l'on veut mettre en place.

Actuellement, GRR est compatible avec plusieurs SSO (LemonLDAP, CAS, LASSO, LCS).

6.1.Configuration LDAP

Depuis la version GRR 1.7, il est possible de se connecter à GRR en s'authentifiant auprès d'un  annuaire LDAP. LDAP (Lightweight Directory Access Protocol) est un protocole permettant d’interroger un annuaire contenant des informations d’utilisateurs (nom, login, email, ...).

Dans le panneau d'administration de GRR, une page « configuration LDAP » permet d'activer et de configurer l'authentification LDAP. A l'ouverture de cette page, GRR détecte si PHP a été compilé avec le support LDAP. Dans le cas contraire, un message en avertit l'administrateur qui ne peut aller plus loin dans le paramétrage LDAP.

L'activation LDAP consiste à choisir le statut par défaut des utilisateurs venant de l'annuaire (« usager » ou « visiteur »).

Une fois LDAP activé, il faut configurer le fichier « config_ldap.inc.php », ce qui est relativement simple en utilisant la procédure automatique accessible à partir de cette page (attention à donner les droits d'écriture sur le fichier « config_ldap.inc.php »).

Attention : si vous configurez manuellement le fichier « config_ldap.inc.php » (sans passer par la configuration en ligne), vous devez tout de même activer LDAP en choisissant le statut par défaut des utilisateurs importés.

Une fois la configuration correctement effectuée, deux types d'utilisateurs peuvent cohabiter :

• les utilisateurs gérés directement par GRR dans la base locale de GRR et
• les utilisateurs importés de l'annuaire LDAP.

Dans le tableau de gestion des utilisateurs un champ indique le type d'authentification (« local » ou « ext ») de l'utilisateur.

Quand le type d'authentification d'un utilisateur est « ext », il ne peut changer son mot de passe dans GRR (celui-ci en effet n'est pas stocké dans GRR mais dans l'annuaire LDAP).
L'administrateur peut modifier tous les paramètres d'un utilisateur « ext » tout comme pour un utilisateur « local », à l'exception du mot de passe qui est laissé vide dans la base locale.
L'administrateur a la possibilité de changer un utilisateur « ext » en un utilisateur « local ». La procédure est irréversible. Il y a alors perte de synchronisation entre GRR et LDAP pour cet utilisateur.
GRR n'inscrit aucune donnée dans l'annuaire. Ainsi GRR n’a besoin que d’un accès en lecture seule à l’annuaire LDAP.

Concrètement, quand un utilisateur tente de se connecter à GRR en tapant un identifiant et un mot de passe, GRR suit la procédure suivante :

• GRR regarde si un utilisateur ayant cet identifiant et ce mot de passe est présent dans la base des utilisateurs de GRR.
  Si oui : l'utilisateur est connecté à GRR.
• Dans le cas contraire : si ldap n'est pas activé ou pas configuré, la procédure s'arrête et il y a échec de la connexion. Si ldap est activé et configuré, GRR tente une authentification de l'utilisateur dans l'annuaire.
  
  • Si cette authentification échoue,la procédure s'arrête et il y a échec de la connexion.
  • Si l'authentification réussit :
    
    1. si c'est la première connexion à GRR, GRR crée l'utilisateur « ldap » dans la table « utilisateurs » en tentant d'importer le nom et l'adresse email. Le champ « mot de passe » est laissé vide. Le statut « usager » ou « visiteur » est celui défini par défaut dans la configuration LDAP. L'administrateur pourra par la suite modifier ces paramètres au cas par cas. La procédure s'arrête : l'utilisateur est alors connecté à GRR. (remarque : si un utilisateur « local » existant porte déjà le même identifiant, l'importation ne pourra avoir lieu : il y a échec de la connexion).
    2. Si ce n'est pas la première connexion, GRR récupère dans sa base les informations concernant l'utilisateur (paramètres par défaut, langue, ...). L'utilisateur peut se connecter à GRR.

Une fois un utilisateur « ldap » connecté, il est traité par la voie classique, c’est-à-dire simplement avec le cookie de session. Ainsi on ne se connecte à LDAP que lors de la procédure de connexion à GRR. De même, les paramètres pris en compte dans la navigation dans GRR (affichage par défaut, nom, prénom, email, ...) sont ceux de GRR.

6.2.Authentification IMAP/POP

Il est possible de se connecter à GRR en s'authentifiant à l'aide d'un compte IMAP ou POP3.

L'activation de l'authentification IMAP/POP consiste à choisir le statut par défaut des utilisateurs venant de l'annuaire (« usager » ou « visiteur »).

Une fois authentification activée, il faut configurer le fichier « config_imap.inc.php », soit manuellement, soit en utilisant la procédure automatique accessible à partir de la même page.

Une fois la configuration correctement effectuée, deux types d'utilisateurs peuvent cohabiter :

• les utilisateurs gérés directement par GRR dans la base locale de GRR et
• les utilisateurs créés lors la première connexion IMAP ou POP.

Dans le tableau de gestion des utilisateurs un champ indique le type d'authentification (« local » ou « ext ») de l'utilisateur.

Quand le type d'authentification d'un utilisateur est « ext », il ne peut changer son mot de passe dans GRR puisqu'il s'agit du mot de passe IMAP ou POP.
L'administrateur peut modifier tous les paramètres d'un utilisateur « ext » tout comme pour un utilisateur « local », à l'exception du mot de passe qui est laissé vide dans la base locale.
L'administrateur a la possibilité de changer un utilisateur « ext » en un utilisateur « local ». La procédure est irréversible. Il y a alors perte de synchronisation entre GRR et IMAP/POP pour cet utilisateur.

Concrètement, quand un utilisateur tente de se connecter à GRR en tapant un identifiant et un mot de passe, GRR suit la procédure suivante :

• GRR regarde si un utilisateur ayant cet identifiant et ce mot de passe est présent dans la base des utilisateurs de GRR.
  Si oui : l'utilisateur est connecté à GRR.
• Dans le cas contraire GRR tente une authentification de l'utilisateur dans auprès du serveur IMAP ou POP.
  
  • Si cette authentification échoue,la procédure s'arrête et il y a échec de la connexion.
  • Si l'authentification réussit :
    
    1. si c'est la première connexion à GRR, GRR crée l'utilisateur dans la table « utilisateurs ». Le champ « mot de passe » est laissé vide. Le statut « usager » ou « visiteur » est celui défini par défaut dans la configuration LDAP. L'administrateur pourra par la suite modifier ces paramètres au cas par cas. La procédure s'arrête : l'utilisateur est alors connecté à GRR. (remarque : si un utilisateur « local » existant porte déjà le même identifiant, l'importation ne pourra avoir lieu : il y a échec de la connexion).
    2. Si ce n'est pas la première connexion, GRR récupère dans sa base les informations concernant l'utilisateur (paramètres par défaut, langue, ...). L'utilisateur peut se connecter à GRR.

Remarque : l'authentification IMAP/POP ne permet pas de récupérer les données (nom, prénom, ...) de l'utilisateur : celui-ci est donc invité lors de la première connexion à compléter son profil.

6.3.Intégration de GRR dans CAS SSO

L’université de Yale aux Etats-Unis (http://www.ja-sig.org/products/cas/index.html) a développé le logiciel open source CAS (Central Authentification Service) pour centraliser toutes les identifications à différentes applications afin d'éviter les identifications multiples (SSO).
Depuis la version 1.7, GRR est prévu pour fonctionner dans un environnement CAS SSO.

Les Pré-requis :

Version PHP supérieure ou égale à 4.2.2, compilée avec les options suivantes :
--with-curl, --with-openssl, --with-dom, --with-zlib
Installation de la librairie phpCAS (http://esup-phpcas.sourceforge.net/) :
1. téléchargement du package phpCAS
2. Extraction du package dans un sous-répertoire « CAS » dans le répertoire correspondant à l'include_path du php.ini (exemple : /var/lib/php)
3. Création du fichier cas.sso contenant les informations de connexions au serveur CAS, à mettre dans la même répertoire  /var/lib/php

Exemple de fichier cas.sso :
<?php
$serveurSSO="nom.du.serveur.fr";
$serveurSSOPort=8443;
$serveurSSORacine=CAS;
?>

Il est possible de modifier les chemins d'accès au fichier « cas.sso » et à la librairie phpCAS dans le fichier « cas.inc.php ».

Fonctionnement

Dans le panneau d'administration de GRR, une page « configuration SSO » permet d'activer la prise en charge de l'environnement CAS. L'activation consiste à choisir le statut par défaut des utilisateurs authentifié CAS (« usager » ou « visiteur »).

Remarque :
Depuis la version GRR197, il est possible de configurer le serveur CAS et GRR de façon à pouvoir récupérer dans GRR des attributs LDAP envoyés par le serveur CAS. Il est alors possible d'associer à un attribut LDAP le statut de l'utilisateur dans GRR. Dans ce cas, le statut par défaut précédent n'est utilisé que lorsque la procédure d'association échoue. Reportez-vous à l'annexe 1 de cette documentation pour plus de détails.

Tout comme pour LDAP, deux types d'utilisateurs peuvent cohabiter :

• les utilisateurs authentifiés et gérés directement par GRR dans la base locale de GRR et
• les utilisateurs authentifiés par CAS.

Dans le tableau de gestion des utilisateurs un champ indique le type d'authentification (« local » ou « ext ») de l'utilisateur.

Remarques :

• Pour se connecter, les utilisateurs locaux, gérés directement par GRR doivent se rendre à l'adresse du type http://monserveur.fr/Grr/login.php (ne pas oublier login.php à la fin). La possibilité de créer des utilisateurs locaux est intéressante pour permettre l'accès à GRR à des personnes ne disposant pas de compte CAS. Il est fortement recommandé de créer un administrateur local de GRR. En effet, certaines mises à jour de GRR nécessite un accès particulier pour effectuer la mise à jour.

• Un utilisateur qui désire accéder à GRR en s'authentifiant par CAS doit se rendre à l'adresse du type http://monserveur.fr/Grr/. S'il n'est pas déjà authentifié, une page lui propose de rentrer son identifiant et son mot de passe. Tout ce qui concerne les utilisateurs authentifiés par CAS est traité de la même façon que les utilisateurs LDAP .

Que se passe-t-il une fois que l'utilisateur a été authentifié par CAS ?

Lorsque GRR est paramétré pour s'intégrer dans un environnement CAS, le processus suivant s'applique :

• Pour se connecter l'utilisateur utilise l'url du type http://mon.site.fr/grr/. Le navigateur est alors automatiquement dérouté vers la page d'authentification CAS. Les utilisateurs « locaux » (entièrement gérés par GRR), doivent utiliser l'url du type http://mon.site.fr/grr/login.php pour se connecter directement à la base de GRR sans passer par l'authentification CAS. C'est notamment le cas de l'administrateur.
• Une fois authentifié, GRR regarde si un utilisateur dont le type d'authentification est « ext » ayant cet identifiant est présent dans la base des utilisateurs de GRR.
  
  • Si oui : GRR récupère dans sa base les informations concernant l'utilisateur (paramètres par défaut, langue, ...). L'utilisateur peut se connecter à GRR.
  • Dans le cas contraire, c'est la première connexion à GRR : GRR crée l'utilisateur dans la table « utilisateurs ». Le champ « mot de passe » est laissé vide.
    Dans le cas où un annuaire LDAP est configuré, GRR tente de récupérer dans l'annuaire les valeurs des « nom »,  « prénom » et « email » (fonctionnalité présente à partir de la version GRR 1.9.6 uniquement).
    Le champ « type d'authentification » prend la valeur « ext ». Le champ « statut » prend la valeur  « usager » ou « visiteur » selon la valeur définie par défaut dans la configuration CAS. L'administrateur pourra par la suite modifier ce paramètre au cas par cas. l'utilisateur est alors connecté à GRR. (remarque : si un utilisateur « local » existant porte déjà le même identifiant, l'importation ne pourra avoir lieu : il y a échec de la connexion).

Une fois l'utilisateur connecté, rien ne diffère pour celui-ci par rapport à un environnement non CAS à la différence près qu'il ne peut pas modifier son mot de passe (celui-ci étant géré par le serveur CAS).

Lorsqu'un utilisateur se déconnecte, la session GRR est détruite et le navigateur est redirigé vers une page dont l'URL est spécifié dans la page de configuration générale.

6.4.Intégration de GRR dans LemonLdap SSO

ATTENTION :
GRR supporte LemonLDAP mais pas LemonLDAP::NG qui est une réécriture complète de LemonLDAP. En attendant qu'un contributeur me propose les modifications nécessaires pour adapter GRR à LemonLDAP::NG, vous pouvez simplement configurer GRR avec l'authentification HTTP. En effet, LemonLDAP::NG simule une authentification Apache, ce qui permettra à GRR de fonctionner dans un environnement LemonLDAP::NG.


Lemonldap (http://lemonldap.sourceforge.net/) est un système SSO sous GPL utilisé par des grands ministères (MINEFI, Défense, Justice, ...). Depuis la version 1.9.1, GRR est prévu pour fonctionner dans un environnement LemonLdap.

Fonctionnement

Dans le panneau d'administration de GRR, une page « configuration SSO » permet d'activer la prise en charge de l'environnement Lemonldap. L'activation consiste à choisir le statut par défaut des utilisateurs authentifié (« usager » ou « visiteur »).

Tout comme pour LDAP et CASS SSO, deux types d'utilisateurs peuvent cohabiter :

• les utilisateurs authentifiés et gérés directement par GRR dans la base locale de GRR et
• les utilisateurs authentifiés par CAS.

Dans le tableau de gestion des utilisateurs un champ indique le type d'authentification (« local » ou « ext ») de l'utilisateur.

Remarques :

• Pour se connecter, les utilisateurs locaux, gérés directement par GRR doivent se rendre à l'adresse du type http://monserveur.fr/Grr/login.php (ne pas oublier login.php à la fin). La possibilité de créer des utilisateurs locaux est intéressante pour permettre l'accès à GRR à des personnes ne disposant pas de compte LemonLdap. Il est fortement recommandé de créer un administrateur local de GRR. En effet, certaines mises à jour de GRR nécessite un accès particulier pour effectuer la mise à jour.

• Un utilisateur qui désire accéder à GRR en s'authentifiant par LemonLdap doit se rendre à l'adresse du type http://monserveur.fr/Grr/. S'il n'est pas déjà authentifié, une page lui propose de rentrer son identifiant et son mot de passe. Tout ce qui concerne les utilisateurs authentifiés par Lemonldap est traité de la même façon que les utilisateurs LDAP .

 

Que se passe-t-il une fois que l'utilisateur a été authentifié par LemonLadap ?

Lorsque GRR est paramétré pour s'intégrer dans un environnement LemonLdap, le processus suivant s'applique :
Une fois authentifié, GRR regarde si un utilisateur dont le type d'authentification est « ext » ayant cet identifiant est présent dans la base des utilisateurs de GRR.

• Si oui : GRR récupère dans sa base les informations concernant l'utilisateur (paramètres par défaut, langue, ...). L'utilisateur peut se connecter à GRR.

• Dans le cas contraire, c'est la première connexion à GRR : GRR crée l'utilisateur dans la table « utilisateurs ». Les champ « mot de passe », « prénom », « email » sont laissés vides. Le champ « type d'authentification » prend la valeur « ext ». Le champ « statut » prend la valeur  « usager » ou « visiteur » selon la valeur définie par défaut dans la configuration Lemonldap. L'administrateur pourra par la suite modifier ce paramètre au cas par cas. l'utilisateur est alors connecté à GRR. (remarque : si un utilisateur « local » existant porte déjà le même identifiant, l'importation ne pourra avoir lieu : il y a échec de la connexion).

Une fois l'utilisateur connecté, rien ne diffère pour celui-ci par rapport à un environnement normal à la différence près qu'il ne peut pas modifier son mot de passe (celui-ci étant géré par le serveur Lemonldap).

Lorsqu'un utilisateur se déconnecte, la session GRR est détruite et le navigateur est redirigé vers une page dont l'URL est spécifié dans la page de configuration générale.

6.5.Intégration de GRR dans un serveur LCS

LCS (http://lcs.ac-caen.fr/) est un serveur de communication développé par l'équipe Académique TICE de Caen et déployé dans l'ensemble des lycées et collèges de l'académie, ainsi que dans de nombreux autres établissements de France.

Depuis la version 1.9.3, GRR est prévu pour s'intégrer sur une serveur LCS.

Intégration de GRR dans un serveur LCS

La mise en place de GRR sur un serveur LCS peut se faire de deux façons : automatique ou manuelle.

1) Mise en place automatique à l'aide du plugin (recommandé)

Connecté en admin sur le serveur LCS, il vous suffit d'installer le plugin LCS (voir documentation LCS). Il se peut que le plugin LCS ne soit pas basé sur la dernière version de GRR. Dans ce cas, voir plus bas ce qui concerne la mise à jour de GRR.

Dans le panneau d'administration de GRR, une page « configuration SSO » permet de modifier le statut par défaut dans GRR (« usager » ou « visiteur ») des élèves et des « non-élèves » (professeurs et administratifs).

2) Mise en place manuelle (expert)

Cette procédure nécessite une assez bonne connaissance du système LCS et se décompose en plusieurs étapes que nous ne développerons pas entièrement dans ce document :

a) Installation dans le répertoire « /usr/share/lcs/ ».

Les modules applicatifs de LCS sont en général installés dans le répertoire « /usr/share/lcs/ » :

• création d'un répertoire « grr » dans « /usr/share/lcs/ »,
• transfert des fichiers de GRR dans ce répertoire,
• création d'une base de données Mysql ayant par exemple pour nom « grr » et d'un utilisateur mysql ayant par exemple pour nom « grr » et ayant les droits SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX et ALTER sur la base précédemment créée,
• lancement de la procédure d'installation (voir documentation GRR).
• Remarque : pour que GRR soit accessible, il est nécessaire de modifier le fichier « /etc/lcs/apache.conf » en ajoutant une ligne (alias) du type : « alias /grr/ /usr/share/lcs/grr/ », puis de redémarrer le serveur apache. GRR sera alors accessible à l'adresse du type « http://mon-site-lcs.fr/grr/ ».

b) Installation dans le répertoire « public_html » d'un utilisateur « grr ».

Une autre façon d'installer GRR consiste à créer un utilisateur du groupe « Profs » ayant le nom « grr ». Le chemin d'accès à l'application est alors du type : « http://mon-site-lcs.fr/~grr/ » :

• ouverture d'une session sous le nom « grr »,
• suppression du fichier « index.html » de « public_html »,
• transfert des fichiers de GRR dans « public_html »,
• lancement de la procédure d'installation (voir documentation GRR).

c) Activation de la prise en charge de l'environnement LCS

Dans le panneau d'administration de GRR, une page « configuration SSO » permet d'activer la prise en charge de l'environnement LCS. L'activation consiste à choisir le statut par défaut des élèves et des « non-élèves » (professeurs et administratifs) authentifiés (« usager », « visiteur » ou « ne pas importer »).

d) Mettre en place un lien vers GRR

Contrairement à l'installation automatique (plugin), l'installation manuelle de GRR sur un serveur LCS ne fournit pas automatiquement l'icône « grr » dans la partie « Applications » de LCS. Nous ne détaillerons pas ici les différentes façons de personnaliser le serveur LCS afin de mettre à la disposition des utilisateurs dans l'espace LCS, un lien vers GRR.

3) Mise à jour automatique de GRR

Connecté en admin sur le serveur LCS, il vous suffit de procéder à une mise à jour par le plugin LCS (voir documentation LCS) si elle existe !

4) Mise à jour manuelle de GRR

Il se peut qu'une nouvelle version de GRR soit disponible sur le site de GRR et que le plugin de mise à jour ne soit pas disponible. Dans ce cas, vous pouvez mettre à jour GRR manuellement :

• Tout d'abord, il est fortement conseillé de créer un administrateur local dans GRR (c'est même indispensable si vous mettez à jour GRR à partir du premier plugin basé sur la version 1.8 de GRR)

• Par sécurité, faites une sauvegarde de votre base de donnée.

• Téléchargez la dernière version complète de GRR, décompactez-la dans le dossier « /usr/share/lcs/Plugins/Grr ».

• Editez le fichier config.inc.php contenu dans le dossier "/include" et servez-vous de votre ancien fichier config.inc.php pour y remettre les bons paramètres, propres à votre configuration. Enregistrez le fichier config.inc.php.

• Rendez-vous dans en admin. Une page vous signale alors un problème. Cliquez sur "Mettre à jour la base Mysql", puis connectez-vous en administrateur local dans la nouvelle page.

• Vous êtes alors redirigé dans la rubrique "Numéro de version et mise à jour". Effectuez la mise à jour de la base de donnée puis lisez le résultat de la mise à jour.

5) Paramétrage de GRR

a) Le fichier « config.inc.php »

Dans le menu « administration », la page « configuration générale » permet de configurer un grand nombre de paramètres.

Attention : en plus de ceux-ci, d'autres paramètres de configuration de GRR, moins courants, sont à votre disposition dans le fichier « config.inc.php » (consulter la documentation de GRR). La modification de paramètres présents dans ce fichier est évidemment plus délicate car elle suppose l'accès à ce fichier qui est normalement présent dans le répertoire du type « /usr/share/lcs/Plugins/Grr/include » (dans le cas d'une installation par le plugin).

Ce fichier « config.inc.php » contient des paramètres très importants et il convient de l'examiner en détail. Toutes les indications nécessaires à la configuration de ce fichier sont disponibles dans la documentation complète ainsi que dans le fichier lui-même.

Parmi ces paramètres, deux sont particulièrement importants dans le cas d'une intégration de GRR dans LCS :

b) Type d'accès à GRR

L'administrateur a le choix entre deux types d'accès à l'application GRR :

• Accès libre en consultation : il n'est alors pas nécessaire de se connecter pour consulter le planning des réservations. L'internaute a les mêmes possibilités qu'un « visiteur » connecté (hormis l'outil de recherche). Dans ce type de configuration, GRR est accessible librement et vos ressources et les réservations sont alors visibles de tous.

• Accès avec authentification : il est obligatoire de se connecter pour accéder au site, même pour une simple consultation des réservations.

c) La variable use_function_mysql_real_escape_string

Au moment où cette documentation est écrire, la version de PHP des serveurs LCS est inférieure à 4.3.0. Or, GRR utilise la fonction « mysql_real_escape_string() » qui n'est disponible qu'à partir de la version 4.3.0 de PHP. Pour que GRR fonctionne dans un environnement LCS, il est donc nécessaire de positionner la variable $use_function_mysql_real_escape_string à "0" (zéro).

Attention : la valeur par défaut dans le cas d'une installation manuelle est $use_function_mysql_real_escape_string = 1.

Fonctionnement

1) Généralités

Lorsque GRR est intégré à un serveur LCS, deux types d'utilisateurs peuvent cohabiter :

• les utilisateurs locaux gérés directement par GRR dans la base locale de GRR et

• les utilisateurs authentifiés par LCS.

Dans la table « grr_utilisateurs » un champ (« source ») indique le type d'authentification de l'utilisateur : « local » ou « ext » (c'est-à-dire ici « LCS »).

 

• Quand le type d'authentification d'un utilisateur est « ext », il ne peut changer son mot de passe dans GRR (celui-ci en effet n'est pas stocké dans GRR mais dans l'annuaire LDAP de LCS).

• L'administrateur a la possibilité de changer un utilisateur « ext » en un utilisateur « local ». La procédure est irréversible. Il y a alors perte de synchronisation entre GRR et le LDAP de LCS pour cet utilisateur.

• GRR n'inscrit aucune donnée dans l'annuaire LDAP de LCS.

2) Cas d'un utilisateur authentifié sur LCS

Concrètement, quand un utilisateur authentifié sur LCS accède à GRR :

• s'il s'agit du premier accès à GRR, GRR crée l'utilisateur avec le champ source « ext » dans la table « utilisateurs » en important le nom, le prénom et l'adresse email. Le champ « mot de passe » est laissé vide. Le statut « usager » ou « visiteur » est celui défini par défaut dans la configuration SSO de LCS. L'administrateur peut par la suite modifier ces paramètres au cas par cas. l'utilisateur est alors connecté à GRR. (remarque : si un utilisateur « local » ayant le même identifiant est présent dans la base de GRR, il y a échec de la connexion à GRR.

• Si ce n'est pas la première connexion, GRR met à jour dans sa base les informations concernant les nom, prénom et email de l'utilisateur.

• Dans la page de configuration, un champ supplémentaire permet de préciser une liste de groupe LCS dont les membres sont autorisés à accéder à GRR. Si le champ est laissé vide, il n'y a pas de restrictions. Dans le cas contraire, seuls les utilisateurs appartenant à au moins l'un des groupes listés sont autorisés à accéder à GRR. Il faut écrire les groupes en les séparant par un point-vigule, par exemple : « Profs;Administratifs ».

 

A tout moment, chaque utilisateur a accès à la gestion de son compte pour modifier ses paramètres personnels, propres à GRR (paramètres par défaut, langue, ...), stockés dans la base locale de GRR.

Lorsqu'un utilisateur se déconnecte de LCS, la session GRR est automatiquement détruite et l'accès à GRR (en tant qu'utilisateur connecté) est impossible.

Cette procédure de déconnexion automatique est une fonctionnalité des plugins de LCS. Néanmoins, même si GRR est intégré manuellement à LCS, une procédure interne à GRR assure également la déconnexion de GRR lorsqu'un utilisateur se déconnecte de LCS.

3) Cas d'un utilisateur local

Un utilisateur local, non présent dans l'annuaire LDAP de LCS peut se connecter à GRR à l'adresse du type : « http://monserveur.fr/Plugins/Grr/login.php » (dans le cas d'une installation avec plugin).

La possibilité de créer des utilisateurs locaux est intéressante pour permettre l'accès à GRR à des personnes ne disposant pas de compte LCS.

Il est fortement recommandé de créer un administrateur local de GRR. En effet, certaines mises à jour de GRR nécessite un accès particulier pour effectuer la mise à jour.

Gestion des utilisateurs

Dans la partie administration, la page « utilisateurs » permet d'accéder à la gestion des utilisateurs.

La plupart des fonctionnalités disponibles sur cette page ne sont pas propres au cas d'une installation dans un environnement LCS. En revanche, les deux procédures suivantes concernant uniquement le cas de GRR dans un environnement LCS :

1) Nettoyage de la base locale

Lorsqu'un utilisateur est définitivement supprimé de la base LCS, celui-ci peut rester présent dans la base locale de GRR. Au fil des mois, la base locale peut ainsi contenir un certain nombre d'informations obsolètes.

La procédure « Nettoyage de la base locale » recherche et supprime de la base locale de GRR, les utilisateurs LCS qui ne sont plus présents dans la base LCS : ces utilisateurs sont effacés de la table locale « grr_utilisateurs » ainsi que des tables de liaison le cas échéant.

2) Mise à jour de la base locale

Lorsqu'un utilisateur est ajouté à la base LCS, celui-ci peut immédiatement se connecter à GRR, comme cela a déjà été dit plus haut. A sa première connexion à GRR, l'utilisateur est ajouté à la base locale de GRR et apparaît alors dans la liste des utilisateurs.

De même lorsque des informations concernant le nom, le prénom ou l'adresse email d'un utilisateur sont modifiés dans la base LCS, les modifications sont automatiquement répercutées dans la base locale de GRR à la prochaine connexion de l'utilisateur à GRR.

L'administrateur peut néanmoins forcer une mise à jour des utilisateurs de la base locale de GRR.

Cette procédure effectue les deux opérations suivantes :

Insertion dans la base locale de GRR des utilisateurs LCS qui ne sont pas présents localement.

Mise à jour de la base locale de GRR à partir des informations de la base LCS, pour les utilisateurs déjà présents.

3) Quelques remarques

• Activation/Désactivation d'un utilisateur local :

Le fait de rendre inactif un utilisateur a pour effet de rendre son accès à GRR impossible, qu'il s'agisse d'un utilisateur authentifié LCS ou bien d'un utilisateur local.

• Changement de statut :

Dans le panneau d'administration de GRR, la « configuration SSO » permet de spécifier le statut par défaut dans GRR (« usager » ou « visiteur ») des élèves et des « non-élèves » (professeurs et administratifs). Il s'agit du statut qui est attribué à chaque utilisateur lors de sa création dans la base locale.

Il est ensuite possible à tout moment de modifier le statut d'un utilisateur particulier : « usager », « visiteur » ou « administrateur » (voir la documentation complète de GRR pour plus de détails).

6.6.Authentification HTTP

Dans le panneau d'administration de GRR, une page « configuration SSO » permet d'activer l'authentification HTTP. L'activation consiste à choisir le statut par défaut des utilisateurs authentifié (« usager » ou « visiteur »).

Deux types d'utilisateurs peuvent cohabiter :

• les utilisateurs locaux, gérés directement par GRR dans la base locale de GRR et
• les utilisateurs authentifiés par HTTP.

Dans le tableau de gestion des utilisateurs un champ indique le type d'authentification (« local » ou « ext ») de l'utilisateur.

Remarques :

• Pour se connecter, les utilisateurs locaux, gérés directement par GRR doivent se rendre à l'adresse du type http://monserveur.fr/Grr/login.php (ne pas oublier login.php à la fin). La possibilité de créer des utilisateurs locaux est intéressante pour permettre l'accès à GRR à des personnes ne disposant pas de compte apache. Il est fortement recommandé de créer un administrateur local de GRR. En effet, certaines mises à jour de GRR nécessite un accès particulier pour effectuer la mise à jour.

• Un utilisateur qui désire accéder à GRR en s'authentifiant par HTTP doit se rendre à l'adresse du type http://monserveur.fr/Grr/. S'il n'est pas déjà authentifié, une page lui propose de rentrer son identifiant et son mot de passe.

Que se passe-t-il lorsqu'un utilisateur a été authentifié par HTTP ?

Une fois authentifié par HTTP, GRR regarde si un utilisateur dont le type d'authentification est « ext » ayant cet identifiant est présent dans la base des utilisateurs de GRR.

• Si oui : GRR récupère dans sa base les informations concernant l'utilisateur (paramètres par défaut, langue, ...). L'utilisateur peut se connecter à GRR.
• Dans le cas contraire, c'est la première connexion à GRR : GRR crée l'utilisateur dans la table « utilisateurs ». Les champ « mot de passe », « prénom », « email » sont laissés vides. Le champ « type d'authentification » prend la valeur « ext ». Le champ « statut » prend la valeur  « usager » ou « visiteur » selon la valeur définie par défaut dans la configuration HTTP. L'administrateur pourra par la suite modifier ce paramètre au cas par cas. l'utilisateur est alors connecté à GRR. (remarque : si un utilisateur « local » existant porte déjà le même identifiant, l'importation ne pourra avoir lieu : il y a échec de la connexion).

Une fois l'utilisateur connecté, rien ne diffère pour celui-ci par rapport à un environnement normal à la différence près qu'il ne peut pas modifier son mot de passe (celui-ci n'étant pas stocké dans la base de GRR).

Déconnexion

Lorsqu'un  utilisateur  est authentifié par HTTP, il le reste tout au long de la session.
Conséquence : même si l'utilisateur se déconnecte de GRR (destruction de la session sur le serveur et du cookie de session sur le navigateur), dès qu'il accède à l'URL du type http://monserveur.fr/Grr/, il est à nouveau automatiquement reconnecté à GRR puisqu'il  est authentifié par HTTP.

Kerberos

Les premiers tests effectués montrent que l'authentification HTTP fonctionne également au travers d'un environnement SSO  Kerberos (via le module auth_kerb).

6.7.Intégration de GRR dans le SSO LASSO

LASSO (Liberty Alliance Single Sign On) est une implantation libre des spécifications Liberty Alliance développées par la Société Entr'Ouvert ( http://www.entrouvert.org). Il s'agit d'une bibliothèque écrite en langage C qui permet de mettre en oeuvre les spécifications Liberty Alliance, disponible sous licence GNU General Public Licence.

GRR est prévu pour fonctionner dans un environnement SSO LASSO.

Les Pré-requis :

1. Pour la configuration du serveur, reportez vous à la documentation disponible sur : http://lasso.entrouvert.org/.
2. Vous devez également installer spkitlasso, une interface haut niveau pour Lasso disponible ici :  http://perso.entrouvert.org/~bdauvergne/bzr/spkitlasso/
3. Optionnel: si vous avez installé spkitlasso dans un emplacement personnalisé (en dehors de l'include_path PHP), vous devez également spécifier, dans /include/config.inc.php, le chemin d'accès au répertoire d'installation.
4. Allez sur http://votre-serveur/grr/lasso/configure.php pour configurer votre nouveau fournisseur de service Lasso (SP, pour Service Provider).
5. Puis enregistrez ce SP dans le fournisseur d'identité de votre environnement Lasso (IdP, pour Identity Provider), par exemple Authentic.

Fonctionnement

Dans le panneau d'administration de GRR, une page « configuration SSO » permet d'activer la prise en charge de l'environnement LASSO. L'activation consiste à choisir le statut par défaut des utilisateurs authentifié LASSO (« usager » ou « visiteur »).

Tout comme pour les autres SSO, deux types d'utilisateurs peuvent cohabiter :

• les utilisateurs authentifiés et gérés directement par GRR dans la base locale de GRR et
• les utilisateurs authentifiés par LASSO.

Néanmoins, LASSO présente la particularité  de "fédération d'identité", avec "anonymisation" des comptes, et la possibilité de lier un compte local existant au SSO.
Il est ainsi possible, pour un compte local existant (avec mot de passe local) de se "fédérer" au SSO LASSO.

7.Personnaliser GRR

7.1.Adapter les fichiers de langue

GRR utilise des fichiers de langue pour l'affichage. Ces fichiers de langue sont situés dans le répertoire /language de votre installation de GRR.

Afin de préserver la compatibilité avec les futures versions de GRR, vous avez la possibilité de substituer vos propres textes aux messages ou libellés officiels, sans pour autant modifier les fichiers fournis avec GRR.

Exemple pour avoir une version française personnalisée

• Créer, avec un simple éditeur de texte, dans le répertoire /language, un fichier lang_subst.fr.

• Ouvrez le fichier lang.fr avec un éditeur de texte et repérer la ligne correspondant au libellé que vous voulez modifier : supposons que vous préfériez le libellé "En réparation", plutôt que "Temporairement indisponible".  Il s'agit donc, dans lang.fr, de la ligne :

  $vocab["ressource_temporairement_indisponible"] = "Temporairement indisponible";

• Dans le fichier lang_subst.fr que vous venez de créer, tapez les lignes suivantes :
  

  <?php
  $vocab["ressource_temporairement_indisponible"] = "En réparation";
  ?>

• Enregistrez et fermer votre fichier et le tour est joué !

Remarque :
Entre les balises <?php et ?>, vous pouvez placer autant de lignes que vous voulez, chacune correspondant à un texte à substituer.
Fichiers de personnalisation de langue par domaine

Il est possible de personnaliser les fichiers de langue par domaine. Pour cela, il suffit de repérer l'identifiant du domaine (il s'agit d'un nombre facilement repérable dans les adresses URL). Appelons numero, cet identifiant. il suffit alors de créer un fichier nommé lang_subst_numero.fr de la même façon que le fichier lang_subst.fr ci-dessus.

Remarque :
Un fichier lang_subst.fr. peut coexister avec des fichiers lang_subst_numero.fr : ces derniers sont alors prioritaires par rapport au fichier lang_subst.fr.

7.2.Feuilles de style et CSS

Vous pouvez créer votre propre feuille de style.

Pour cela, créez un nouveau répertoire dans le dossier "themes" de votre installation de GRR et prenez pour modèle un des différents répertoires de ce dossier "themes".

Supposons que vous ayez nommé votre répertoire "automne", il vous reste à ajouter ce nom dans la liste des thèmes du fichier misc.inc.php situé dans le répertoire include en prenant pour modèle la façon dont les autres thèmes sont écrits.

Enfin, n'hésitez pas à proposer votre thème à l'équipe des développeurs de GRR pour qu'il soit éventuellement intégré à une future version de GRR.

8.Documentation technique

8.1.Les tables de la base de données

La table grr_room

Elle contient la liste des ressources

• id : numéro identifiant de la ressource (clé de la table)

• area_id : identifiant du domaine (area) auquel elle est rattachée

• room_name : nom de la ressource

• description : description courte des fonctionnalités de la ressource

• capacity : capacité (nombre de place dans le cas d'une salle, 0 sinon)

• max_booking : nombre maximum de réservations possibles par utilisateur (-1 si illimité)

• statut_room : '1' si la ressource est disponible, '0' sinon

• show_fic_room : 'y' si la fiche de présentation est rendue visible, 'n' sinon

• picture_room : nom de l'image de la ressource stockée dans le répertoire /images

• comment_room : description complète des fonctionnalités de la ressource

• show_comment : 'y' : la description complète de la ressource est visible sur les plannings semaines et mois, 'n' sinon

• delais_max_resa_room : nombre maximal de jours au-delà duquel l'utilisateur ne peut pas réserver ou modifier une réservation (-1 si pas de restriction).

• delais_min_resa_room : temps en minutes en-deçà duquel l'utilisateur ne peut pas réserver ou modifier une réservation (0 si pas de restriction).

• order_display : ordre d'affichage :

• allow_action_in_past : permettre les réservation dans le passé ainsi que les modifications/suppressions de réservations passées.

• type_affichage_reser : en mode édtion d'une réservation, valeur 0 : l'utilisateur spécifie une durée de réservation; valeur 1 : l'utilisateur spécifie une date et une heure de fin de réservation.

• moderate : indique si les réservations de la ressource sont modérées ou non. 0 : la ressource n'est pas modéré, 1 : la ressource est modérée.

• qui_peut_reserver_pour : indique le type d'utilisateur autorisé a effectuer des réservations au nom d'autres personnes que lui-même.

• dont_allow_modify : deux valeurs possibles 'y' ou 'n' ( permettre ou non aux utilisateurs, hormis les gestionnaires et les administrateurs, de modifier ou de supprimer leurs propres réservations).

• active_ressource_empruntee : deux valeurs possibles 'y' ou 'n' (activer ou non la fonctionnalité "ressource empruntée/restituée")

• who_can_see : entier indiquant le "niveau" de l'utilisateur autorisé à  voir cette ressource (et éventuellement réserver selon les droits attribués)

• delais_option_reservation : dans le cas des réservations "sous réserve" nombre maximal de jours dont dispose le réservant pour confirmer une réservation.

La table grr_area

Elle contient la liste des domaines c'est à dire les groupes de ressources.

• id : numéro identifiant du domaine (clé de la table)

• area_name : nom du domaine

• access : 'r' si le domaine est un domaine à accès resteint,

• order_display : numéro d'ordre d'affichage du domaine dans la liste des domaines

• ip_adr : activation (1)ou désactivation (0) de la fonction de gestion de l'affichage d'un domaine par défaut en fonction de l'adresse IP de la machine cliente.

• morningstarts_area : heure de début de réservation

• eveningends_area : heure de fin de réservation

• resolution_area : quel bloc peut être réservé, en secondes

• eveningends_minutes_area : minutes à ajouter à l'heure $eveningends pour avoir la fin réelle d'une journée

• weekstarts_area : début de la semaine: 0 pour dimanche, 1 pou lundi, etc.

• twentyfourhour_format_area : format d'affichage du temps : valeur 0 pour un affichage « 12 heures » et valeur 1 pour un affichage« 24 heure ».

• calendar_default_values : 1 : prend en compte les valeurs par défaut de config.inc.php concernant les paramètres d'affichage des planning (compatibilité avec versions < 1.9)

• enable_periods : type des créneaux de réservation :
  « n » : les créneaux de réservation sont basés sur le temps.
  « y » : les créneaux de réservation sont basés sur des intitulés pré-définis (les champs morningstarts_area, eveningends_area, resolution_area, eveningends_minutes_area et twentyfourhour ne sont alors pas pris en compte.

• display_days : chaîne de 7 caractères « y » ou « n » indiquant les jours à afficher, à partir du dimanche. Par exemple la chaîne nyyyyyn signifie qu'on affiche pas les samedis et les dimanches.

• id_type_par_defaut : identifiant du type sélectionné par défaut lors d'une nouvelle réservation.

• duree_par_defaut_reservation_area :  Durée par défaut d'une réservation, en secondes

• duree_max_resa_area : durée maximale en minutes pour une réservation (-1 si pas de restriction)

• max_booking : nombre maximum de réservations possibles par utilisateur (-1 si illimité) pour toutes les ressources du domaine.

 

La table grr_site

Table des sites

• id : identifiant

• sitecode : code du site

• sitename : nom du site

• adresse_ligne1 : ligne 1 adresse

• adresse_ligne2 : ligne 2 adresse

• adresse_ligne3 : ligne 3 adresse

• cp : code postal

• ville : ville

• pays : pays

• tel : téléphone

• fax : fax

La table grr_area_periodes

Table utilisée uniquement dans le cas où enable_periods = 'y'. Stocke les numéros et intitulés des créneaux pour chaque domaine :

• id_area : identifiant du domaine

• num_periode : numéro du créneau

• nom_periode : intitulé du créneau

La table grr_entry

Elle contient la liste des réservations

• id : numéro identifiant de la réservation (clé de la table)

• start_time : date et l'heure du début de la séance (en temps Unix, c'est à dire le nombre de secondes depuis le 1er Janvier 1970)

• end_time : date et l'heure de la fin de la séance (temps Unix)

• entry_type : '0' si aucune périodicité associée. '1' ou '2' si une périodicité est associée ('2' si la réservation a été modifiée indépendamment de la périodicité)

• repeat_id : dans le cas d'une réservation périodique, identifiant de l'entrée dans la table grr_repeat (0 sinon)

• room_id : l'identifiant de la ressource réservée

• timestamp : date et heure de la dernière modification de la réservation

• create_by : identifiant de la personne qui a enregistré la réservation

• beneficiaire : identifiant de la personne au nom de laquelle la réservation a été faite.

• beneficiaire_ext : nom et email de la personne au nom de laquelle la réservation a été faite dans le cas ou beneficiaire est vide

• name : nom de la réservation

• type : type de la réservation

• description : description de la réservation

• statut_entry : statut de la réservation. 'y' : la réservation est en cours d'utilisation. 'e' : la réservation est en cours d'utilisation et un mail est envoyé en cas de retard dans la restitution. Sinon '-'

• option_reservation : cas des réservations "sous réserve". Si -1 : la réservation a été confirmée. Sinon, option_reservation représente le timestamp de la date limite de confirmation de réservation.

• overload_desc : contenu des champs additionnels

• moderate : indique l'état de la modération. 0 : réservation non modérée. 1 : réservation en attente de modération. 2 : réservation acceptée après modération. 3 : réservation refusée après modération.

• jours : numéro du jours cycle dans le cas d'une réservation avec périodicité selon les jours cycle

La table grr_repeat

Elle contient la liste des périodicités

• id : clé de la table

• start_time : début de la périodicité

• end_time : fin de la périodicité

• rep_type : fréquence (0 = jamais, 1 = chaque jour, 2 = chaque semaine, 3 = chaque mois, la même date, 4=chaque année, même date, 5 = chaque mois, même jour de la semaine, 6=toutes les n semaines

• end_date : fin de la répétition

• rep_opt : suite de 7 caractères 0 ou 1 indiquant les jours de périodicité dans le cas ou rep_type vaut 2 ou 6. 0 sinon.

• room_id : identifiant de la ressource réservée

• timestamp : date et heure de la dernière modification

• create_by : identifiant de la personne qui a enregistré cette périodicité

• beneficiaire : identifiant de la personne au nom de laquelle la réservation a été faite.

• beneficiaire_ext : nom et email de la personne au nom de laquelle la réservation a été faite dans le cas ou beneficiaire est vide

• name : le nom de la périodicité

• type : type desréservations

• description : description des réservations

• rep_num_weeks : indique la valeur de n dans le cas où rep-type = 2 (toutes les n semaines)

• overload_desc : contenu des champs additionnels

• jours : numéro du jours cycle dans le cas d'une réservation avec périodicité selon les jours cycle

La table grr_utilisateurs

Elle contient les utilisateurs et tous les renseignements les concernant

• login : identifiant (clé de la table)

• nom : nom de l'utilisateur

• prenom : prénom de l'utilisateur

• password : mot de passe crypté de l'utilisateur

• email : adresse email de l'utilisateur

• statut : prend les valeurs « administrateur », « utilisateur », « visiteur » ou « gestionnaire_utilisteur ».

• etat : prend les valeurs « actif » ou « inactif »

• default_site: site affiché par défaut

• default_area : domaine affiché par défaut

• default_room : ressource affichée par défaut

• default_style : style/thème par défaut

• default_list_type : type par défaut d'affichage des listes des domaines et des ressources

• default_language : langue par défaut

• source : type d'authentification de l'utilisateur (« ext » ou « local »)

La table grr_type_area

Table des types de réservation, communs à tous les domaines

• Id : identifiant mysql du type de réservation

• type_name : nom du type de réservation

• order_display : ordre d'affichage du type de réservation dans les différentes interfaces

• couleur : code couleur du type d'affichage (en référence aux couleurs définies dans le fichier « config.inc.php »)

• type_letter : identifiant du type en lien avec le champ « type » des tables grr_entry et grr_repeat

• disponible : prends les valeurs 2 (le type est disponible pour tout), 3 (le type est disponible pour les gestionnaires et administrateurs seulement) ou 5 (le type est disponible uniquement pour les administrateurs).

La table grr_j_type_area

Table de jointure des type des réservation désactivés dans les domaines

• id_type identifiant du type de réservation

• id_area identifiant du domaine

La table grr_j_mailuser_room

Table de jointure des utilisateurs à avertir par mails automatiques

• login : identifiant de l'utilisateur à avertir par mail automatique

• id_room : identifiant de la ressource pour laquelle l'utilisateur doit être averti.

La table grr_j_user_area

Table de jointure des utilisateurs ayant accès aux domaines restreints

• login : identifiant de l'utilisateur

• id_area : identifiant du domaine restreint auquel l'utilisateur a accès.

La table grr_j_user_room

Table de jointure des utilisateurs gestionnaires de ressources.

• login : identifiant de l'utilisateur

• id_room : identifiant de la ressource dont l'utilisateur est gestionnaire.

La table grr_j_useradmin_area

Table de jointure des utilisateurs administrateurs de domaines.

• login : identifiant de l'utilisateur

• id_area : identifiant du domaine dont l'utilisateur est administrateur.

grr_j_useradmin_site

Table de jointure des utilisateurs administrateurs de sites.

• login : identifiant de l'utilisateur

• id_site : identifiant du site dont l'utilisateur est administrateur.

La table grr_j_site_area

Table de jointure qui relie les domaines aux sites

• id_site : identifiant du site

• id_area : identifiant du domaine

La table grr_log

Table du journal des connexions

• LOGIN : login de l'utilisateur

• START : date et heure de début de la session

• SESSION_ID : numéro de la session

• REMOTE_ADDR : adresse IP de l'utilisateur

• USER_AGENT : navigateur de l'utilisateur

• REFERER : provenance du lien sur GRR

• AUTOCLOSE : 0 si l'utilisateur a normalement terminé sa session, 1 sinon

• END : date et heure de fin de la session

La table grr_setting

Cette table contient un certain nombre de paramètres.

• NAME : nom du paramètre

• VALUE :valeur du paramètre

La table grr_calendar

Cette table contient les valeurs UNIX des jours hors réservation (jours « fériés »).

• DAY : jour férié

La table grr_overload

Cette table contient les noms et types des champs additionnels pour un domaine donné.

• id : identifiant du champ additionnel,

• id_area : identifiant du domaine auquel ce champ additionnel s'applique,

• fieldname : nom du champ additionnel,

• fieldtype : type du champ additionnel.

• fieldlist : liste des choix possibles séparés par le caractère "|" dans le cas ou fieldtype est égal à "list".

• obligatoire : le remplissage du champ additionnel est  obligatoire ("y") ou non ("n"),

• affichage : le champ apparaît ("y") ou non ("n") dans les différents plannings (journée, semaine, mois).

La table grr_entry_moderate

Table de sauvegarde des informations de la table grr_entry des réservations après modération.

• motivation_moderation : description : motif de la décision,

• login_moderateur : identifiant de l'utilisateur ayant procédé à la modération,

• id, start_time, end_time, entry_type, repeat_id, room_id, timestamp, create_by, beneficiaire, beneficiaire_ext, name, type, description, statut_entry, overload_desc, moderate, : voir la table grr_entry pour la signification de chacun de ces champs.

 

La table grr_calendrier_jours_cycle

Table des "jours cycle"

• DAY : valeurs UNIX du "jour cycle"

• Jours : numéro du "jour cycle

 

La table grr_correspondance_statut

Table de correspondance entre le statut dans GRR et la fonction LDAP (cas d'un SSO CAS)

• id : identifiant

• code_fonction : identifiant du profil de l'utilisateur dans LDAP

• libelle_fonction : intitulé du profil de l'utilisateur dans LDAP

• statut_grr : statut dans GRR

 

8.2.Le schéma de la base données

Le schéma ci-dessous permet d'appréhender globalement le schéma de la base de données de GRR.
Remarque : ce schéma ne prétend à aucune rigueur et a juste vocation à donner une idée d'ensemble des tables et des interactions entres elles.

9.Annexe 1 : Configurer CAS pour la récupération d'attributs LDAP

Annexe 1 : Configurer CAS pour la récupération d'attributs LDAP

9.1.Introduction

Quand le SSO CAS est activé dans GRR; il y a deux moyens de récupérer les attributs LDAP d'un utilisateur (email, nom, prénom)

• soit en utilisant la possibilité qu'un serveur SSO CAS offre de pouvoir envoyer à une application des attributs ldap;

• soit en configurant l'annuaire LDAP dans GRR de façon que GRR interroge lui-même l'annuaire LDAP pour essayer de récupérer les attributs.

La première méthode est plus difficile à mettre en oeuvre mais permet, selon la structure de l'annuaire de récupérer, en plus des email, nom et prénom, la langue préférée de l'utilisateur ainsi que le profil qui peut alors être associé au statut dans GRR (simple visiteur, utilisateur, administrateur).

C'est cette première méthode que nous allons décrire maintenant.

9.2.Configuration du serveur CAS pour la diffusion des attributs LDAP

Rappel

GRR supporte l’authentification SSO avec CAS mais celui-ci est livré de base sans la librairie phpCAS qui permet de mettre en place ce mécanisme.

La première étape consiste donc à télécharger la librairie phpCAS à l'adresse suivante :

http://www.ja-sig.org/wiki/display/CASC/phpCAS

Il faut ensuite décompresser le contenu de l’archive dans un répertoire nommé « CAS » à l’intérieur du répertoire de l’application web GRR.

Par défaut, CAS n'envoie à GRR que le nom de l'utilisateur lors de la validation du ticket.

Afin de mettre en place la récupération dans GRR d'attributs des utilisateurs depuis l’annuaire LDAP, il est nécessaire de modifier le fichier \WEB-INF\deployerConfigContext.xml du serveur CAS.

Modification du bean attributeRepository

Dans le fichier deployerConfigContext.xml, repérer le bean « attributeRepository ». Ce bean indique à CAS tous les attributs qui devront être envoyés à GRR.

La modification consiste à ajouter les attributs que l’on souhaite récupérer.

Ci-dessous, par exemple on configure une récupération dans LDAP des attributs : sn, givenName, ENTPersonFonction, preferredLanguage et mail :

<bean id="attributeRepository" class="org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao">
 ...
 <property name="ldapAttributesToPortalAttributes">
 <map>
 <entry key="sn" value="user_nom_ldap"/>
 <entry key="givenName" value="user_prenom_ldap" />
 <entry key="ENTPersonFonction" value="user_code_fonction_ldap" />
 <entry key="ENTPersonFonction" value="user_libelle_fonction_ldap" />
 <entry key="preferredLanguage" value="user_language_ldap" />
 <entry key="mail" value="user_mail_ldap" />
 ...
 </map>
 </property>
</bean>

Modification du bean serviceRegistryDao

Dans le fichier deployerConfigContext.xml, repérer le bean «serviceRegistryDao» et modifiez le pour qu'il ressemble à l'exemple ci-dessous (en l'adaptant à votre situation).

<bean id="serviceRegistryDao" class="org.jasig.cas.services.InMemoryServiceRegistryDaoImpl">
  <property name="registeredServices">
    <list>
      <bean class="org.jasig.cas.services.RegisteredServiceImpl"
         p:id="1"
         p:description="Acces GRR"
         p:serviceId="*://*.nom_du_site.fr/GRR/**"
         p:name="GRR"
         p:theme="default"
         p:allowedToProxy="true"
         p:enabled="true"
         p:ssoEnabled="true"
         p:anonymousAccess="false">
        <property name="allowedAttributes" value="uid,sn,givenName,mail,ENTPersonFonctions,prefererredLanguage" />
      </bean>
    </list>
  </property>
</bean>

Remarques : l’élément qui permet à CAS de faire la différence entre GRR et les autres applications est le serviceId, qui est un champ permettant d’expliquer à CAS quelle est la forme de l’url d’accès à l’application GRR ;

L’élément allowedAttribute permet d’énumérer tous les attributs qui devront être renvoyés par CAS pour cette application.

9.2.Configuration de GRR

Le serveur CAS envoie donc à GRR Les valeurs suivantes :

user_nom_ldap, user_prenom_ldap, user_code_fonction_ldap, user_libelle_fonction_ldap, user_language_ldap et user_mail_ldap.

L'étape suivante consiste à configurer le fichier « include/config_CAS.inc.php ».

Remarque :

Le fichier « include/config_CAS.inc.php » n'existe pas dans le paquetage de GRR. En revanche, un fichier « config_CAS.inc.php.ori » est présent dans le répertoire « include ». Commencez par renommer ce fichier en config_CAS.inc.php. De cette façon, lors d'une mise à jour de GRR, vous ne risquez pas d'écraser ce fichier « config_CAS.inc.php » car il n'est pas présent dans l'archive.

Idéalement, GRR peut récupérer les 5 valeurs suivantes :

• le nom de l'utilisateur

• le prénom de l'utilisateur

• la langue de l'utilisateur

• le statut de l'utilisateur

• le mail de l'utilisateur

La correspondance entre ces champs et les valeurs envoyées par le serveur CAS (user_nom_ldap, user_prenom_ldap, user_code_fonction_ldap, user_libelle_fonction_ldap, user_language_ldap et user_mail_ldap) se fait de la manière suivante :

Par défaut, le fichier « include/config_CAS.inc.php » comporte les lignes suivantes :

$user_nom=recuperer_nom(phpCAS::getAttribute('user_nom_ldap'));
$user_prenom=recuperer_prenom(phpCAS::getAttribute('user_prenom_ldap'));
$user_language=recuperer_language(phpCAS::getAttribute('user_language_ldap'));
$user_code_fonction=recuperer_code_fonction(phpCAS::getAttribute('user_code_fonction_ldap'));
$user_libelle_fonction=recuperer_libelle_fonction(phpCAS::getAttribute('user_libelle_fonction_ldap'));
$user_mail=recuperer_mail(phpCAS::getAttribute('user_mail_ldap'));

Explications :

• $user_nom : nom de l'utilisateur

• $user_prenom : prénom de l'utilisateur

• $user_language : langue de l'utilisateur

• $user_code_fonction : identifiant du profil de l'utilisateur dans l'annuaire LDAP

• $user_libelle_fonction : libellé du profil de l'utilisateur dans l'annuaire LDAP

• $user_mail : mail de l'utilisateur

Explication de la première ligne :

$user_nom=recuperer_nom(phpCAS::getAttribute('user_nom_ldap'));

• phpCAS::getAttribute('user_nom_ldap') est la variable envoyé par CAS.

• La fonction « recuperer_nom() » permet éventuellement de traiter cette variable pour récupérer la valeur utilisée dans GRR. En effet certains attributs peuvent nécessiter un traitement avant de pouvoir être utilisés dans GRR (voir ci-dessous).

• Le résultat est alors stocké dans $user_nom.

Traitement des attributs LDAP

Pour chacun des attributs LDAP envoyé par CAS à l'application GRR il est possible de personnaliser dans le fichier « include/config_CAS.inc.php », des fonctions de traitement de ces attributs.

Par exemple, dans le cas d'un ENT basé sur l'annuaire fédérateur de l'Education Nationale, les informations concernant le profil sont lues dans l’annuaire LDAP, dans l’attribut « ENTPersonFonctions ». Or ce champ multivalué est constitué de 5 valeurs. L'identifiant du profil et son libellé sont respectivement les 2ème et 3ème champs.

Dans le fichier « include/config_CAS.inc.php » figurent des exemples de code permettant de traiter ces champs multivalués.

Gestion de la correspondance profil / statut

Le profil de l'utilisateur (identifiant et libellé) est disponible grâce aux variables $user_code_fonction et $user_libelle_fonction.

Mais les profils de l'annuaire LDAP ne correspondent pas à priori aux différents statuts possibles dans GRR.

Une interface dans GRR permet donc à l'administrateur de faire correspondre le profil d’un utilisateur (appelé fonction dans l’annuaire LDAP), et le statut qu'il se verra attribué au sein de GRR à sa première connexion à GRR.

Cette interface n'est pas visible par défaut. L'activation de cette interface se fait dans le menu générale de configuration SSO.

Une fois cette fonctionnalité activée, l'administrateur peut compléter le tableau de correspondance.

Ainsi, à la première connexion d'un utilisateur externe authentifié par CAS, son statut dans GRR est déduit du tableau de correspondance.

Remarque : si le profil de l’utilisateur ne possède pas d’entrée dans la table de correspondance une nouvelle entrée est alors automatiquement créée pour ce profil et le statut par défaut (défini dans la page de gestion du SSO) lui est associé.

L’administrateur peut par la suite changer le statut associé à ce profil.

9.3.Autres paramètres de configuration de GRR dans un environnement CAS

Dans le menu « Configuration générale » (onglet « Sécurité / Connexions »)

• Il est possible de préciser une url de déconnexion : lorsqu'un utilisateur se déconnecte, après fermeture de la session, le navigateur est redirigé vers la page dont l'URL est spécifiée.

Dans le menu « Configuration SSO »

• Paramètre permettant d'afficher ou non le lien "Se déconnecter" dans le bandeau supérieur pour les personnes authentifiées à GRR par SSO.
• Paramètre permettant d'empêcher l'accès à la page de login : permet de forcer tous les visiteurs à s'authentifier via le SSO.
• Paramètre permettant d'interdire aux utilisateurs externes de modifier leur nom, prénom et email dans GRR.
• Possibilité de spécifier une adresse internet afin de faire apparaître, dans le bandeau supérieur, un lien "Portail d'accueil" pointant vers cette adresse.

Dans le fichier « include/config.inc.php »

1) Paramètre « $sso_super_admin » (prend la valeur false ou true) :

Mettre la valeur du paramètre $sso_super_admin à « true » pour rendre possible l'accès à la page login.php même si l'administrateur a coché dans l'interface en ligne le choix « Empêcher l'accès à la page de login ».

2) Paramètre « $sso_restrictions » (prend la valeur false ou true)

Mettre la valeur du paramètre « $sso_restrictions » à « true » permet de cacher dans l'interface de GRR l'affichage de la rubrique « Authentification et ldap »

9.4.CAS et GRR : gestion du Single Sign-Out

Ce paragraphe est mis à disposition dans la documentation à titre uniquement d'information et sa lecture n'est pas utile pour la configuration de l'environnement CAS dans GRR.

Le Single Sign-Out est implémenté dans phpCAS à partir de la version 1.0.0 : http://www.ja-sig.org/wiki/display/CASC/phpCAS+ChangeLog.

Le Single Sign-Out est implémenté dans CAS à partir de la version 3.0

Le Single Sign-Out est la possibilité d'utiliser le serveur CAS pour déconnecter automatiquement l'utilisateur sur toutes les applications à la fois.

Sans single sign-out, l'utilisateur est déconnecté de CAS, mais toutes les sessions ouvertes sur les applications en SSO restent ouvertes (ce qui pose un problème essentiel de sécurité...). En effet, après réception d'un ticket valide, les applications clients ne revérifient pas systématiquement que la session est toujours active sur le serveur d'authentification (cela génèrerait un flux inutile de requêtes).

Ce n'est que dans les versions les plus récentes de phpCAS que le single-sign out est pris en charge. Une application PHP utilise des connexions stateless (la connexion n'est pas maintenue au-delà de la requête initiale et de sa réponse), et il n'est donc pas possible de transmettre aux applications l'ordre de terminer une session lors d'un logout de CAS.

La manière dont phpCAS a réglé le problème est d'utiliser le nom de la session pour conserver le numéro de ticket CAS, et donc savoir quelle session interrompre. Concrètement, cela se passe de la manière suivante :

• connexion de l'utilisateur sur CAS
• authentification
• création d'un ticket CAS
• accès à l'application cliente (Grr)
• création par l'application d'un cookie de sesssion dont le nom contient le numéro de ticket
• utilisation de l'application
• retour au portail
• déconnexion (fin de la validité du ticket au niveau du serveur cas)
• le serveur CAS renvoie à toutes les applications enregistrées une requête de logout, qui contient le numéro de ticket
• l'application cliente intercepte cette requête de logout grâce à la méthode phpCAS::handleLogoutRequests(false); (l'argument 'false' est là pour ne pas effectuer de vérification du client duquel provient la requête de logout)
• l'interception de logout termine la session de l'utilisateur
• lorsque l'utilisateur essaie de se connecter à nouveau sur l'application cliente avec son cookie de session, l'application détecte bien que le cookie ne correspond plus à une session valide

Remarque : pour avoir une session qui contient le numéro de ticket, il est indispensable que ce soit phpCAS qui s'occupe d'initier la session php, et non Grr lui-même. C'est à cela que sert le dernier argument "true" de :

phpCAS::client(CAS_VERSION_2_0,$serveurSSO,$serveurSSOPort,$serveurSSORacine,true);

Ainsi, phpCAS gére lui-même la création du cookie de session.

Voir aussi :

http://wiki.esco-portail.org/index.php/Documents:Single_Sign_Out#Traitement_de_la_requ.C3.AAte_via_handleLogoutRequest.28.29_de_phpCAS