authentification

Authentification

Service eduroam

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 05/03/13
  • Correction mineure : 31/05/13
  • Auteur : Denis Mirassou (Université Toulouse 3 Paul Sabatier, DTSI, département Système Réseau et Télécom)
  • Responsable thématique : David Rousse
Mots-clés

Service eduroam

  • http://www.renater.fr/eduroam
  • Type de ressource : service
  • Date de publication du document ou de l'événement : 2003
  • Auteur(s) ou responsable(s) : RENATER
  • Contact pour plus d'informations : support-eduroam_AT_support.renater.fr

Ce document a été rédigé par Denis Mirassou (Université Toulouse 3), avec l'aide de Dominique Launay (RENATER), Alain Péan (CNRS/LPN), Jean-Pierre Feuillerat (CNRS/DSI), Vincent Carpier (Université de la Réunion), Xavier Marty (Université Toulouse 1) et Erwann Thoraval (IRCAM Paris). Il a été relu par Patrice Hérault (CRI, Université de Marne-la-Vallée).

Description du service :

eduroam, pour Education Roaming, est un service de mobilité d'authentification international proposé par RENATER (pour la France) utilisable notamment pour accéder de manière sécurisée et authentifiée à l'Internet en Wi-Fi depuis tout établissement d'Education ou de Recherche ayant souscrit et déployé le service.

