La gestion des identités au CNRS
Christelle Ecrepont
DSI/CNRS.
Claude Gross
UREC/CNRS
Résumé
La
gestion des identités, en particulier pour l’accès
aux applications, est un problème qui n’est pas résolu
aujourd’hui au CNRS. Les spécificités du CNRS,
avec ses centaines d’unités disséminées
géographiquement, et pour la plupart multi-tutelles, rendent
d’autant plus difficile cette gestion.
La mise en place
d’une IGC pour diffuser des certificats électroniques
aux personnels des unités CNRS avait pour but de répondre
en partie à cette question. Mais outre la difficulté
d'un déploiement généralisé dans toutes
les unités, les certificats en eux-mêmes ne peuvent
répondre qu’au problème de l’authentification,
et non à la gestion des habilitations.
Par ailleurs, le
CNRS n’est pas un organisme isolé du monde et le besoin
d’outils permettant l’authentification inter-organismes
existe. Or nos partenaires (les universités par exemple)
n'ont pas nécessairement retenu les certificats électroniques
comme méthode d'authentification.
Le projet Janus est
donc une évolution, en tenant compte de l’existant,
permettant de résoudre les problèmes ci-dessus et de
rendre possible l’interopérabilité avec nos
partenaires des autres EPST et des universités.
L'article
abordera d'abord la démarche qui a été suivie
pour mener ce projet dans le contexte particulier du CNRS et
présentera l'architecture qui a été mise en
place.
Un certain nombre de problèmes spécifiques
à la réalisation d'un tel service seront discutés
ensuite.
Enfin, la suite du projet sera abordée, et en
particulier le volet gestion des habilitations qui reste à
compléter.
Mots clefs
Identités, identification, authentification, habilitation, fédérations, Shibboleth, SSO
En 2001, le CNRS a mis en place une infrastructure de gestion de clés (IGC) dans le but de délivrer des certificats personnels et de services pour ses besoins d'authentification et de sécurisation des applications réseaux. Pour cela, un logiciel a été développé en interne pour répondre au besoin et une organisation adaptée au CNRS a été mise en place pour la diffusion des certificats. Entre 2001 et 2008, ce service a permis la délivrance de plus de 36000 certificats personnels et de plus de 5200 certificats de service. Outre les besoins initiaux relatifs à l'authentification, des applications comme la messagerie sécurisée ou le chiffrement de données ont pu être déployés.
En 2007, le déploiement des certificats au CNRS couvrait environ les 2/3 de ses unités. À cette date, l'annonce de l'ouverture prochaine de nouvelles applications, comme SIRHUS1, nécessitant une couverture complète des unités, a amené la DSI du CNRS et l'UREC à une réflexion pour répondre à ce problème. Cette réflexion a porté sur deux points principaux :
le constat de la difficulté à atteindre une diffusion généralisée des certificats au CNRS, tout en gardant un niveau de confiance minimal aux certificats délivrés ;
le problème posé par les choix différents de nos partenaires, comme les universités, en terme de technologie d'authentification, rendant difficile le partage de ressources communes.
Ceci a conduit le CNRS, fin 2007, a démarrer le projet JANUS afin de proposer une solution pour la gestion des accès aux applications CNRS, intégrant une gestion des habilitations, s'appuyant sur l'existant (le SI du CNRS et l'IGC CNRS en particulier) et permettant l'interopérabilité avec nos partenaires tels que les universités.
Les choix technologiques retenus dans le projet, ont été guidés par la volonté de proposer une solution interopérable avec nos partenaires, ce qui nous a conduit au choix de la technologie Shibboleth [1] utilisée en particulier dans les universités.
Cette technologie permet de mettre en place :
un service d'authentification, via un fournisseur d'identités, utilisable en dehors de l'organisme à travers la notion de fédérations d'identités ;
une gestion des habilitations grâce à la propagation d'attributs [2].
Ce choix devait nous permettre d'intégrer les fédérations d'identités que permet cette technologie et qui se mettaient alors en place chez nos partenaires.
Dans ce cadre, Janus nécessitait la mise en place de 3 briques :
un annuaire ou référentiel ;
un service de fournisseur d'identités ;
un service de gestion des habilitations.
Le projet Janus était contraint en délai puisqu'il fallait pouvoir offrir le service au premier client pour Avril 2008, date de l'ouverture de SIRHUS à certaines unités. Il fallait de plus qu'il prenne en compte l'existant du SI CNRS notamment en termes d'identifiant pour les applications. En effet, l'identifiant retenu jusque là pour l'identification aux applications nationales était l'adresse mail de l'utilisateur. Selon les cas, l'authentification se faisait par certificat CNRS ou par email/mot de passe.
Le CNRS disposait alors d'un annuaire (dénommé
Annuaire Central) contenant l'ensemble des personnels CNRS (issu du
référentiel de fonctions de l'organisme, Labintel)
mais qui ne pouvait servir de référentiel pour le
fournisseur d'identités, d'une part à cause de la non
unicité des adresses de messagerie des personnels et d'autre
part du fait de la nécessité de disposer d'attributs
supplémentaires pour la gestion des habilitations.
Nous
avions aussi à notre disposition un annuaire spécifique
aux projets BFC2
et SIRHUS adressant uniquement la population utilisatrice de ces
applications et ne contenant que les attributs nécessaires à
leurs accès (notamment l'identifiant SAP). Dans cet annuaire
l'unicité, des adresses de messagerie était
assurée.
Le CNRS disposait également d'un
gestionnaire de mots de passe (Sesame) qui permettait aux
utilisateurs de définir et mettre à jour leur mot de
passe sans l'intervention d'un tiers. Ce gestionnaire positionnait
le mot de passe sur l'annuaire central du CNRS.
L'architecture réseau/sécurité mise en place
sur le centre serveur de la DSI pour les besoins de BFC et SIRHUS en
2007 amenait la sécurité nécessaire au moyen de
pare-feux, d'une DMZ et d'un service de répartition de
charge.
Afin que SIRHUS puisse être client de JANUS dès
avril 2008, il était nécessaire de mettre à
profit les briques à notre disposition dans le système
d'information CNRS et d'envisager de mener le projet JANUS en
plusieurs étapes.
Nous avons opté pour un démarrage
utilisant l'annuaire projets SAP que nous avons étendu avec
d'autres attributs issus de l'annuaire central comme le mot de
passe.
La construction du référentiel indispensable a été menée dans la phase suivante du projet.
En 2008 nous avons travaillé à la construction d'un nouveau référentiel redondé pour JANUS adressant l'ensemble des utilisateurs des unités CNRS.
En effet, l'annuaire utilisé au départ du projet était un annuaire conçu pour les besoins spécifiques des nouvelles applications de gestion CNRS BFC et SIRHUS. Cet annuaire ne contenait que les personnels CNRS et quelques personnels spécifiques (Directeurs d'unités, Responsables d’entretien...) et uniquement les attributs nécessaires au fonctionnement des systèmes de paye et de Comptabilité/Finances. Les entrées des personnels présentes dans cet annuaire étaient « marquées » (« taguées ») dans l’annuaire central CNRS et intégrées dans cet annuaire Projets. Cet annuaire, sur lequel reposait JANUS au départ, n'était pas redondé.
Afin de pouvoir étendre l’utilisation de JANUS aux autres applications CNRS (applications DSI, Délégations, Unités…), il était nécessaire de pouvoir disposer d’un référentiel complet, adressant l'ensemble des personnels des unités, et sécurisé.
L'étude relative aux attributs du référentiel a été menée en tenant compte des recommandations du groupe de travail Supann [3].
Un fournisseur d’identités référence habituellement des personnes plutôt que des fonctions.
Dans un annuaire de personnes, une personne qui entre dans le référentiel gardera toujours le même identifiant dans celui-ci quels que soient ses changements de situations professionnelles. Si la personne occupe plusieurs fonctions simultanément elle a une seule entrée dans le référentiel. Dans un annuaire de fonctions de personnes, une personne qui a plusieurs fonctions (affectations) possède plusieurs identifiants dans l’annuaire.
Suite à une première
réflexion, et dans l'optique de faciliter l’usage du
fournisseur d’identités aux applications, tout en
minimisant l’impact sur les applications existantes, nous
avons retenu le principe de créer un nouvel annuaire de
fonctions et non de personnes, avec pour identifiant l'adresse
mail de la personne, qui doit donc être unique.
Les
personnels ayant N affectations disposent de N entrées dans
l'annuaire avec N adresses mails différentes. Ils ont donc un
compte d’accès différent pour chacune de leurs
affectations.
Dans tous les cas afin d'assurer l'unicité
d'adresse mail dans le référentiel, lorsque l’adresse
mail est vide, non renseignée correctement, ou non unique,
alors l’entrée correspondante ne sera pas activée
ou utilisable dans le référentiel.
Cette adresse
mail des personnels (CNRS ou non) est une information renseignée
manuellement dans Labintel par les gestionnaires Labintel des
différentes unités.
Jusqu'à la mise en œuvre
de JANUS, les informations contenues dans Labintel étaient
réservées essentiellement à un usage
consultatif si bien que les données renseignées
n'étaient pas systématiquement fournies ni normées.
Des campagnes d'information ont été menées
et sont à renouveler régulièrement afin de
sensibiliser les acteurs sur la criticité de ces données
et l'importance que ces informations soient correctement renseignées
et tenues à jour.
Le fournisseur d’identités,
même avec le nouveau référentiel, ne permet que
l’authentification des utilisateurs ainsi qu’une gestion
minimale des accès sur la base des valeurs des attributs
actuellement présents dans le référentiel. En
effet, les possibilités dans ce domaine restent très
limitées du fait de l'absence de certaines informations dans
Labintel.
Par exemple, certaines fonctions ou rôles, comme
par exemple les ACMOs, les correspondants sécurité,
les gestionnaires Labintel n'y figurent pas. De nombreuses et
nouvelles perspectives pourraient voir le jour si ce type de données
était présent dans le référentiel.
Le référentiel est actuellement alimenté par l'annuaire de Fonctions du CNRS (Labintel) qui est le référentiel des populations des unités. L'alimentation de cet annuaire repose :
pour les personnels payés par le CNRS, sur SIRHUS pour partie et sur des informations renseignées manuellement par les gestionnaires Labintel d'unité pour les informations non gérées dans SIRHUS ;
pour les personnels des unités non payés par le CNRS, sur l'insertion et la mise à jour des informations des personnels par les gestionnaires Labintel.
Sur l'utilisation d'une interface web pour gérer les « tags », attributs spécifiques pour gérer l'accès aux applications DSI
Figure 1
: Alimentation du référentiel de Janus
Ce référentiel constitue le socle de base pour l’authentification des applications CNRS. Il est donc commun à l’ensemble des applications et ses entrées et contenus ne peuvent donc être adaptés à des besoins ponctuels ou ne répondant pas aux critères de confidentialité requis. Par exemple, il ne doit pas contenir de comptes génériques ni de comptes de tests.
Le référentiel doit donc répondre à un cadre strict d'utilisation et sans possibilité de déroger aux règles établies.
Pour les applications clientes du fournisseur d'identités CNRS ouvertes également à des utilisateurs hors population Labintel, la délégation de l'authentification (ou de la gestion des accès), doit être étudiée séparément. La mise en place d'un fournisseur extérieur dédié (avec un annuaire et des outils de gestion spécifiques) pourrait répondre au besoin.
En attendant la mise en place de l'outil de gestion des habilitations, et afin de filtrer l'accès à certains services sur la base d'informations non directement disponibles dans le référentiel, une interface a été adaptée afin de pouvoir :
éditer les informations sur un utilisateur ;
gérer le marquage de certains attributs dans le référentiel.
Pour tenir compte de l'existence de l'IGC CNRS, et donc de la disponibilité de certificats personnels, 2 modes d'authentification sont proposés sur le fournisseur d'identités :
par identifiant et mot de passe ;
par certificat personnel.
L'identifiant retenu, pour des raisons pragmatiques, est l'adresse mail de l'utilisateur. Celui-ci a pour avantage :
d'exister dans le référentiel ;
d'être unique ;
d'être connu des utilisateurs ;
de pouvoir bénéficier d'un service existant pour l'initialisation et la modification des mots de passe ;
d'être présent dans les certificats personnels délivrés par l'IGC CNRS.
Mais il présente comme inconvénients :
de ne pas être obligatoirement présent dans le référentiel. En effet c'est le gestionnaire Labintel de l'unité qui fournit cette information ou non. Dans le cas où l'adresse mail n'est pas présente, le compte est invalidé au niveau du référentiel ;
de ne pas être pérenne. Une personne changeant d'unité verra son adresse mail modifiée ;
de ne pas être unique dans le référentiel à cause des personnes affectées dans plusieurs unités ; dans ce cas, une seule entrée est active dans le référentiel, les autres ne peuvent être utilisées.
Le mode d'authentification par certificat personnel se fait par validation du certificat et par vérification de l'existence de l'adresse mail extraite du certificat dans le référentiel.
Pour mettre en place ce double mode d'authentification, nous avons fait le choix d'utiliser CAS [4] comme service d'authentification, car il apportait une facilité pour la mise en place de ce système, en particulier pour la double authentification, certificats personnels ou email/mot de passe.
Par ailleurs, nous avons mis en œuvre la fonctionnalité SSO (Single Sign On) [5] que rend disponible la technologie Shibboleth et qui permet aux utilisateurs de s'authentifier une seule fois sur un fournisseur d'identités pour accéder à plusieurs applications.
La performance et la disponibilité du service ont été les objectifs de l'architecture mise en place pour le fournisseur d'identités. Pour cela, chacun des composants a été redondé.
Cette architecture comprend :
pour l'IdP3, 2 serveurs sur lesquels ont été installés :
serveur httpd apache,
module mod_jk,
tomcat,
shibboleth IdP 1.3.3 + extension Hashib,
CAS ;
2 serveurs LDAP (Oracle OID) pour le référentiel ;
2 répartiteurs de charge (BIGIP 3400 – F5) ;
2 pare-feux (CISCO ASA 5540) ;
2 routeurs (CISCO 3845).
Figure 2
: Architecture du fournisseur d'identités
Les choix suivants ont été faits :
les routeurs, les pare-deux, les répartiteurs de charge ainsi que les annuaires LDAP sont installés en actif/passif ;
les 2 serveurs IdP sont eux en actif/actif derrière le répartiteur de charge ;
installation de l'extension Hashib pour partager les informations de sessions entre les 2 serveurs IdP ;
Apache est utilisé comme frontal en utilisant le module mod_jk ;
utilisation systématique de la méthode PUSH pour la propagation des attributs par l'IdP. Ce choix permet de n'avoir aucune session entre les applications cibles et l'IdP, ce qui facilite le problème de la répartition de charge entre les 2 IdPs (cf. paragraphe 4.3).
Le fait d'avoir un répartiteur de charge desservant 2 serveurs IdP demande un traitement adéquat :
pour que les redirections HTTP entrant en jeu dans une authentification Shibboleth puissent se faire correctement ;
pour que la durée de validation d'une authentification ne soit pas diminuée.
Les sessions sont les suivantes :
navigateur → application ;
navigateur → serveur IdP ;
navigateur → serveur CAS ;
serveur IdP → serveur CAS ;
serveur CAS → serveur LDAP ;
serveur IdP → serveur LDAP.
Pour que l'authentification Shibboleth réussisse, du fait que les serveurs CAS ne partagent pas les informations de sessions, il est absolument nécessaire que le serveur CAS soit le même dans la session 3 et la session 4. S'il ne s'agit pas du même serveur, le serveur IdP ne pourra pas récupérer l'identifiant de l'utilisateur à l'origine de la requête.
Le répartiteur de charge utilisé permet une configuration de la persistance de session entre un client, identifié par son adresse IP, et un service défini par une URL. Dans notre cas, le serveur CAS et le serveur IdP, sur un même serveur physique, sont vus comme un même service car seule la partie chemin (PATH) diffère dans l'URL de CAS et celle de l'IdP :
https://janus.dsi.cnrs.fr/shibboleth-idp/
https://janus.dsi.cnrs.fr/CAS/
Pour ces services, une durée d'une heure a été configurée sur les répartiteurs pour la persistance de session.
Par ailleurs, le choix de la méthode PUSH pour la propagation des attributs, permet d'éviter le problème des sessions entre les applications cibles et l'IdP. Sans celle-ci, l'IdP entrant en jeu dans ce type de sessions, ne serait pas forcément le même que celui qui l'était dans les sessions avec le navigateur.
L'utilisation de l'extension Hashib [6] sur les serveurs IdP permet de partager les informations de sessions entre les 2 IdPs et donc de vérifier une authentification encore valide sur n'importe lequel des 2 serveurs IdP. Sans cette extension, les utilisateurs pourraient se voir obliger de se ré-authentifier dans une période inférieure à celle configurée sur les IdPs. Cela correspond par exemple à :
un utilisateur s'authentifie sur IDP1 pour accéder à une application A à un instant t1 : l'authentification est normalement valide pendant 2h
le même utilisateur, soit perd sa session sur l'application A, soit veut accéder à une application B, il est donc renvoyé vers le fournisseur d'identités :
si cela arrive à t1 + delta, avec delta ≤ 1h, la session se fera avec le même serveur IDP1 grâce à la persistance de sessions et l'authentification sera vérifiée
si cela arrive à t1 + delta, avec delta > 1h, la session ne se fera pas obligatoirement avec le même IdP, mais grâce à l'extension Hashib, les 2 serveurs peuvent valider l'authentification.
Lors d'une demande d'authentification sur le fournisseur d'identités, le scénario est le suivant :
Figure 3
: Authentification sur le fournisseur d'identités
demande d'accès à l'application
redirection sur l'IdP. Le répartiteur assigne l'un de 2 IdPs pour la session du navigateur
redirection sur CAS. Le répartiteur, par le mécanisme de persistance de session, va utiliser le même serveur physique, car pour lui il s'agit du même service
Authentification sur le serveur CAS. L'utilisateur doit utiliser au choix :
un couple identifiant/mot de passe ➱ recherche de l'entrée dans l'annuaire et requête BIND avec le mot de passe fourni ;
un certificat personnel ➱ validation du certificat et recherche de l'entrée dans l'annuaire.
redirection sur l'IdP. Le répartiteur, par le mécanisme de persistance de session, va utiliser le même serveur.
récupération par l'IdP de l'identifiant sur le serveur CAS. Pour être sûr d'utiliser le même serveur CAS, une entrée dans le fichier /etc/hosts indique d'utiliser localhost comme serveur CAS.
récupération par l'IdP des attributs dans l'annuaire
redirection sur l'application cible avec l'assertion contenant les attributs de l'utilisateur
L'architecture mise en place permet donc de tenir compte de la répartition de charge sur plusieurs serveurs IdP. Mais elle n'est valable que dans la version 1.3.X de l'IdP Shibboleth car l'extension Hashib n'a pas été portée sur les versions 2.X. Il faudra donc étudier d'autres techniques avant de pouvoir migrer dans les nouvelles versions de l'IdP Shibboleth, comme par exemple Terracota [7].
Le service a été mis en place dans un souci de haute disponibilité vue sa criticité. L'architecture sur le site est totalement redondée afin de s'affranchir de toute panne simple.
Cependant le réseau n'est pas actuellement redondé et le dispositif ne prend pas en compte une « panne site » (sinistre sur le site).
Il existe une liaison de secours réseau (opérateur différent, adductions différentes) mais cette liaison ne secourt que les flux de et vers les sites du Système d'Information (DSI, Siège et Délégations Régionales du CNRS et Centre Serveur) et non pas l'Internet. Un dispositif de secours complet a été spécifié mais n'a pas encore été testé et mis en place.
Pour s'affranchir du second risque, plusieurs solutions sont envisageables :
répartir totalement l'infrastructure sur 2 bâtiments proches (dual building, avec ou sans solution de PRA) ;
un secours opérationnel hors site du service ;
une répartition du service sur 2 sites.
À ce jour aucun choix n'a été arrêté au niveau de la direction.
Le sujet de la déconnexion est complexe et mal résolu actuellement dans le contexte d'un fournisseur d'identités Shibboleth. En effet, un utilisateur peut, à un moment donné, être connecté à plusieurs applications après s'être authentifié sur un fournisseur d'identités. Dans ce contexte, la déconnexion, dite globale (ou SLO pour Single LogOut [8]), n'est pas triviale à mettre en oeuvre. Pour être complète, il faudrait que les sessions correspondantes soient détruites :
sur l'IdP ;
sur le service d'authentification si l'IdP en utilise un, comme CAS dans notre cas ;
sur les différents SP correspondants aux différentes applications ;
sur les applications si elles gèrent elles-mêmes des sessions applicatives.
Dans l'état actuel il est possible de terminer une session sur une application donnée si celle-ci a prévu cette fonctionnalité. Si tel est le cas, l'utilisateur peut cliquer sur le lien correspondant à l'action Logout, ce qui aura pour effet de détruire les informations de session (contenues dans les cookies du navigateur), la session au niveau du SP et éventuellement (si c'est correctement implémenté) la session au niveau de l'application si c'est nécessaire.
Mais cela est totalement insuffisant, car si on en reste là, l'utilisateur sera toujours « connu » du fournisseur d'identités et si celui-ci refait une tentative d'authentification sur l'application, il sera redirigé vers l'IdP qui validera l'authentification sans intervention de l'utilisateur.
Pour une déconnexion complète, il faudrait donc que l'application envoie une requête de Logout vers l'IdP (les versions actuelles de l'IdP ne supporte pas ce type de requêtes) pour que celui-ci détruise la session de l'utilisateur, propage cette requête vers tous les SP ayant une session avec cet utilisateur ainsi qu'aux applications gérant des sessions applicatives. Il faut ajouter à cela le traitement des SP ne supportant pas cette fonctionnalité et celui du retour à l'utilisateur lui indiquant que la déconnexion s'est bien ou ne s'est pas bien passée. On voit que le mécanisme à mettre en œuvre n'est pas prêt de voir le jour.
Actuellement, le seul moyen de se déconnecter globalement est de fermer le navigateur, ce qui entrainera la suppression de tous les cookies de sessions mis en place lors des différentes connexions.
Les évolutions qui sont annoncées dans les prochaines versions de Shibboleth IdP devront être étudiées de près pour évaluer ce qu'il sera possible de faire raisonnablement dans ce domaine.
Dans tous les cas, cette faiblesse de la technologie doit être compensé (très partiellement) par une information claire auprès des utilisateurs.
La mise en place pour les utilisateurs d'un compte unique et de la
fonctionnalité de SSO n'est pas quelque chose d'anodin en
termes de sécurité. Cela nécessite une
réflexion sur l'accompagnement nécessaire pour éviter
des conséquences négatives.
Une information
importante vers les utilisateurs doit être faite afin de
permettre la compréhension des risques associés.
À cette condition, on peut espérer que l'appropriation par les utilisateurs de ce compte unique ET personnel permette d'éviter des comportements à risques de la part de ces derniers. En particulier, on peut espérer que le « prêt » de compte à un collègue pour permettre d'accéder à une application, « parce que c'est plus simple », devrait grandement diminuer. La condition à cela est également que les outils mis en place permettent une gestion de ces comptes distribuée et réactive.
Dans les délais qui ont été les nôtres pour satisfaire les contraintes liées à l'ouverture de certaines applications, la priorité a été la mise en place du fournisseur d'identités. En conséquence, le référentiel qui a été mis en place pour celui-ci contient uniquement les données disponibles dans le SI CNRS à ce moment là, avec les outils de gestion associées (SIRHUS, LABINTEL, Sesame, …). Nous avons donc aujourd'hui un fournisseur d'identités répondant à la fonction d'authentification, capable de fournir un certain nombre d'attributs issus des données actuelles du référentiel et offrant un niveau de gestion des habilitations faible.
Pour aller plus loin, il est nécessaire :
de mener une étude sur un ensemble de rôles, correspondants à des fonctions au CNRS, en particulier sur ceux non renseignés dans le référentiel existant ;
établir un ensemble de droits associés ou non à ces rôles, en intégrant des possibilités de délégation ;
traduire cela par de nouveaux attributs dans le référentiel ;
mettre en place les outils nécessaires à la gestion de ces nouveaux attributs.
Seuls les rôles représentatifs à l'échelle de l'organisme auront vocation à être intégrés dans l’annuaire puis gérés via l’outil de gestion des accréditations mis en place. Des attributs spécifiques à une application ou à un laboratoire CNRS n’ont pas vocation à y figurer.
Ce volet du projet JANUS est très important car il pourrait ouvrir la voie à des applications nouvelles. Elle pourrait également offrir une solution permettant d'éviter certains comportements à risque de la part des utilisateurs. Si la délégation de droits était possible, un directeur n'aurait, par exemple, pas à donner son compte à sa secrétaire pour effectuer certaines tâches.
Comme nous l'avons vu, le fournisseur d'identités CNRS propose 2 modes d'authentification, par certificat personnel ou par identifiant/mot de passe. Ce choix est celui de l'utilisateur et ne peut être exploité au niveau des applications, car celles-ci n'ont pas connaissance actuellement de la méthode employée. Pourtant cette information, s'il elle était accessible aux applications, permettrait de différencier le niveau de confiance accordée aux différentes méthodes d'authentification.
Pour cela il faudrait proposer différentes méthodes d'authentification (certificat personnel, identifiant/mot de passe, mot de passe à usage unique, …), associées chacune à des niveaux de sécurité différents, correspondants à des politiques de sécurité différentes, et pouvoir identifier les méthodes d'authentifications au niveau des applications qui pourraient les exploiter pour la gestion de leurs accès.
Ainsi des applications sensibles pourraient exiger un mode d'authentification correspondant à un certain niveau de sécurité alors que des applications moins sensibles pourraient se satisfaire d'un mode moins exigeant.
Le fournisseur d'identités d'un organisme comme le CNRS étant utilisé par des applications diverses du point de vue de la sécurité, il est important d'explorer ces possibilités. Sinon, l'alternative, à terme, sera :
soit d'augmenter le niveau de sécurité des modes d'authentification disponibles pour couvrir les besoins en la matière des applications les plus sensibles (nivellement par le haut). Mais exiger un niveau de sécurité très haut pour des applications qui n'en ont pas besoin risque d'être contre-productif en terme de sécurité ;
soit de ne plus utiliser le fournisseur d'identités pour les applications sensibles.
La notion de niveau de confiance (LOA pour Level of Assurance [9] [10]) concerne non seulement le niveau de l'authentification des utilisateurs, mais également le niveau de qualité de l'enregistrement des utilisateurs et des données associées. Elle peut être intéressante non seulement pour les applications « internes » mais également au niveau des fédérations d'identités.
Un projet de gestion d'identités comme JANUS nécessite des compétences diverses autant techniques qu'organisationnelles. Transverse par nature, il est structurant pour l'organisme et exige de tenir compte de l'existant.
Le projet JANUS a permis la mise en place d'un fournisseur d'identités dont les apports sont divers :
il offre un confort aux utilisateurs par le biais de l’unicité de leur compte et de la fonction SSO ;
il offre aux administrateurs d’applications la possibilité de déléguer complètement la gestion de l’authentification au fournisseur d’identités et, grâce à la propagation d’attributs, des possibilités de gestion des droits ;
il permet d'améliorer la sécurité des accès aux applications ;
il permet d'améliorer la qualité des données du système d'information ;
il ouvre la voie à de nouvelles applications.
Par ailleurs, le fournisseur d’identités CNRS a intégré la fédération d’identités Education/Recherche [11] en juillet 2009, permettant ainsi aux personnels du CNRS d'accéder aux ressources de nos partenaires en utilisant leur compte sur le fournisseur d'identités CNRS.
Pour compléter le projet, le volet « gestion des habilitations », qui reste à développer, demande une étude des besoins pour établir l'ensemble des droits, rôles et fonctions qu'il serait intéressant d'intégrer dans le référentiel de Janus. Les outils de gestion associés devront permettre une gestion distribuée et des possibilités de délégation des droits.
Système centralisé qui nécessite un haut niveau de disponibilité, il doit pouvoir s'appuyer sur un référentiel complet dont la gestion sera décentralisée.
The Shibboleth Project,
https://spaces.internet2.edu/display/SHIB2/Home
Fédération d'identités et propagation
d'attributs avec
Shibboleth,
http://www.jres.org/tutoriel/shibboleth-jres2005-article.pdf
Attributs utilisateurs pour la fédération
d'identités, tutoJRES mise en oeuvre de SuPann, avril 2009,
https://federation.renater.fr/_media/docs/supann-federation-010409.pdf
Central Authentication Service,
http://www.jasig.org/cas
Introduction aux architectures web de Single
Sign-on,
http://www.cru.fr/_media/documentation/federation/jres-sso.pdf
Shibboleth Extension Hashib,
https://www.middleware.georgetown.edu/confluence/display/MW/hashib
Terracotta,
http://www.terracotta.org/
Single Logout for Shibboleth,
http://www.switch.ch/export/sites/default/uni/security/aai/event/aai-info-day-2009/slides/AAI-ID09-51-SLO.pdf
NIST Special Publication 800-63,
http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
REFEDs - Level of Assurance,
http://www.terena.org/activities/refeds/loa.html
La fédération Education/Recherche,
https://federation.renater.fr
1Application de ressources humaines sous SAP (Système de Ressources Humaines)
2Application de gestion financière et comptable (Budget Comptabilité et Finances)
3Identity Provider, ou fournisseur d'identités