JI Les systèmes d’autorisation et d’authentification dans AMI Fabian Lambert

Fabian Lambert – JI Le framework AMI AMI : Framework Développé en java. Système de commandes qui retourne un résultat en XML. Système de plugins pour un accès générique à des bases de données. Système fonctionnant avec une logique de projets/sous projets. Applications Web se basant sur AMI : Un servlet qui exécute les commandes AMI. Le résultat des commandes XML est transformé en HTML par transformation XSLT. AMI est le composant de base de deux applications web importantes pour ATLAS : Tag Collector Management du logiciel offline d’ATLAS ATLAS dataset search Recherche de données grilles par métadonnées

Fabian Lambert – JI Tag Collector Tag Collector est un système de gestion de releases de projets.

Fabian Lambert – JI Tag Collector Tag Collector gère les versions et les dépendances de packages, il collabore avec CVS et CMT.

Fabian Lambert – JI Les rôles Tag Collector Tous les utilisateurs n’ont pas les mêmes droits : Project coordinators Droits sur le projet (l’ensemble des groupes) Group coordinators Droits sur leurs groupes et sur l’ensemble des releases qui en font parties. Release coordinators Droits sur leurs releases et sur l’ensemble des versions de packages dans celles-ci. Package managers/developers Droits sur leurs packages et sous packages et sur leurs versions dans les différentes releases En résumé: Les droits sont hiérarchiques. L’utilisateur à accès a certaines commandes en fonction des droits qu’il a sur une instance spécifique d’un élément du projet.

Fabian Lambert – JI ATLAS Dataset Search L’outil officiel de recherche de données ATLAS se base sur AMI

Fabian Lambert – JI Les rôles dans ATLAS dataset search Les utilisateurs ont des droits sur des projets qui correspondent ici à différentes bases de données Rôle AMI natifs AMI_guest_role, AMI_administrator_role… Rôle liés à VOMS (avec certificats) AMIWriter –Peux lire/écrire dans la bases de données d’un projet AMIReader –Peux lire dans nos bases de données d’un projet En résumé : Des droits sur des projets et pas sur des éléments dans un projet. L’obligation de s’adapter à un système extérieur VOMS.

Fabian Lambert – JI Les pré-requis du système d’autorisation Deux applications web qui n’ont pas les mêmes besoins en terme d’autorisations. TagCollector Système à nombreux rôles très hiérarchisés. Droit à donner sur des éléments très spécifiques d’un projet. Atlas Dataset Search : Système avec peu de rôles mais devant être capable d’intégrer les rôles VOMS. L’élément de base sur lequel les droits sont attribués est le projet. Le système de gestion d’autorisations doit donc Gérer l’hétérogénéité des rôles, des projets et des éléments des projets. Etre capable de s’adapter à un système ‘extérieur’. Etre suffisamment générique pour être réutilisable dans d’autres applications.

Fabian Lambert – JI Le système d’autorisation CommandesRôlesEléments Utilisateurs Validateurs Un utilisateur peut avoir plusieurs rôles associés à différentes familles d’éléments voir à un exemplaire d’un élément précis. Un rôle donne droit à exécuter différentes commandes. Si un validateur existe pour une commande, il peux vérifier que l’utilisateur à les droits sur un exemplaire d’une famille d’éléments.

Fabian Lambert – JI Les pré-requis du système d’authentification Au début d’AMI Un système login / password car tout le monde n’avait pas de ‘certificat grille’ Un certificat serveur pour avoir des sites en https. Les besoins ATLAS ATLAS projette de restreindre l’accès aux données aux seuls utilisateurs de sa VO. Beaucoup d’outils grille se base sur l’authentification par certificat et sur la génération de proxy courte-durée VOMS L’authentification dans AMI: Authentification de l’utilisateur à partir du certificat chargé dans son navigateur. Détermination des rôles VOMS d’un utilisateur à partir du certificat chargé dans son navigateur. Capacité d’utiliser n’importe quel outil grille en faisant de la délégation de proxy à partir de nos applications web.

Fabian Lambert – JI Authentification par certificats Serveur apache http AMI Serveur Tomcat 1 AMI Serveur Tomcat 2 Module mod_proxy VOMS admin Web service Serveur VOMS Rôles VOMS Certificat utilisateur 1. Serveur apache http en mode ‘SSLVerifyClient optional’ 2.Load-balancing, création d’une session sécurisée sur un nœud Tomcat 3.Tomcat en mode ‘clientAuth=want’ 4.Extraction par AMI des paramètres DN et Issuer en utilisant l’API glite 5.Interrogation du web service VOMS pour connaitre les rôles utilisateur

Fabian Lambert – JI Les pré-requis de la délégation de proxy Les besoins d’AMI Interfaçage avec des logiciels grille qui utilisent des proxy VOMS (DQ2 par exemple). Récupérer côté serveur un proxy VOMS crée à partir d’un certificat se trouvant côté client. Problèmes des applications web Les navigateurs actuels ne savent pas gérer les proxy VOMS. Impossibilité de récupérer un certificat chargé dans un navigateur. La solution Java Web Start Une application coté serveur qui se charge de manière sécurisée sur le client.

Fabian Lambert – JI Délégation de proxy : Acacia 1.L’utilisateur s’authentifie dans AMI en utilisant un certificat grille 2.AMI autorise l’utilisateur à lancer l’application ‘Java Web Start’ acacia de création de proxy 3.L’utilisateur choisit le certificat (pkcs12) présenté par acacia au serveur VOMS 4.Le serveur VOMS retourne un proxy courte durée 5.Un web service AXIS installé sur Tomcat est utilisé par acacia pour uploader le proxy sur le serveur via une connexion sécurisée 6.La délégation de proxy est disponible sur le serveur 7.Eventuellement, la VO, le groupe et les rôles VOMS de l’utilisateur peuvent être extrait du proxy a des fins d’autorisation.

Fabian Lambert – JI L’interface d’Acacia