En pratique, la procédure d'authentification utilisateur sur le Wi-Fi est établie de façon sécurisée (cryptée) et transparente (même login et mot de passe) entre l'établissement d'origine de l'utilisateur et l'établissement d'accueil. Lors de ses déplacements (en France et à l'étranger) dans un autre établissement ou laboratoire, l’authentification d’un utilisateur est faite par son établissement de rattachement au travers d’une hiérarchie de serveurs RADIUS selon le standard 802.1x.

Avec plus de 160 établissements Français impliqués à ce jour et un millier d'usagers par jour en moyenne pour ce service, eduroam représente un service pratique d’accès internet via le Wi-Fi en déplacement en France ou à l'étranger (plus de 50 pays membres, 5000 lieux couverts en Europe).

Modalités d'accès au service :

Le service étant administré par Renater pour la France, il faut faire une demande de modification d’agrément via l'interface SAGA.

L'établissement désireux de rejoindre la communauté eduroam doit alors indiquer un contact technique local eduroam, l'url d'une ressource de support utilisateur local ainsi que quelques paramètres techniques (compte utilisateur eduroam local pour le monitoring national, etc...).

On ne peut avoir accès à ce service que si l'on est membre de la communauté éducation / recherche.

Clients/utilisateurs du service :

Les utilisateurs du service sont les personnels administratifs/enseignants/chercheurs et étudiants des établissements d'éducation et de recherche.

Fournisseur du service :

Au niveau national, c'est RENATER qui gère les RADIUS centraux de la fédération nationale eduroam. Les fédérations nationales des pays participants sont regroupées en confédérations, qui constituent ensuite des confédérations régionales (Amérique du Nord, Asie-Pacifique, Europe). La gouvernance mondiale est assurée par le comité de la gouvernance mondiale eduroam constitué de membres des confédérations régionales.

L'association Géant gérant le réseau pan-Européen de l'éducation et de la recherche assure les rémunérations des membres de la gouvernance mondiale ainsi que la logistique de secrétariat.

Technologie d'implémentation du service :

L'implémentation du service est assez simple et repose sur le standard 802.1x. Il suffit d'un service RADIUS (implémentable à l'aide de logiciels libres, comme FreeRadius, ou de logiciels commerciaux) sur le site client ayant connaissance des utilisateurs locaux (fichier local, annuaire LDAP, SGBD SQL, relais RADIUS, ...). Celui ci aura pour rôle de retransmettre (rôle de relais ou proxy) les requêtes des utilisateurs "externes" ou "invités" vers les RADIUS nationaux et de répondre aux requêtes de ces mêmes RADIUS lorsqu'un utilisateur local est en déplacement sur un site distant. A noter que chaque établissement doit conserver les journaux de connexion selon la réglementation en vigueur.

Le cas échéant (déplacement à l'étranger), les RADIUS nationaux impliqués se relaieront les requêtes des utilisateurs.

Dans le cas d'un déplacement à l'étranger sur un autre continent, les RADIUS régionaux (Europe, Asie-Pacifique) serviront d'intermédiaires aux radius nationaux.

Service Level Agreement (SLA) du service :

En France, le service RADIUS central est redondé (GIP-Renater Paris et Université de Strasbourg) et opéré par RENATER.

Les RADIUS des confédérations régionales sont également redondés : Danemark (UNI-C) et Pays-Bas (Surfnet) pour la confédération régionale Européenne, Australie et Hong-Kong pour la confédération Asie-Pacifique.

Coût du service :

Intégré dans les coûts payés par les établissements pour RENATER pour ce qui concerne le service RADIUS national, à la charge des établissements participants pour le service RADIUS eduroam de chaque établissement.

Fonctions annexes du service :

Un service de test est en place permettant de préparer la mise en place du service sur son établissement. Un nouvel établissement passe en production lorsque la phase de test est positive.

Au niveau national, la liste des établissements membres de la communauté est consultable en ligne. Une carte nationale est également disponible.

Chaque site est supervisé ce qui permet d’être averti en cas de panne de l'infrastructure locale.

Le site eduroam français propose des exemples de fichiers de configuration RADIUS, des recommandations de sécurisation réseau, des affichettes pour la signalétique éventuelle. Une liste de diffusion électronique est également disponible pour les échanges entre les correspondants eduroam français.

Une application Android (non supportée par eduroam) géolocalise les lieux couverts par le service eduroam :
https://play.google.com/store/apps/details?id=net.ja.android.eduroamcompanion

Limitations du service :

  • Pas d'accès de type portail captif.
  • Respect obligatoire de la charte eduroam.
  • Pas de gestion de "profil" de connexion, de droit d'accès.

Services concurrents :

A priori, il n'existe pas vraiment de service concurrent si l'on considère le périmètre géographique d'utilisation d'eduroam (mondial). Néanmoins, on peut citer quelques services de nature équivalente mais de périmètres (géographique et population utilisatrice) plus réduits :

  • Eduspot : ensemble de recommandations nationales favorisant l'usage de réseau Wi-Fi de type portail captif en Enseignement Supérieur et Recherche : ssid commun, fédération d'identité Education-Recherche pour la mobilité d'authentification.
  • Midi-Pyrénées Wi-Fi (MiP-Wifi), mobilité d'authentification Wi-Fi (accès de type Portail captif uniquement) entre établissements d'enseignement supérieur et de recherche en Midi-Pyrénées et le CROUS Toulouse (accès internet des étudiants en résidence universitaire).

Commentaires et retours d'expériences sur le service :

  • Il est important que l'utilisateur du service eduroam valide la configuration Wi-Fi eduroam de son terminal dans son établissement d'origine avant de partir en déplacement.
  • Difficulté, pour un utilisateur, d'obtenir du support en déplacement.

URLs pour plus d'informations :

Fiche dév Ens Sup - Recherche
  • Création ou MAJ importante : 12/09/12
  • Correction mineure : 12/09/12
Mots-clés

myProMS : validation, quantification et partage des données de spectrométrie de masse protéomique

Ce logiciel a été développé (ou est en cours de développement) dans la communauté de l'Enseignement Supérieur et de la Recherche. Son état peut être variable (cf champs ci-dessous) donc sans garantie de bon fonctionnement.
  • Site web
  • Système : UNIX-like
  • Version actuelle : 2.7.2 - 06/09/2012
  • Licence(s) : Licence propriétaire - Utilisation académique libre.
  • Etat : diffusé, stable
  • Support : maintenu, développement en cours
  • Concepteur(s) : Patrick Poullet, Guillaume Arras, Florent Yvon, Falaye Camara
  • Contact concepteur(s) : myproms@curie.fr
  • Laboratoire(s), service(s)... : INSERM-U900

 

Fonctionnalités générales du logiciel

myProMS est un outil multi-utilisateur (serveur web et base de données) dédié à la gestion, au traitement et au partage des données d'identifications protéiques issues de la spectrométrie de masse. Il accepte les résultats des moteurs de recherche Mascot (avec lequel il communique directement) et Proteome Discoverer.

Les données importées sont organisées en projet dont l'accès est dépendant des droits de chaque utilisateur. Les données d'identification peuvent être validées manuellement ou automatiquement selon différents critères. Une fois validées, les données deviennent accessibles aux différents collaborateurs du projet qui peuvent les analyser pour en extraire des informations biologiques pertinentes. Des fonctionnalités telles que la comparaison (de groupes) d'échantillons et l'enrichissement d'annotations sont proposées pour aider les utilisateurs dans l'interprétation des résultats.

Contexte d’utilisation du logiciel

myProMS est utilisé par les plates-formes et laboratoires de spectrométrie de masse qui souhaitent centraliser, traiter et partager avec leurs collaborateurs les résultats d'identification générés par les moteurs de recherche tels que Mascot et Proteome Discoverer.

Publications liées au logiciel
Fiche logiciel validé
  • Création ou MAJ importante : 30/03/12
  • Correction mineure : 19/08/13
Mots-clés

KeePass : gestionnaire de mots de passe

Description
Fonctionnalités générales

KeePass est un logiciel de gestion de mots de passe pour une équipe ou un projet donné.

KeePass a reçu la certification CSPN de l’ANSSI (pour la version portable).

L'idée est de centraliser dans un fichier unique chiffré un ensemble d'informations de connexion (nom d'utilisateur, mot de passe...). L'accès à ce fichier peut se faire en parallèle par différents membres de l'équipe, KeePass gère la concurrence d'accès.

C'est donc une alternative pratique et sécurisée aux habituels fichiers texte ou tableurs, protégés en général par des droits d'accès au niveau OS (et par un mot de passe supplémentaire parfois pour les tableurs).

L'outil peut également servir comme gestionnaire de mots de passe personnels : un utilisateur peut ainsi gérer avec cet outil ses nombreux mots de passe pour les multiples sites auxquels il se connecte. Il permet ainsi d'utiliser des mots de passe aléatoires, ce qui est un gage important de sécurité. Il existe une version portable pour clé USB qui permet d'utiliser facilement sa base de mots de passe à partir de différentes machines.

Autres fonctionnalités

Divers mécanismes ont été implémentés pour se protéger, autant que possible, des keyloggers.

Interopérabilité

Les informations gérées par KeePass peuvent être importées et exportées dans différents formats ouverts, comme CSV ou XML, ou via des formats propriétaires d'autres logiciels du même genre, comme indiqué à cet endroit http://keepass.info/help/base/importexport.html.

Contexte d'utilisation dans mon laboratoire/service

KeePass est utilisé pour gérer les différents logins/mot de passe pour un projet donné. Cela permet de partager de manière sécurisée ces informations entre les membres d'une même équipe projet, interne au service ou avec un prestataire. Pour éviter de partager un secret entre plusieurs personnes, il est possible d'utiliser l'extension CertKeyProvider qui offre une protection par certificat au lieu d'un mot de passe.

Keepas est l'outil idéal pour n'avoir qu'un seul mot de passe à retenir, ce qui permet d'en choisir un robuste, et utiliser sur les différentes applications ou sites auxquels on se connecte des mots de passe extrêmement robustes car longs et aléatoires .

Limitations, difficultés, fonctionnalités importantes non couvertes

Une version native dédiée à Linux et MacOS (sans Mono) serait appréciable, même si des contributeurs annexes en ont mis des versions à disposition.

Environnement du logiciel
Plates-formes

Le produit est développé en .net. Il s'exécute nativement sous MS Windows et via l'émulateur Mono (Mono version 2.6 et ultérieures) pour Linux ainsi que MacOS.

Des contributeurs annexes ont mis à disposition des versions natives pour divers OS y compris pour des smartphones, le tout regroupé sur http://keepass.info/download.html.

Autres logiciels aux fonctionnalités équivalentes
Environnement de développement
Type de structure associée au développement

Le développement est géré par un particulier, Dominik Reichl, dont le site personnel est http://www.dominik-reichl.de/index.html.

Eléments de pérennité

Diverses récompenses ont été décernées à cet outil, comme le mentionne la page http://keepass.info/ratings.html.

Environnement utilisateur
Liste de diffusion ou de discussion, support et forums

Un forum est disponible, hébergé sur le SourceForge du projet : http://sourceforge.net/projects/keepass/forums.

Documentation utilisateur

La page principale d'aide, en anglais, est http://keepass.info/help/base/index.html.

Divers (astuces, actualités, sécurité)

La distribution standard la plus pratique est la version portable qui se présente sous forme de fichier ZIP. Une fois décompressée le ZIP dans un répertoire accessible à l'équipe projet, le partage se fait typiquement en positionnant des droits d'accès OS adaptés sur le dit répertoire.

L'utilisation du mode "master password" est la plus pratique. Il convient cependant de modifier une option de base afin de minimiser les risques d'attaques par force brute, en allant dans les options de la base de sécurité, onglet Sécurité, et en cliquant sur "1 second delay" (voir le détail sur http://keepass.info/help/base/security.html#secdic...).

A noter par ailleurs qu'une traduction en français de la distribution standard est présente à http://keepass.info/translations.html.

Contributions

Il est possible de développer des plugins en suivant la documentation http://keepass.info/help/v2_dev/plg_index.html.

Par ailleurs, à titre d'information, les codes sources de la version courante sont disponibles sur SourceForge, à http://downloads.sourceforge.net/keepass/KeePass-2....

Le développement se fait en C#.

Ecole (ANGD) 'Installation et configuration des logiciels libres de base, utiles à tout ASR d’un laboratoire' déc 2011

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 04/07/11
  • Correction mineure : 04/07/11

Ecole (ANGD) 'Installation et configuration des logiciels libres de base, utiles à tout ASR d’un laboratoire' déc 2011

Cette page reprend les informations de la page de référence de RESINFO, à consulter pour avoir plus d'informations.

La fédération de réseau RESINFO en partenariat avec la plateforme PLUME organise une formation nationale de 4 jours sur le thème des logiciels libres utiles à tout ASR : "Installation et configuration des logiciels libres de base, utiles à tout Administrateur Système et Réseau (ASR) d’un laboratoire"

Date et lieu

Cette formation aura lieu du lundi 5 Décembre 14H au Vendredi 9 Décembre 12H00 à la villa Clythia à Fréjus.

Inscriptions

Le nombre de stagiaires est limité à 30 avec une date limite des inscriptions fixée au 30 septembre. Pour s'inscrire, consultez le site de RESINFO

Public visé

Cette formation s’adresse à différents publics d’Administrateurs Système et Réseau (ASR) : soit nouvellement recrutés au CNRS, ou bien travaillant seuls dans leur laboratoire, ou encore à la recherche d’ une solution logicielle qu’ils n’ont pas pu mettre en œuvre par manque de temps.

Pour toute question sur cette formation, vous pouvez cp-angd-outils-libres-asr [at] listes [dot] resinfo [dot] org (écrire au comité d’organisation)

Objectif et description

Les ASR doivent reprendre ou mettre en place un ensemble de services qui proposent un environnement informatique opérationnel aux différents personnels techniques, administratifs et scientifiques d’unités de recherche. Or, il est souvent difficile de dégager le temps nécessaire pour choisir une solution logicielle, la tester, la mettre en production. En outre, parfois impliqué dans un contexte de mutualisation de laboratoires ou dans des projets transversaux qui regroupent différentes équipes, il devient nécessaire pour l’ASR de se reposer sur la connaissance d’un environnement technique et un système d’information communs.

L’objectif de cette formation est de faciliter l’intégration des ASR nouvellement recrutés en leur faisant découvrir un ensemble d’outils libres, performants et habituellement répandus dans les unités de recherche. Une méthodologie de mise en œuvre « pas à pas » sera présentée afin d’aboutir à un ensemble de services opérationnels. Cette formation est également l’occasion de faire connaître les logiciels de base utiles au quotidien dans le métier d’ASR qui sont présentés par le projet PLUME. Du fait de la grande souplesse d’administration qu’elle procure, l’usage de la virtualisation des systèmes devient quasiment indispensable dans les laboratoires. La formation débutera donc par la mise en place d’une plate forme de virtualisation qui servira en outre de support à la formation.

Cette plate forme permettra ensuite la mise en place progressive des différents services permettant l’authentification des utilisateurs, la centralisation de leur répertoire de travail, une solution de gestion de parc de PC, la gestion des impressions, la sauvegarde des serveurs et des données utilisateurs, la mise en place d’une infrastructure WEB sécurisée et le monitoring des serveurs et du réseau.

En fin de formation, le stagiaire aura tous les éléments nécessaires (savoir faire et documentation) pour pouvoir réinstaller et utiliser ces logiciels dans son environnement professionnel.

Programme prévisionnel

Tous les outils présentés ci-dessous sont décrits dans une fiche PLUME. Vous pouvez accéder à ces fiches, via le champ 'Fiches logiciel PLUME connexes dans le rectangle en haut à droite 'Fiche ressource'.

Lundi après-midi

  • Mise en place d’une plateforme de virtualisation ProxMox
  • TP d’installation et de configuration de Proxmox. création de machines KVM
  • Présentation d’OpenVZ. création de machine virtuelles openVZ
  • TP d’application à partir de ProxMox.

Mardi

  • OpenLDAP : présentation, configuration, extension de schéma, réplication, authentification client Linux.
  • TP : installation et paramétrage d’un serveur LDAP, authentification client Linux, mise en oeuvre de la réplication.
  • Synchronisation OpenLDAP et ActiveDirectory via un "script maison".

Mercredi

  • Samba couplé à un annuaire LDAP : contrôleur de domaine, centralisation des répertoires de travail utilisateur : TP d’application.
  • Cups : solution d’impression centralisée : TP d’application.
  • Mise en place d’une architecture Web sécurisée : Apache Reverse Proxy et ModSecurity  : présentation, retours d’expérience sur l’intégration de ModSecurity avec certaines applications.
  • TP : installation, configuration,publics / serveurs Intranet /serveurs cachés.

Jeudi

  • Sauvegarde de données avec BackupPC : présentation, fonctionnalités, ...etc.
  • TP d’application.
  • Gestion de parc : GLPI et OCS Inventory : présentation, installation des agents sur les clients, déploiement d’applications grâce aux agents.
  • TP fonctionnel pour illustrer les différents points cités ci-dessus.

Vendredi

  • Mise en place d’un système de supervision systeme et réseau : Nagios  : mise en place d’une configuration, sondes (SNMP, NRPE, NSCA), gestionnaire d’événements, escalades.
  • TP d’application : configuration, exemples de sondes pour surveiller différents types d’équipements (services, serveurs, commutateurs, imprimante), installation et configuration de NRPE.
  • Cacti : surveillance de l’activité de l’infrastructure informatique.
  • TP d’application.
  • Mise en place d’un système de supervision : Xymon.
  • TP d’application.
Fiche dév Ens Sup - Recherche
  • Création ou MAJ importante : 06/06/11
  • Correction mineure : 28/09/11
Mots-clés

SIGDEF : système de gestion et de distribution de licences de logiciels

Ce logiciel a été développé (ou est en cours de développement) dans la communauté de l'Enseignement Supérieur et de la Recherche. Son état peut être variable (cf champs ci-dessous) donc sans garantie de bon fonctionnement.
  • Système : UNIX-like, Windows
  • Version actuelle : 1.0 - 02/05/2011
  • Licence(s) : GPL, CeCILL - En étude.
  • Etat : utilisé en interne, en développement
  • Support : maintenu, sans développement en cours
  • Concepteur(s) : IRD - DSI - Service Informatique Scientifique : Stéphane DEBARD (conception), Geoffrey PASCAL (conception et développement)
  • Contact concepteur(s) : stephane.debard@ird.fr
  • Laboratoire(s), service(s)... : IRD

 

Fonctionnalités générales du logiciel

SIGDEF est une application informatique conçue de façon suffisamment générique pour répondre aux besoins de distribution et de gestion de licences. Cet outil est à destination des structures informatiques transversales. Il offre la possibilité, à travers deux interfaces (une pour les utilisateurs et une autre pour les administrateurs), d'effectuer des commandes d'activation de licences des logiciels et de les gérer simplement.

1- Interface utilisateur :

  • Identification (avec un annuaire, un fichier .htAccess) ou pas d'identification.
  • Choix du logiciel et de la version (gestion de commandes individuelles ou groupées), choix d'une demande d'installation par les services transversaux ou non.
  • Téléchargement des justificatifs des droits d'utilisation et des raisons d'accès (conventions, contrats, lettres ...).
  • Récapitulatif et acceptation de la charte d'utilisation.

2- Interface administrateur :

  • Validation de la commande (contrôle des informations sur l'utilisateur et ses choix).
  • Envoi de la licence, suite à une validation. La validation et l'envoi de la ou des licences peuvent être faits par un ou plusieurs services.
  • Synthèse et recherche des commandes en cours, validées ou envoyées.

Fonctionnalités non existantes et restant à développer :

  • Exportation des résultats bruts de la synthèse des commandes.
  • Requêtes spécifiques et croisement des données pour effectuer des bilans sur les commandes.
  • ...

Le logiciel est accompagnée d'une documentation complète : installation, utilisation et prise en main ainsi que le document de conception (base de données, workflow).

Contexte d’utilisation du logiciel

Les éditeurs de logiciels permettent contractuellement aux sociétés de mutualiser les achats de licences de plusieurs logiciels afin de diminuer les couts. Les sociétés délèguent la gestion d'un ensemble de licences à des services transversaux en informatique. Ces licences sont souvent des ID ou des fichiers d'activation fournis au gestionnaire sans les accompagner d'un outil de monitoring ou de gestion des commandes.

SIGDEF permet de répondre aux besoins de gestion et de déploiement d'un ensemble de logiciels à une large échelle.

Il est actuellement en production depuis 1 an pour la gestion de licences des logiciels des Systèmes d'Information Géographiques, impliquant deux services d'une DSI concernés dans la validation et l'envoi des licences à ses utilisateurs (200 utilisateurs).

Retour d'expérience d'une installation Shibboleth (Fournisseur d'identités)

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 19/07/10
  • Correction mineure : 19/12/11
Mots-clés

Retour d'expérience d'une installation Shibboleth (Fournisseur d'identités)

  • Type de ressource : article, compte-rendu
  • Date de publication du document ou de l'événement : Septembre 2009
  • Auteur(s) ou responsable(s) : Samuel Godey (CNRS/UREC)
  • Contact pour plus d'informations : samuel.godey@urec.cnrs.fr

La fiche

Document de base pour la rédaction de cette fiche

Date : JUIN-DECEMBRE 2009
Auteur : Samuel Godey (CDD Ingénieur d'étude de 6 mois)
Commanditaire : Patrice Koch (Directeur du CRI Université de Franche-Comté à Besançon)

Nature de la fiche

Cette fiche expose mon expérience sur l'installation du serveur fournisseur d'identités à l'université de Franche-Comté en 2009 et explique comment réaliser la mise à jour des briques logicielles nécessaires à son fonctionnement. La partie fournisseur de services ne sera pas traitée. Certaines informations dans ce texte ont été volontairement remplacées par des termes génériques. La configuration décrite ici est dépendante de l'architecture déjà en place à l'université de Franche-Comté, cependant la majorité des grandes structures utilise des technologies similaires. Les paramètres peuvent varier et sont certainement incompatibles avec votre situation. N'attendez de ce texte qu'un point de départ ou une source d'inspiration pour votre propre fournisseur d'identités.
Attention : ce document ne garantie pas le bon fonctionnement de votre installation.

Public destinataire

Cette note est à l'attention des administrateurs d'un service "fournisseur d'identités" avec la technologie Shibboleth. Veuillez prendre en considération que des connaissances sur LDAP ainsi que sur le service SSO CAS sont nécessaires pour suivre cette fiche, bien que ces services ne soient pas obligatoires pour utiliser Shibboleth. Le serveur fournisseur d'identités a été ajusté pour la fédération éducation-recherche de Renater. Je considère que les utilitaires GNU/Debian sont maîtrisés.

Complément d'information

Les supports techniques utilisés pour réaliser l'installation initiale ainsi que d'autres documentations pour l'installation sont disponibles à l'adresse : https://federation.renater.fr
Les noms des programmes mentionnés dans ce document peuvent se trouver sous la forme "logiciel-x.x.x.foo". Veuillez prendre en considération la version des programmes stables à jour afin d'adapter ce document dans le temps. Par exemple, remplacez x.x.x par 2.3.1 si la version du logiciel "logiciel" est actuellement en version 2.3.1.

Fiches PLUME en lien avec ce retour d'expérience

Pré-requis

Serveur :

  • Lenny/Debian/GNU/Linux

Application Debian non-free/contrib :

  • sun-java-6

Applications Debian main :

  • Apache 2.2
  • mod_ssl
  • mod_proxy_ajp
  • OpenSSL
  • NTP-server
  • Maven

Applications externes :

  • Apache-tomcat6
  • Shibboleth-idp
  • CAS-client

Plan

1) Introduction

1.1) Présentation des chemins d'accès
1.2) Sources des programmes

2) Procédure de mise-à-jour de la brique Shibboleth-idp

2.1) Procédure de mise-à-jour de la brique CAS-client

3) Procédure de mise-à-jour et d'installation de Tomcat
4) Configuration de Apache2.2 (lenny/debian)
5) Configuration de Shibboleth-idp

5.1) attribute-resolver.xml
5.2) attribute-filter.xml

