- Dans le cadre du stage effectué dans le département Informatique à l'INT à Evry (France) nous avons abordé le support de sources d'authentification multiples pour les plate-formes de travail collaboratif se basant sur phpGroupWare comme PicoLibre, ProGet. - L'approche proposée et développée dans le cadre du stage est l'utilisation Shibboleth pour créer la fédération d'identités et l'utilisation de l'authentification de serveur Web(par exemple le mod_auth_ldap, mod_auth_mysql. - L'Intégration de Shibboleth permet d'offrir l'authentification de type SSO (Single Sign On), l'autorisation.. - L'adapteur peut devenir utile également pour d'autres sources d'authentification par Apache(via par exemple mod_auth_ldap, mod_auth_mysql), Cet adapteur est intégré dans le code-base standard du module APIs de la nouvelle version 0.9.18 de phpGroupWare.. - L'intégration de Shibboleth dans phpGroupWare sera utilisé par les plates formes PicoLibre dans la fédération d'identité de GET/INT.. - 2.5 Le choix de Shibboleth...16. - Chapitre 3 .Shibboleth...18. - 3.1 Composants de Shibboleth. - 3.2 Assertions SAML de Shibboleth...20. - 3.3 Fonctionnement de Shibboleth avec WAYF et SSO...21. - 3.4 Fédération de Shibboleth...24. - 4.2.1 Utiliser l'authentification via Apache dans le phpGroupWare. - 4.2.3 Additions à phpGroupWare...31. - Figure 1: Architecture générale de phpGroupWare...9. - Figure 9: Modèle Shibboleth...16. - Figure 12: Fonctionnement de Shibboleth. - Le cadre du stage est effectué dans le projet structurant PFTCR(Plate-Formes de Travail Collaboratif pour la Recherche) de l'équipe de systèmes répartis dans le département Informatique à l'INT. - Cela permettra idéalement de prescrire les adaptations nécessaires dans le système d'informations GET, et d'implémenter les adaptations requises du côté phpGroupWare.. - L’état de l’art est réalisé dans le chapitre 2, il donne une vue générale sur la plate forme PicoLibre et ses logiciels. - Une description de Shibboleth ses composants, les fonctionnalités de Shibboleth, et de la. - fédération d'identités de type Shibboleth sont présentées dans le chapitre 3. - Il est indépendant de la plate forme parce que il est codé en php. - Les applications de bases de phpGroupWare proposées dans le package par défaut sont un gestionnaire d'applications, client mail (POP3, IMAP. - local, qui a été indiqué par l'administrateur dans la phase de configuration du serveur phpGroupWare, à la fin de la procédure d'installation. - Une instance de PicoLibre est installée à l'AUF, pour permettre le développement de logiciels dans le cadre du programme Centres Linux et Logiciels Libres pour le Développement (C3LD).. - L’architecture de la plupart des produits de SSO repose sur les concepts de base qui sont montrés dans la figure4. - Le serveur d’authentification délivre des tickets au client (maintient de la session d’authentification) et aux applications (transmission de l’identité de l’utilisateur). - Le serveur d’authentification est l’élément central du système de SSO puisqu’il assure l’authentification de l’utilisateur, la persistance de sa connexion et la propagation de l’identité de l’utilisateur auprès des applications.. - Cela permet également de centraliser la gestion de la politique de sécurité d'offre service SSO. - Lorsqu'il accède à un service de la fédération, l'utilisateur est authentifié par son établissement. - 2.5 Le choix de Shibboleth. - Dans le contexte du support de sources d'authentification multiples pour les plate-formes de travail collaboratif ProGET, PicoLibre les fonctionnalités offertes par Shibboleth. - L'établissement gère ses utilisateurs de façon indépendante des autres établissements de la fédération. - Il se paramètre pour définir les relations entre les acteurs de la fédération en proposant des scénarios adaptés au contexte universitaire et les connecteurs avec le système d'information. - La version 2.0 de Shibboleth sera compatible avec SAML 2.0. - Le concept de base de Shibboleth est basé sur trois composants: le fournisseur d'identité (IdP), le fournisseur de service (SP) et le service de découverte(WAYF).. - Le fournisseur de services (Service Provider ou SP) est une partie de Shibboleth écrit en C/C++ qui gère des ressources accédées par les utilisateurs dans la fédération. - Le demandeur d’attributs est chargé de la récupération des attributs des utilisateurs auprès de l’IdP. - En général l'IdP est une partie dans le système d’information (SI) de l'établissement et est un membre dans la fédération.. - C’est lui qui, par exemple, demande à l’utilisateur un couple user/password, puis le valide auprès de la base d’authentification du SI.. - Les attributs de l’utilisateur sont récupérés dans le SI de l’établissement, plusieurs sources pouvant être envisagées (annuaire LDAP, base de données…).. - 3.2 Assertions SAML de Shibboleth. - 3.3 Fonctionnement de Shibboleth avec WAYF et SSO. - Les paramètres de la demande d'authentification (montrés dans l'étape précédente) sont codés dans des champs cachés.. - (5) L'utilisateur choisit un IdP à partir de la liste. - Trois paramètres sont apposés à l'URL de la redirection(Voir dans phase 7).. - Pour automatiser la soumission de la forme, la ligne suivante du Javascript (ou son équivalent) peut apparaître dans le document HTML qui contient le formulaire. - <?xml version="1.1". - <saml:NameIdentifier. - Format="urn:mace:shibboleth:1.0:nameIdentifier". - <saml:AttributeDesignator. - AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"/>. - 3.4 Fédération de Shibboleth. - – soit, par défaut, en mode auto-create qui est déclaré dans la phase de la configuration phpGroupWare dès que l'on installe phpGroupWare.. - L'administrateur peut ainsi modifier le profil d'utilisateur, selon le rôle d'un utilisateur défini dans le schéma d'organisation d'un établissement.. - Dans le cadre de travail on suppose que le serveur Apache est standard.. - On a besoin toujours également d'un service SSO avec d'autres applications déployées partout dans le système d'information, en dehors de la plate forme. - Il est nécessaire de développer un nouvel adapteur d'authentification de phpGroupWare pour la combinaison de serveur Aapche + de Shibboleth.. - les utilisateurs de PicoLibre avec un compte dans le phpGroupWare, qui accèdent à PicoLibre, et. - ● s'ils ont également un compte dans la fédération de Shibboleth alors ils peuvent faire un mapping de l'identité de Shibboleth vers leur compte de PicoLibre.. - ● sinon (pour des personnes externes de la fédération), Ils peuvent accéder à PicoLibre en déviant le service SSO de Shibboleth.. - les nouveaux utilisateurs externes de la fédération, qui peuvent demander l'enregistrement dans phpGroupWare.. - Dans la phase d'implémentation un adapteur a été développé dans phpGroupWare qui permet à phpGroupWare de participer à la fédération de Shibboleth. - Au lieu de cela, il dépendra de la variable d'environnement REMOTE_USER de la session de Apache. - Il faut utiliser d'autre valeur pour REMOTE_USER (par exemple mail, numéro d'identité, numéro de passeport) qui est censé être une valeur unique parmi tous les IdP de la fédération d'identité.. - – Mapping trivial, dans le cas où REMOTE_USER est une identification unique dans la fédération des identités.. - – Mapping par table, dans le cas où chaque utilisateur n'a pas nécessairement une identification unique qui peut être identifiée dans le système de l'information de l'entreprise.. - Après avoir passé la phase d'authentification de Shibboleth le script login.php réalisera la phase de mapping et créera la session de travail dans phpGroupWare.. - Le script create_mapping.php fournit la fonction pour créer un nouveau mapping si l'utilisateur a déjà un compte dans le phpGroupware. - Dans le cas où le mapping trivial est un succès pour la plupart des utilisateurs, mais qu'il échoue quand même pour un nombre restreint de cas, un mapping « séquentiel » pourrait être activé. - Par des directives spécifiques de configuration dans le serveur Apache, on peut concevoir différents points d'accès pour la même application Web , et choisir le contrôle d'accès par Apache obligatoire (appelé full-apache), ou facultatif (appelé semi-apache).. - On accordera l'accès qu'aux utilisateurs déjà connus de la fédération d'identité . - Alors la configuration de la partie spécifique pour l'authentification via Apache devrait être disponible dans un sous-répertoire, par exemple /phpgroupware/phpgwapi/inc/sso. - Avec l'addition de la phase de mapping nécessaire, phpGroupware peut maintenant utiliser les services de SSO disponibles dans l'infrastructure de Shibboleth. - Dans la configuration de Apache on utilisera l'authentification de Shibboleth:. - Dans le cadre du stage on a proposé une méthode pour intégrer phpGroupWare et Shibboleth pour permettre l'utilisation de mécanismes de SSO dans phpGroupWare et de supporter des sources d'authentification multiples en utilisant la fédération d'identité.. - Il y a aussi un adapteur pour la version courante de PicoLibre se basant sur phpGroupWare 0.9.16 pour tester dans la fédération d'identité de GET/INT.. - Par des directives spécifiques de configuration dans le serveur Apache, on peut concevoir différents points d'accès pour la même application Web, et choisir le contrôle d'accès par Apache obligatoire (appelé full-apache), ou facultatif (appelé semi-apache).. - Dans un contexte d'utilisation de Shibboleth pour PicoLibre, on a ajouté l'application picolibre_twiki pour intégrer Twiki dans PicoLibre(en détail dans l'annexe C).. - [1] Site du projet PicoLibre, http://www.picolibre.org/.. - [2] Site du projet phpGroupWare, http://www.phpgroupware.org/.. - [3] Site du projet Shibboleth, http://shibboleth.internet2.edu/.. - [8] Site de la fédération de CRU, http://federation.cru.fr/.. - <saml:Assertion. - <saml:Conditions. - <saml:AuthenticationStatement. - <saml:Attribute. - AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">. - Dans ce paquet on ajoute la classe auth dans le fichier auth_remoteuser.inc.php qui correspond à la méthode d'authentification par Apache. - seulement la classe basse dans le processus l'authentification dans le phpGroupware.. - Pour la phase de mapping on ajoute la classe mapping dans le fichier mapping.inc.php. - Il hérite de la classe mapping_ qui est basé sur le compte existant dans le phpGroupware, pour faire le mapping trivial et pour valider le compte.. - class auth : auth_apache.inc.php class mapping. - mapping_ldap.inc.php class mapping. - mapping_sql.inc.php. - picolibre_twiki/index.php. - picolibre_twiki/inc/admin.inc.php. - est ajouté dans le group TWikiAdminGroup de TWiki). - Dans le fichier .htaccess de TWiki on configure l'accès via apache/LDAP à ces scripts. - On préfère que les membres du groupe Admins de Picolibre soient les membres de Main.TWikiAdminGroup de TWiki, alors il faut ajouter le groupe Admins dans le liste des membre de TWikiAdminGroup.