6) Droits et sécurité

6.1) Shibboleth-idp
6.2) Tomcat
6.3) Certificat SSL Apache
6.4) Ajout des certificats non valides

1) Introduction

Veuillez considérer ce document comme un complément d'information pour un service "fournisseur d'identités" déjà en exploitation ou en test avec les briques LDAP et CAS configurées. Il est inutile d'essayer de réaliser une nouvelle installation en s'appuyant sur ce document. Si vous souhaitez installer ce service pour la première fois, il est conseillé d'utiliser les supports techniques fournis par Renater et la documentation officielle de Shibboleth :
- Support technique Renater : https://federation.renater.fr
- Documentation officielle de Shibboleth-idp : https://spaces.internet2.edu/display/SHIB2/

Dans le cas d'une mise-à-jour à cause d'un problème de sécurité ou encore parce que de nouvelles fonctionnalités sont nécessaires, il est important de conserver une copie de la configuration en cours et de procéder à une installation standard. Dès que la mise-à-jour est terminée, il faut vérifier vos fichiers de configuration et les remplacer si nécessaire par vos sauvegardes.

Remarque très importante : si vous hésitez à réaliser une mise-à-jour et que vous préférez utiliser un SNAPSHOT (point de sauvegarde instantanée) de votre machine virtuelle, vous devrez impérativement re-synchroniser l'horloge (avec ntptime) de la machine virtuelle. En effet, une petite dérive temporelle peut supprimer les sessions actives des utilisateurs. Dans le pire de cas, un redémarrage suffit est reste une valeur sûre.

1.1) Présentation des chemins d'accès

Je vous encourage à prendre en considération les chemins ci-dessous pour la lecture de ce document car je les ai déterminés arbitrairement. Par ailleurs, ces derniers peuvent ne pas être les plus judicieux. À vous de choisir des emplacements confortables.

Shibboleth-idp : /opt/shibboleth-idp
configuration de Shibboleth : /opt/shibboleth-idp/conf
certificats de Shibboleth : /opt/shibboleth-idp/credentials
méta-données (éducation-recherche) : /opt/shibboleth-idp/metadata

Données complémentaires :

fqdn shibboleth-idp : idp.mondomaine.fr
chemin source idp : /opt/shibboleth-identityprovider-x.x.x
chemin brique logicielle : /opt/shibboleth-identityprovider-x.x.x/lib/cas-client-core-x.x.x.jar
config compil : /opt/shibboleth-identityprovider-x.x.x/src/main/webapp/WEB-INF/web.xml
configuration Renater : https://services-federation.renater.fr/exemples/co...
méta-données Renater : https://services-federation.renater.fr/metadata/re...
certificat fédération Renater : https://services-federation.renater.fr/metadata/me...

Remarques :

idp.mondomaine.fr a besoin uniquement des ports 448 et 8448. Ils doivent être accessibles et sont nécessaires au bon fonctionnement du service.
À vos pare-feu : 448 et 8448 ouverts en entrée sur idp.mondomaine.fr

1.2) Sources des programmes :

shibboleth-idp url : http://shibboleth.internet2.edu/downloads/shibbole...
shibboleth-idp nom de l'archive : shibboleth-identityprovider-x.x.x-bin.zip
cas-client url : http://www.ja-sig.org/downloads/cas-clients/
cas-client nom archive : cas-client-x.x.x-release.zip
tomcat6 url : ftp://ftp.inria.fr/pub/Apache/tomcat/tomcat-6/v6.x...
tomcat6 nom archive : apache-tomcat-6.x.xx.tar.gz

2) Procédure de mise-à-jour de la brique Shibboleth-idp

  • Arrêtez shibboleth-idp :

    /etc/init.d/tomcat stop
  • Faites une copie de sécurité de la configuration :

    tar zcvf ~/shib-conf.tgz /opt/shibboleth-idp/conf
  • Téléchargez la dernière version :

  • Décompressez :

    jar -xf shibboleth-identityprovider-2.1.5-bin.zip
  • Éditez le fichier de compilation :

    Par commodité, je vous conseille de faire des copies de sécurité de la configuration d'accès à votre serveur CAS. À chaque nouvelle version de Shibboleth, vous devrez adapter le fichier de compilation "web.xml" avec votre système d'authentification. Le but est d'intégrer la brique "cas-client" pré-configurée sur votre réseau en ajoutant les informations locales de votre service.

    Exemple d'un fichier /opt/shibboleth-idp/cas_web.xml à adapter suivant vos besoins :

    <!-- CAS Filter Configuration -->
    <context-param>
    <param-name<serverName</param-name>
    <param-value>https://idp.mondomaine.fr</param-value>
    </context-param>
    <!-- CAS Authentication Filter -->
    <filter>
    <filter-name>CAS Authentication Filter</filter-name>
    <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
    <init-param>
    <param-name>casServerLoginUrl</param-name>
    <!-- votre page de login -->
    <param-value>https://cas.mondomaine.fr/cas/login</param-value>
    <!-- <param-value>https://federation.cru.fr/sac-cas/login</param-value> -->
    </init-param>
    </filter>
    <!-- CAS Validation Filter -->
    <filter>
    <filter-name>CAS Validation Filter</filter-name>
    <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
    <init-param>
    <param-name>casServerUrlPrefix</param-name>
    <!-- Votre page de réception de ticket -->
    <param-value>https://cas.mondomaine.fr/cas</param-value>
    <!-- <param-value>https://federation.cru.fr/sac-cas</param-value> -->
    </init-param>
    </filter>
    <!-- CAS HttpServletRequest Wrapper Filter -->
    <filter>
    <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
    <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class>
    </filter>
    <!-- CAS Assertion Thread Local Filter -->
    <filter>
    <filter-name>CAS Assertion Thread Local Filter</filter-name>
    <filter-class>org.jasig.cas.client.util.AssertionThreadLocalFilter</filter-class>
    </filter>
    <!-- CAS Filter for Shibb RemoteUser -->
    <filter-mapping>
    <filter-name>CAS Authentication Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>
    <filter-mapping>
    <filter-name>CAS Validation Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>>
    <filter-mapping>
    <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>
    <filter-mapping>
    <filter-name>CAS Assertion Thread Local Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>

    C'est dans le fichier : /opt/shibboleth-identityprovider-2.x.x/src/main/webapp/WEB-INF/web.xml
    que vous devez reporter : /opt/shibboleth-idp/cas_web.xml. Pour ce faire, ajoutez le contenu du fichier "/opt/shibboleth-idp/cas_web.xml" juste en dessous de "</listener>"

  • Copiez le client CAS dans les bibliothèques des sources de Shibboleth :

    cp /opt/cas-client-3.x.x/modules/cas-client-core-3.x.x.jar /opt/shibboleth-identityprovider-2.x.x/lib/
  • Lancez la procédure d'installation :

    cd shibboleth-identitypovider-2.x.x
    chmod +x install.sh
    ./install.sh
  • Faites le choix d'installation :

    Where should the Shibboleth Identity Provider
    software be installed ? [/opt/shibboleth-idp]
    [Acceptez ce choix] the directory '/opt/shibboleth-idp' already exists.
    Would you like to overwrite this shibboleth configuration ?
    (yes, [no]) no => Naturellement c'est "no"

    C'est maintenant terminé, vous devez avoir en bas de votre terminal un message du type :

    BUILD SUCCESFUL
    Total time : 8 seconds
  • Synchronisez l'horloge :

    ntptime
  • Vérifiez la date :

    date
  • Relancez Shibboleth :

    /etc/init.d/tomcat start
  • Contrôlez le bon fonctionnement :

    tail -f /opt/shibboleth-idp/logs/idp-process.log

2.1) Procédure de mise-à-jour de la brique CAS-client

  • Téléchargez l'achive :

    wget http://www.ja-sig.org/downloads/cas-clients/cas-cl... -O /opt/cas-client-3.1.10-release.zip
  • Décompressez :

    cd /opt
    jar -xf cas-client-3.x.x-release.zip
  • Déplacez vous dans le répertoire :

    cd cas-client-3.x.x/cas-client-core
  • Compilez :
    mvn package
    /!\ Si vous avez une erreur => "Failed to resolve artifact"
    à propos du JAR org.opensaml:opensaml:jar:1.1b
    => Utilisez la version demandée ici 1.1b
  • Déplacez-vous ici :

  • Retournez dans le repertoire cas-client :

    cd cas-client-3.x.x/cas-client-core
  • Compilez avec la commande :

    mvn install :install-file -DgroupId=org.opensaml -DartifactId=opensaml -Dversion=1.1b\
    -Dpackaging=jar -Dfile=/opt/opensaml-1.1b.jar
  • Maintenant vous devez obtenir :

    "BUILD SUCCESSFUL"

    en bas de votre écran.

    Attention l'idp n'aura aucune connaissance de cette nouvelle version de CAS-client. Pour prendre en compte cette mise-à-jour vous devez faire l'upgrade de votre idp, cf. le paragraphe 2) Procédure de mise à jour de la brique Shibboleth-idp.

3) Procédure de mise-à-jour et d'installation de Tomcat

Je tiens à préciser qu'il est impératif de fonctionner avec Tomcat en version 6 au minimum. La version 5.5 rien ne marchera pas avec la plupart des navigateurs hormis mozilla-firefox, puisqu'il y a un problème de compatibilité avec les COOKIES. Dans certain cas Tomcat6 n'est pas proposé avec les distributions stables de linux, il faut donc récupérer une version binaire pré-compilée sur le site officiel de la fédération Apache.

L'installation n'a rien de compliqué mais nécessite de prendre quelques précautions pour éviter de donner un accès global au serveur. J'indique ici comment mettre Apache2.2 en frontal de Tomcat6 avec une configuration optimale, aussi bien pour Apache2.2 que pour Tomcat6.

En résumé, Apache2.2 constitue la porte d'entrée et de sortie vers l'extérieur. Apache communique directement avec Tomcat via un proxy accessible uniquement depuis la boucle locale. Tomcat s'occupe juste d'exécuter les applications web Java (webapps). Ici il est question de "idp.war".

C'est donc Tomcat6 qui doit avoir les droits nécessaires de lecture des fichiers de configuration et d'écriture des logs de Shibboleth. De façon à soulager Tomcat, la gestion de SSL/TLS est prise en charge par Apache2.2.

Voici la procédure à suivre :

  • Emplacement de réception :

    cd /opt/
  • Récupérez l'archive "

    wget ftp://ftp.inria.fr/pub/Apache/tomcat/tomcat-6/v6.x... -O /opt/apache-tomcat-6.x.xx.tar.gz
  • Décompressez l'archive :

    cd /opt
    tar zxvf apache-tomcat-6.x.xx.tar.gz
  • Supprimez les binaires et scripts pour windows :

    cd apache-tomcat-6.x.xx
    rm bin/*.exe bin/*.bat
  • Créez un lien symbolique par commodité :

    cd /opt
    ln -s /opt/apache-tomcat-6.x.xx tomcat
  • Activez le connecteur PROXY AJP pour Tomcat :

    Ajoutez à la section <Service name="Catalina"> du fichier /opt/tomcat/conf/server.xml le connecteur comme ci-dessous :

    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
  • Commentez le connecteur sur le port 8080 dans le fichier /opt/tomcat/conf/server.xml :

    <!--
    <Connector executor="tomcatThreadPool"
    port="8080" protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" />
    -->
  • Supprimez les webapps de base offerts avec Tomcat :

    rm -rf /opt/tomcat/webapps/*
  • Ajoutez la webapp Shibboleth-idp dans le fichier /opt/tomcat/conf/Catalina/localhost/idp.xml

    <Context
    docBase="/opt/shibboleth-idp/war/idp.war"
    privileged="true"
    antiRessourceLocking="false"
    antiJARLocking="false"
    unpackWAR="false" />

    Remarque : vous pouvez ajouter l'attribut autoDeploy="true". Dans ce cas l'application sera chargée au lancement de Tomcat.

  • Par mesure de sécurité, supprimez les utilisateurs qui peuvent s'authentifier sur Tomcat :

    Retirez simplement le contenu de l'instance : tomcat-users dans le fichier /opt/tomcat/conf/tomcat-users.xml comme ci-dessous :

    <?xml version="1.1" encoding='utf-8 ?>
    <tomcat-users>
    </tomcat-users>
  • Lancez Tomcat au démarrage :

    Aucun script "System V" n'est fourni avec la distribution de Tomcat. Vous allez donc devoir en créer un. Par ailleurs ce procédé permet de simplifier la maintenance, mais aussi d'assurer le lancement automatique de Tomcat au démarrage du serveur. Cela permet aussi d'en profiter pour initialiser les variables d'environnement.

    Créez le fichier /etc/init.d/tomcat comme ci-dessous :

    #!/bin/sh

    RETVAL=$?
    JAVA_HOME=/usr/lib/jvm/java-6-sun
    JAVA_OPTS="-Xmx1000m -XX:MacPermSize=512m"
    CATALINA_HOME=/opt/tomcat
    IDP_HOME=/opt/shibboleth-idp

    export JAVA_HOME
    export JAVA_OPTS
    export CATALINA_HOME
    export IDP_HOME

    case "$1" in
    start)
    if [ -f $CATALINA_HOME/bin/startup.sh ];
    then
    echo $"Starting Tomcat"
    /bin/su -p -s /bin/sh tomcat $CATALINA_HOME/bin/startup.sh
    fi
    ;;
    stop)
    if [ -f $CATALINA_HOME/bin/shutdown.sh ];
    then
    echo $"Stoping Tomcat"
    /bin/su -p -s /bin/sh tomcat $CATALINA_HOME/bin/shutdown.sh
    fi
    ;;
    *)
    echo $"Usage: $0 {start|stop}"
    exit 1
    ;;

    exit $RETVAL

    Maintenant il ne reste plus qu'à positionner le script dans les differents niveaux de démarrage comme ci-dessous :

    chmod 755 /etc/init.d/tomcat
    update-rc.d tomcat default
  • Lancez Tomcat avec un utilisateur spécifique :

    Il est préférable de lancer Tomcat avec un utilisateur spécifique avec des privilèges limités. Le script suivant vous aidera à le créer :

    #!/bin/sh

    if ! id tomcat > /dev/null 2>&1 ; then
    adduser --system --home /opt/tomcat --no-create-home \
    --ingroup nogroup --disable-password --shell /bin/false \
    tomcat
    fi

4) Configuration de Apache2.2 (Lenny/Debian)

  • Activez les ports d'écoute dans le fichier :

    /etc/apache2/ports.conf

    Vérifiez que Apache écoute bien les deux ports comme ci-dessous :

    Listen 443
    Listen 8443
  • Configurez vos deux accès :

    - Créez le fichier /etc/apache2/sites-available/idp ci-dessous :

    <IfModule mod_ssl.c>
    <VirtualHost _default_:443>
    ServerName idp.mondomaine.fr:443
    SSLEngine On
    SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:SSLv2:+EXP
    SSLProtocol all -SSLv2
    SSLCertificateFile /etc/ssl/certs/idp.mondomaine.fr.pem
    SSLCertificateKeyFile /etc/ssl/private/idp.mondomaine.fr.key
    SSLCertificateChainFile /etc/ssl/certs/globalsign_ct_root.pem
    SSLCACertificateFile /etc/ssl/certss/sureserverEDU.pem
    SSLOptions +StdEnvVars

    SetEnvIf User-Agent "*.MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    <IfModule mod_proxy_ajp.c>
    ProxyRequests Off
    <proxy ajp://localhost:8009>
    Allow from all

    ProxyPass /idp ajp://localhost:8009/idp retry=5
    </IfModule>
    </VirtualHost>
    </IfModule>

    - Créez le fichier /etc/apache2/sites-available/idp-aa ci-dessous :

    <IfModule mod_ssl.c>
    <VirtualHost _default_:8443>
    ServerName idp.mondomaine.fr:8443
    SSLEngine On
    SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:!SSLv2:+EXP
    SSLProtocol all -SSLv2
    SSLCertificateFile /opt/shibboleth-idp/credentials/idp.crt
    SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp.key
    SSLVerifyDepth 10
    SSLOptions -StdEnvVars +ExportCertData

    SetEnvIf User-Agent "*.MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    <IfModule mod_proxy_ajp.c>
    ProxyRequests Off
    <proxy ajp://localhost:8009>
    Allow from all
    </proxy>
    ProxyPass /idp ajp://localhost:8009/idp retry=5
    </IfModule>
    </VirtualHost>
    </IfModule>

  • Activez les deux accès :

    a2ensite idp idp-aa
  • Activez le module ssl :

    a2enmod ssl
  • Activez le module proxy_ajp :

    a2enmod proxy_ajp
  • Relancez le server Apache2:

    apache2ctl -t
    apache2ctl -k restart

5) Configuration de Shibboleth-idp

Il s'agit de la configuration principale et donc celle que vous devrez utiliser pour administrer Shibboleth. Elle se trouve dans deux fichiers :

- Fichier de génération d'attributs : /opt/shibboleth-idp/conf/attribute-resolver.xml

Ce fichier est nécessaire pour configurer les connecteurs, LDAP, BDD et Statique. Il sera aussi très pratique pour déterminer les attributs nécessaires aux ressources.

- Fichier de contrôle de la propagation d'attributs : /opt/shibboleth-idp/conf/attribute-filter.xml

Ce fichier détermine quels attributs seront fournis aux ressources.

Le support technique Renater offre des fichiers d'exemples qui servent de base à la fédération. Pour une utilisation classique, il faut naturellement changer la configuration des connecteurs et filtrer la propagation des attributs, le but étant d'avoir le contrôle de son fournisseur d'identités.
Fichiers de configuration d'exemples Renater : https://services-federation.renater.fr/exemples/co...

5.1) attribute-resolver.xml

Modifiez attribut-resolver.xml à partir de la section "Data connectors" comme ci-dessous :
(Ces connecteurs sont obligatoires pour mondomaine.fr)

<resolver:DataConnector id="StaticAttributes"
xsi:type="Static"
xmlns="urn:mace:shibboleth:2.0:resolver:dc">

<Attribute id="eduOrgLegalName">
<Value>
Idp MonDomaine.fr
</Value>
</Attribute>

<Attribute id="EduPersonEntitlement">
<Value>
urn:mace:dir:entitlement:common-lib-terms
</Value>
</Attribute>

</resolver:DataConnector>

<resolver:DataConnector id="votreLDAP"
xsi:type="LDAPDirectory"
xmlns:"urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://ldap.mondomaine.fr"
baseDN="ou=people,dc=mondomaine,dc=fr"
principal="cn=cri,ou=services,dc=mondomaine,dc=fr"
principalCredential="VotreMotDePasse">

<FilterTemplate>
<![CDATA[
(uid=$requestContext.princpalName)
]]>
</FilterTemplate>

</resolver:DataConnector>

<resolver:DataConnector id="computedID"
xsi:type="ComputedID"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
generatedAttributeID="computedID"
sourceAttributeID="uid"
salt="VotrePointeDeSel">

<resolver:Dependency ref="votreLDAP" />

</resolver:DataConnector>

5.2) attribute-filter.xml

Ce fichier est indispensable pour l'ajout d'un fournisseur de services. Les fournisseurs de services mentionnés dans ce fichier seront accessibles. Voici un exemple pour ajouter un fournisseur de services :

  • Déplacez vous dans la partie suivante :

    <AttributeFilterPolicy id="releaseAttributesToSelectedSP">
  • Ajoutez le fournisseur dans "PolicyRequirementRule" :

    <PolicyRequirementRule xsi:type="basic:OR">
    <basic:Rule xsi:type="basic:AttributeRequesterString" value="url_fournisseur_a" />
    <basic:Rule xsi:type="basic:AttributeRequesterString" value="url_fournisseur_b" />

    <!-- Mettez à la suite les fournisseurs de services -->
    <!-- Remplacez url_fournisseur_a par l'url de votre fournisseur
    exemple http://www.cairn.info
    -->
    </PolicyRequirementRule>

  • Les paramètes suivants sont les attributs propagés aux fournisseurs url_fournisseur_x :

    <!-- Ex nom complet sans accent d'une personne -->
    <AttributeRule attributeID="commonName">
    <PermitValue xsi:type="basic:ANY" />
    </AttributeRule>

    <!-- Ex nom complet avec accents -->
    <AttributeRule attributeID="DisplayName">
    <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>

  •  Attention Pour que vos modifications soient appliquées il faut impérativement relancer Tomcat.
    /etc/init.d/tomcat stop
    /etc/init.d/tomcat start

6) Droits d'accès et sécurité

Les droits d'accès peuvent être réglés avec beaucoup de souplesse. Voici un ensemble de règles pour protéger le service et les informations sensibles.

6.1) Shibboleth-idp

Shibboleth doit être accessible par Tomcat :

chown -R tomcat logs metadata credentials
chmod 755 logs metadata
chmod 750 credentials
chown tomcat conf/attribute-filter.xml
chmod 660 conf/attribute-filter.xml

chmod 444 /opt/shibboleth-idp/credentials/metadata-federation-renater.crt
chown tomcat /opt/shibboleth-idp/credentials/idp.key
chgrp root /opt/shibboleth-idp/credentials/idp.{key,crt}
chmod 440 /opt/shibboleth-idp/credentials/idp.key
chmod 644 /opt/shibboleth-idp/credentials/idp.crt

6.2) Tomcat

D'origine les droits sont bien réglés, mais assurez-vous que l'utilisateur "tomcat" est bien le propriétaire de :

/opt/tomcat

chown -R tomcat /opt/tomcat

6.3) Certificat SSL Apache

Les certificats SSL permettent d'identifier le serveur via une procédure de signature. Les échanges d'identités entre les utilisateurs et les ressources seront chiffrées. Protégez vos certificats :

chown root:root /etc/ssl/private/idp.mondomaine.fr.key
chmod 640 /etc/ssl/private/idp.mondomaine.fr.key

chown root:root /etc/ssl/certs/globalsign_ct_root.pem
chown root:root /etc/ssl/certs/idp.mondomaine.fr.pem
chown root:root /etc/ssl/certs/sureserverEDU.pem

chmod 640 /etc/ssl/certs/globalsign_ct_root.pem
chmod 640 /etc/ssl/certs/idp.mondomaine.fr.pem
chmod 640 /etc/ssl/certs/sureserverEDU.pem

 Attention Remarque : le prestataire qui assure la sécurité des certificats peut changer. Ce qui précède est donc valable jusqu'à la réception de nouveaux certificats (sauf si vous passez par GlobalSign).

Veuillez prendre note des modifications suivantes pour les nouveaux certificats.

  • Afin de simplifier la gestion des certificats, réalisez un document.cnf : /etc/ssl/idp.mondomaine.cnf. Ce document permet de conserver les paramètres utilisés lors de la création du certificat requête.

    Ci-dessous son contenu :

    [req]
    default_bits = 1024
    default_keyfile = idp.mondomaine.fr.key
    distinguished_name = req_distinguished_name
    prompt = no

    [ req_distinguished_name ]
    C = FR
    O = Mon Etablissement
    CN = idp.mondomaine.fr
    emailAddress = idpmaster [at] mondomaine [dot] fr

  • Maintenant si vous voulez générer un certificat requête avec votre clé privée correspondante, vous pouvez utiliser le script ci-dessous (fichier /root/bin/req) :

    #!/bin/sh
    # Fourni dans le répertoire courant :
    # la clé (pour Apache)
    # idp.mondomaine.fr.key
    # le certificat requête (pour votre RSSI)
    # idp.mondomaine.fr_req.pem
    openssl req -new -nodes -out idp.mondomaine.fr_req.pem\
    -config /etc/ssl/idp.mondomaine.fr.cnf

  • Vous devez remplacer la clé "RSA PRIVATE KEY" par la nouvelle clé :

    cat ./idp.mondomaine.fr.key > /etc/ssl/private/idp.mondomaine.fr.key
  • Pour terminer, il faut remplacez les chaines de certificats. Vous devez adapter les chaînes de certificats selon votre prestataire.

6.4) Ajoutez des certificats non valides

Malheureusement un bon nombre d'aministrateurs n'utilise pas SSL dans les règles de l'art. Les serveurs mal administrés ne sont pas considérés comme dignes de confiance et Java ou les navigateurs internet n'accepteront pas les connexions avec ces serveurs. Pour résoudre ce problème et forcer Java à utiliser ces serveurs, vous devez ajouter manuellement les certificats dans son KeyStore de la façon suivante :

  • Téléchargez le programme Java suivant :

  • Compilez le programme :

    javac InstallCert hostname

     Attention Pour mondomaine.fr hostname=cas.mondomaine.fr

  • On vous demande d'ajouter les certificats. Ajoutez les tous.

    Enter certificate to add to trusted keystore or 'q' to quit: [1]

     Attention 1 pour certificat numéro 1, recommancez autant de fois que vous avez des certificats, cf. le paragraphe 3).

  • Copiez le KeyStore Java "jssecacerts" crée dans le répertoire courant ici :

    cp jssecacerts $JAVA_HOME/jre/lib/security
  • Vérifiez les droits ou fixez les :

    chown root:root $JAVA_HOME/jre/lib/security/jssecacerts
    chmod 644 $JAVA_HOME/jre/lib/security/jssecacerts
  • Pour finir, relancer Tomcat :

    /etc/init.d/tomcat stop
    /etc/init.d/tomcat start

    Remarque : si vous souhaitez que ces certificats soient reconnus comme de "confiance" par toutes vos applications Java et pas seulement JSSE, écrasez "cacert" avec "jssecacerts".

Choisir un bon mot de passe

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 15/07/10
  • Correction mineure : 10/04/12
Fiche archivée
Ce texte date de 1992 et n'a pas été mis à jour depuis. Néanmoins le fond est toujours valable et c'est un document qui fait partie de l'histoire de la sécurité informatique au CNRS.
Mots-clés

Choisir un bon mot de passe

Cette fiche n'est plus à jour. Elle a été archivée pour la raison exposée ci-contre.

Ce petit texte alerte les utilisateurs de l'informatique sur l'importance du mot de passe et donne des conseils pour le bon choix et la bonne confidentialité de celui-ci. Il introduit aussi le nouveau poste de chargé de mission sécurité informatique qui venait d'être créé au CNRS et que j'ai occupé. Ce texte est un des premiers documents de sécurité informatique destiné aux utilisateurs venant du CNRS qui a été publié. Il a été repris dans de nombreux autres environnements.

Fichier attachéTaille
choisir_mot_de_passe.pdf17.69 Ko

Présentations du séminaire 'Authentification centralisée pour les applications web' JoSy Mai 2010

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 29/06/10
  • Correction mineure : 19/10/10
Mots-clés

Présentations du séminaire 'Authentification centralisée pour les applications web' JoSy Mai 2010

Ce séminaire JoSy "Authentification centralisée pour les applications web" a été organisé par RESINFO le 6 mai 2010 à Paris.

Objet (d'après le site Web)

L’authentification est un élément central de notre sécurité. L’identification de manière unique et globalisée d’un utilisateur se connectant à une application web est devenue une nécessité, notamment du fait de la multiplication des applications accédées à distance et de la disparité au niveau géographique des services offerts.

Cette journée permet de dresser un réel état des lieux des concepts, techniques et applications qui sont le plus utilisés au sein de notre communauté, relatifs à une authentification unique centralisée pour les applications web, que ce soit au niveau d’un laboratoire, d’une université, ou de toute la communauté Education /Recherche.

En complément, une présentation de retours d’expériences pourra aider un administrateur système et réseau à mettre en place un système d’authentification unique pour ses applications web au sein de son unité.

Présentations et videos

(les PDF et les vidéos sont disponibles sur le site de la conférence)

  • Introduction - Anne Facq (Centre de Recherche Paul Pascal)
  • La problématique de l’authentification, panorama de quelques solutions (Ldap, Active Directory, Eduroam, Radius, SSO, Shibboleth, CAS, OpenId) - Claude Gross (Unité Réseau du CNRS)
  • OpenID - Dominique Fournier (CNRS/CRIC)
        Pour quoi faire ?
        Pour qui ?
        Avec quelle sécurité ?
  • CAS - Julien Marchal (Université de Nancy 2)

          Principe de l’authentification CAS
          Architecture CAS
          Mise en place d’un serveur CAS

  • Shibboleth - David Verdin (CRU)

         Principes
         Les applications déjà prêtes
         "Shibboletiser" une application

  • Shibboleth et Fédération Education/Recherche
  • Fédération d’identité Éducation-Recherche" - Mehdi Hached (Renater)

         Les participants
         Son évolution

  • Le projet JANUS (gestion identite CNRS) - Claude Gross (Unité Réseau du CNRS)

         La gestion des identités au CNRS
         Les applications qui l’intègrent ou qui vont l’intégrer

  • CASifier une application - Julien Marchal (Université de Nancy 2)
  • Mise en oeuvre de Shibboleth - Shibboliser des applications web (application locale et application tierce) - Roland Dirlewanger (CNRS - Délégation Aquitaine-Limousin)
Fiche dév Ens Sup - Recherche
  • Création ou MAJ importante : 11/05/10
  • Correction mineure : 11/05/10
Mots-clés

RDVZ : mise en place de rendez-vous entre plusieurs personnes par sondage

Ce logiciel a été développé (ou est en cours de développement) dans la communauté de l'Enseignement Supérieur et de la Recherche. Son état peut être variable (cf champs ci-dessous) donc sans garantie de bon fonctionnement.
  • Site web
  • Système : UNIX-like
  • Version actuelle : 2.0.2 - 19/04/2010
  • Licence(s) : GPL, CeCILL
  • Etat : validé (au sens PLUME), diffusé, stable
  • Support : maintenu, développement en cours
  • Concepteur(s) : Centre des Ressources Informatiques - Université d'Avignon et des Pays de Vaucluse
  • Contact concepteur(s) : https://listes.univ-avignon.fr/wws/info/gpl
  • Laboratoire(s), service(s)... : Univ Avignon

 

Une fiche logiciel décrit plus en détail ce développement, consultez la pour plus d’informations : RDVZ
Fonctionnalités générales du logiciel

RDVZ permet la mise en place de rendez-vous entre plusieurs personnes par sondage en ligne.
L’organisateur crée sur un serveur avec une interface conviviale le sondage et les dates possibles puis communique l’URL du sondage aux participants. Chaque participant vote pour une date de réunion proposée par l’organisateur sur le serveur et dit si il est disponible ou non.
Cela permet de mettre en place un service de type Doodle Fiche Plume.

L’organisateur peut également exporter les résultats au format csv, et clore les votes. Il peut aussi recevoir un courrier électronique de notification à chaque vote.
La durée de vie du sondage est gérée dans le fichier de configuration.
L’application permet un accès anonyme uniquement pour le vote, et un accès authentifié (MySQL, CAS, LDAP) indispensable pour créer des rendez-vous.
Des documentations utilisateurs et développeurs sont disponibles en français et en anglais.

Contexte d’utilisation du logiciel

A l'IBGC (Bordeaux), RDVZ est utilisé depuis janvier 2009, une centaine de sondages sont créés par an. Simple d'utilisation et d'installation, il correspond à nos besoins. Nous avons choisi le mode d'authentification LDAP sans CAS. Suite aux retours des utilisateurs, quelques modifications ont été apportées.

Au sein de l'IEMN (Villeneuve d'Ascq, 59), RDVZ est utilisé depuis septembre 2008. La version en production sur la plate-forme d'hébergement est la version 1.1 (sur laquelle quelques modifs mineures ont été apportées). Plebiscité par nos utilisateurs pour sa simplicité d'utilisation, il a remplacé peu à peu Doodle dans notre unité (+ de 200 sondages crées depuis le lancement de l'outil). Point amusant, il est aussi détourné de sa fonction première (prise de rdv rapide) : utilisé parfois pour effectuer des votes électroniques sur des sujets non stratégiques.

Pour la partie authentification, nous avons fait le choix d'utiliser une base de comptes stockées dans MySQL (migration prochainement vers LDAP sans SSO-CAS). L'équipe informatique du LASIR (UMR CNRS 8516) a modifié le code source du produit pour utiliser les certificats électroniques X509 CNRS dans le processus d'authentification et l'a intégré dans sa charte graphique web.

Mis en place récemment au sein de la Maison René-Ginouvès, Archéologie et Ethnologie, la création de sondage est réservée aux membres des laboratoires de la Maison via une authentification CAS (JASIG) couplée au LDAP. Le vote, lui, est ouvert à tous les votants ayant reçu le lien adéquat et sans authentification.
Malgré cette mise en place récente, l’utilisation monte en charge rapidement. La seule modification au produit initial, mise à part la customisation graphique, est la suppression de la possibilité de laisser aux votants un commentaire global. Cette option modifiait la mise en page et générait des erreurs de manipulation de la part des votants.

RdvZ entame maintenant une seconde vie avec la version 2.0 : le développement a été entièrement refait à l'aide du framework PHP Symfony.
Nous avons notamment eu des retours de Centrale Marseille et de l'Inserm qui nous ont beaucoup aidé à corriger les différents bugs et problèmes pendant la beta.

Mots-clés

Journée JOSY "Authentification centralisée pour les applications web" - 6 mai 2010 - Paris

Extrait du site de la journée (http://www.resinfo.cnrs.fr/spip.php?article44) :

JOSY "Authentification centralisée pour les applications web" - le 6 mai 2010 à Paris

Objet : L’authentification est un élément central de notre sécurité. L’identification de manière unique et globalisée d’un utilisateur se connectant à une application web est devenue une nécessité, notamment du fait de la multiplication des applications accédées à distance et de la disparité au niveau géographique des services offerts.

Cette journée va nous permettre de dresser un réel état des lieux des concepts, techniques et applications qui sont le plus utilisés au sein de notre communauté, relatifs à une authentification unique centralisée pour les applications web, que ce soit au niveau d’un laboratoire, d’une université, ou de toute la communauté Education /Recherche.

En complément, une présentation de retours d’expériences pourra aider un administrateur système et réseau à mettre en place un système d’authentification unique pour ses applications web au sein de son unité.

Date et lieu : jeudi 6 mai 2010 - Délégation Paris Michel-Ange du CNRS à Paris (http://www.cnrs.fr/paris-michel-ange/article.php3?...)

Web diffusion : cette journée sera diffusée en direct sur le web grâce à la cellule Webcast du Centre de Calcul de l’IN2P3.

Organisateurs : Olivier Boebion, Roland Dirlewanger, Anne Facq, Claude Gross, Jean-Yves Hangouët, Christian Helft, Bernard Maire-Amiot

Programme prévisionnel :
9h00 Accueil des participants

Introduction
9h30 "La problématique de l’authentification, panorama de quelques solutions (Ldap, Active Directory, Eduroam, Radius, SSO, Shibboleth, CAS, OpenId)" - Claude Gross (Unité Réseau du CNRS)

Techniques
10h00 "OpenID" - Dominique Fournier (CNRS/CRIC)
* Pour quoi faire ?
* Pour qui ?
* Avec quelle sécurité ?

10h30 "CAS " - Julien Marchal (Université de Nancy 2)
* Principe de l’authentification CAS
* Architecture CAS
* Mise en place d’un serveur CAS

11h00 "Shibboleth" - David Verdin (CRU)
* Principes
* Les applications déjà prêtes
* "Shibboletiser" une application

11h40 Shibboleth et Fédération Education/Recherche

Projets utilisant Shibboleth
12h00 "Fédération d’identité Éducation-Recherche" - Mehdi Hached (Renater)
* Les participants
* Son évolution

12h20 "Le projet JANUS (gestion identite CNRS)"- Claude Gross (Unité Réseau du CNRS)
* La gestion des identités au CNRS
* Les applications qui l’intègrent ou qui vont l’intégrer

12h40 Repas

Après-midi

Retours d’expérience (durée des presentations entre 20 à 30 mn)
* Installation serveur OpenId
* Installation serveur CAS
* Installation serveur Shibboleth
* Mise en place d’applications clientes (Apache, les CMS etc...)

Syndiquer le contenu