21/09/20161 Installation d’un fournisseur d’identités Shibboleth Formation CRU/RENATER 19 et 20 Novembre 2008 Formateurs : Mehdi Hached Olivier Salaün

21/09/20162 Partie 1 Introduction

21/09/20163 Objectif de la formation Installer un fournisseur d'identités Shibboleth, découvrir son paramétrage Ne couvre l'installation d'un service opérationnel

21/09/20164 Tour de table...

21/09/20165 Demo de Shibboleth

21/09/20166 Logistique 9h30h : Introduction : déroulement du TP 12h30 : Pause déjeuner sur place 14h : Présentation Shibboleth 2 : Reprise du TP 16h : Conclusion 17h30 : Fin du TP

21/09/20167 Les postes de travail Postes eleveX.cines.fr OS= CentOS 5.2 Compte eleveX / ciren11 Compte root / cirenadmin

21/09/20168 Le support Version papier Version électronique –Permet le copier/coller –Variable monidp.univ-test.fr => eleveX.cines.fr –Attention « lecture seule » => save as... Un peu directif, mais bon... Prenez votre temps et parcourez les docs en ligne

21/09/20169 Déroulement du TP 1- Installation des pré-requis Java, Tomcat, certificats, NTP 2- Installation de l'IdP Shibboleth 3- Configuration Shibboleth et AJP Connexion LDAP, CAS 5- Tests Le mystère de l'attribute push...

21/09/ Quelques révisions... IdP Fédération Méta-données Shibboleth Attributs utilisateurs Redirections HTTP SAML

21/09/ Idp = Fournisseur d'Identités

21/09/ Fédération Définit un ensemble constitué de –Fournisseurs d'identités –Fournisseurs de services Résout le problème des relations bilatérales Les membres de la fédérations –Partagent un niveau de confiance –Ont un cadre technique –Partagent des méta-données

21/09/ Méta-données Un fichier de méta-données par fédération Gérées par l'opérateur de la fédération Chaque entrée comprend : –Identifiant du fournisseur, URLs, certificat, profils supportés, contacts, description,... Exemple : –

21/09/ Shibboleth Logiciel « open source » : Adapté contexte enseignement / recherche Deux briques distinctes : –fournisseur d'identités –fournisseur de services Logiciels très (trop ?) configurable Le TP couvre l'installation la brique IdP Shibboleth en version 2.1 (publiée en juillet 2008)

21/09/ Attributs utilisateurs Un fournisseur de services a besoin d'authentifier des utilisateurs Le fournisseur d'identités lui transmet un profil utilisateur –Composé d'attributs Attributs issus d'un référentiel (LDAP) –Norme SuPann

21/09/ Transmission des attributs utilisateurs SP IdP LDAP SAML Applicatio n attribute- resolver.xml attribute-filter.xml attribute-policy.xml mail urn:oid: mail schéma inspiré d’une présentation de Switch

21/09/ Redirections HTTP Usage intensif des redirections HTTP –Comme CAS L'utilisateur est redirigé en permanence –Application > SP > WAYF > IdP > CAS > IdP > SP > Application Plugins Firefox utiles : –Web developer –Tamper data

21/09/ SAML Protocole entre le SP et l'IdP –Assertions d'authentification –Assertions d'échange d'attributs –Signature et chiffrement Version 2.0 supportée par Shibboleth 2.x –Interopérabilité possible avec d'autres produits

21/09/ Les briques logicielles IdP Apache mod_ssl mod_prox y Tomcat Servlet idp shibboleth Java casclient certificat clef privée AC de test AJ P SP de test du CRU Serveur CAS de test Annuaire De test SAML

21/09/ Services de Test Fédération de Test du CRU –Enregistrement automatique –Ouvert à tout SP/IdP –Pas d’usages en production SP de test –Utilisable avec n’importe quel IdP de test –Fonctionnement : liste les attributs reçus Référentiel de test –Un seul enregistrement : etudiant1 Serveur CAS de test –Mot de passe=uid

21/09/ Utilisation des certificats Certificats pour sécuriser Apache –Fournis par le CRU pour les besoins du TP –Chapitre 2.3 du support Certificat utilisés par Shibboleth (SAML) –Certificat + clef privée –Générés à l'installation de Shibboleth Certificat du CRU –Vérification de la signature des méta-données –Téléchargé au chapitre 4.2.2

21/09/ A vous de jouer...

Nouveautés, différences avec la version 1, rétrocompatibilité, gestion des attributs Partie 2 Présentation de Shibboleth version 2

publié en mars 2008 en version 2.0 remplacé pour correction de bogues et alerte de sécurité par la version 2.1 Implémente plusieurs mode d’authentification de façon native Nouvelle gestion des attributs et de leur filtrages Meilleure gestion des journaux de log pour un meilleur débogage Shibboleth 2 IdP

Installation améliorée, toujours en ligne de commande Génération automatique d’une clé privée et d’un certificat auto-signé à l’installation Génération des métadonnées de l’IdP accessible directement à l’URL exemple.org/idp/profile/Metadata/SAML Le fichier relying-party.xml est automatiquement peuplé des bonnes données attribute-resolver.xml et attribute-filter.xml basiques mais quasiment prêts à l’emploi Installation de l’IdP 2

L’IdP a vu ses fichiers de configuration grandement modifiés :  relying-party.xml : fichier principal  Configuration des “profiles”, méta-données, certificats, paramètres de sécurité  attribute-resolver.xml : extraction et préparation des attributs  attribute-filter.xml : politique de filtrage des attributs  logging.xml : configuration des différents fichiers de log (process, access, et audit)  login.config : réglages de l’authentification JAAS  handler.xml : contrôle les points de contact de l’IdP  internal.xml & service.xml : Pour des utilisations très avancées de l’IdP Nouveaux fichiers de configuration

La gestion des journaux 1/2 Toutes les erreurs sont journalisées Trois fichiers de logs, tous dans le répertoire $IDP_HOME/logs – idp-process.log – le même que l’IdP 1.3, permet de vérifier le processus IdP – idp-access.log – Fichier à la Apache permettant de journaliser les accès à l’IdP – idp-audit.log – Fichier facilement “parsable” journalisant les infrormations transitantpar l’IdP: type de requêtes, attributs fournis, etc.s

La gestion des journaux 2/2 Le fichier logging.xml éditable pendant l’exécution de l’IdP La gestion des journaux est améliorée (lisibilité, contenance) et optimisée (exécution) Toujours déconseillé de passer en TRACE ou DEBUG en production Le niveau TRACE permet d’avoir une trame utile pour le débogage en cas d’erreurs d’exécutions

L’IdP peut fonctionner selon plusieurs profils : Ils définissent la manière dont l’IdP et les SP s’échangent les assertions de sécurités (authentification et attributs). Dans la fédération du CRU nous avons limité l’utilisation au « attribute push ». L’IdP envoi les attributs avec l’assertion d’authentification le tout est chiffré (necéssite les certificats des SP dans les méta-données) Shibboleth 2, adopte cela par défaut mais par rétro-compatibilité il peut faire du « attribute pull » et « artifact » L’Idp 2 introduit donc 5 profils supplémentaires aux trois pré-existant extraits de la norme SAML 2 Les « profils » Shibboleth IdP

/Status /Metadata/SAML /Shibboleth/SSO /SAML1/SOAP/AttributeQuery /SAML1/SOAP/ArtifactResolution /SAML2/POST/SSO /SAML2/POST-SimpleSign/SSO /SAML2/Redirect/SSO /SAML2/SOAP/AttributeQuery /SAML2/SOAP/ArtifactResolution Les « profils » - Liste

Rétro compatibilité et interopérabilité L’IdP 2 garde les anciens profils Permet une totale rétro-compatibilité avec les versions 1.3.X (pas antérieures) La norme SAML 2 permet l’interopérabilité avec d’autres implémentations de cette norme (Oracle, BEA, Sun…)

L’IdP implémente nativement 4 modes : REMOTE_USER : Un serveur en Frontal positionne cette variable consommée par l’IdP Identifiant/Mot de passe : Branchement de l’IdP grâce à l’interface JAAS (Java Authentication and Autorisation Service) à un annuaire LDAP ou à Kerberos Adresse IP Existence d’une session utilisateur valide (prolongement d’un SSO)  Dans ce TP : Branchement à un serveur SSO-CAS Les modes d’authentification native

Fichiers de configurations plus nombreux et mis par spécialité Validation de la majeur partie de la configuration au démarrage évitant ainsi des exécutions avec des configurations erronées Le JNDIDataConnector disparaît au profit d’une normalisation de type : – La brique Shibboleth IdP dans son fonctionnement naturel en “attribute push” chiffré – Nécessite la présence des certificats des SP dans les méta-données Différences avec les versions 1.x

Configuré dans attribute-resolver.xml On trouve 4 éléments : – Data connector : sert à extraire les données depuis des sources (LDAP, SGBDR) ‏ – Attribute definition : défini les attributs extrait à partir des sources – Attribute encoder : transforme les attributs en XML – Principal connector : lie un “SAML name identifier” à un “principal” Seuls les attributs déclarés dans ce fichier peuvent “quitter” le resolver de l’IdP Les connectors et les definitions peuvent récolter des informations les uns des autres La définition des attributs

S’occupe du branchement à une source de données En cas d’échec un autre Data connector peut prendre le relais Les types de connectors : – Static : déclaration d’une donnée statique – RelationalDatabase : connection à une base SQL – LDAPDirectory : connection à un annuaire – StoredId : crée et retrouve un identifiant depuis une base SQL – ComputedId : crée un identifiant unique en faisant un hash de la requête et du timestamp DataConnector

member urn:exemple.org:entitlement:entitlement1 urn:mace:dir:entitlement:common-lib-terms <resolver:DataConnector id="monLDAP" xsi:type="LDAPDirectory” ldapUrl="ldap://ldap.exemple.org” baseDN="ou=people,dc=exemple,dc=org” principal="uid=monservice,ou=system” principalCredential=“monServicePassword"> DataConnector - exemple

Déclare un attribut avec un identifiant unique dans le fichier du resolver Selon des valeurs qu’un attribut recueille, on peut actionner une nouvelle source d’attributs Il existe plusieurs définitions possible : – Simple: extrait tel quel d’une source – Scoped : ajoute un « scope » à un attribut – Script : manipule/modifie un attribut – RegexSplit : manipule un attribut selon des expressions régulières – … Attribute Definition

Le fichier attribute-filter.xml défini les politiques de fourniture d’attributs aux SP. La syntaxe des « filtering policies » a changé Un fichier de filtering peut contenir plusieurs politiques d’attributs Seuls les attributs contenant une ou plusieurs valeurs autorisées sont fournis Les valeurs permises se basent sur des concordances établies à l’aide de règles booléennes Par défaut, ce fichier est pauvre en directives et en « deny all » Le filtrage en sortie des attributs

Les fonctions de concordances : – Opération booléennes : AND, OR, NOT, ANY – Chaines de caracteres et expressions régulières : AttributeIssuerString, AttributeRequesterString, PrincipalNameString, AuthenticationMethodString, AttributeValueString, AttributeScopeString – Écriture de scripts possible (utilisation avancée) Le filtrage – attribute-filter.xml

Expérimentations L’utilitaire en ligne de commande AACL.sh permet de faire des tests sur la validité de configuration du resolver et du filtre

Redémarrages de Tomcat Pas de redémarrage nécessaire pour les fichies : internal.xml, service.xml, logging.xml et login.config Les autres nécessitent redémarrage de Tomcat : il ne faut pas recharger de la servlet par le « manager » !

21/09/ Partie 3 Conclusion de la formation Passage en production Présentation fédération RENATER

21/09/ Installer un IdP dans votre organisme Comme en TP, mais aussi : –Configuration des attributs –Nommer un shibmaster –Haute disponibilité Utilisation des méta-données de la « vrai » fédération –Laquelle ?

21/09/ La fédération du CRU –Service opérationnel depuis janvier 2006 –Le CRU gère –L’enregistrement des entités –La distribution des méta-données –Le support aux sites –Les membres –IdP : 49 établissements d’enseignement supérieur –SP : 54 ressources, principalement éditeurs de contenus + ressources régionales

21/09/ Les 49 fournisseurs d'identités ENS LSH ENSAIT IUFM de Bretagne IUFM de Montpellier INPL PRES Nancy Université UTC Université Jean Monnet Université Paul Cézanne Université d'Angers Université d'Artois Université de Bordeaux 4 Université de Bourgogne Université de Bretagne Occidentale Université de Bretagne Sud Université de Grenoble 1 Université de Grenoble 2 Université de Grenoble 3 Université de Haute Alsace Université de La Rochelle Université de La Réunion Université de Lille 1 Université de Lille 2 Université de Limoges Université de Lyon 1 Université de Montpellier 1 Université de Montpellier 2 Université de Montpellier 3 Université de Nancy 1 Université de Nancy 2 Université de Nantes Université de Nice Université de Paris 1 Université de Paris 5 Université de Paris 7 Université de Pau Université de Perpignan Université de Poitiers Université de Provence Université de Reims Université de Rennes 1 Université de Rennes 2 Université de Rouen Université de Technologie de Troyes Université de Toulouse 1 Université de Valenciennes Université de la Méditerrannée Université du Littoral Université du Maine

21/09/ La fédération RENATER Fédération à spectre élargi : Enseignement Supérieur + Recherche Notion d'organismes membres et d'organismes partenaires Une migration de la fédération du CRU vers la fédération Renater est en cours de préparation Entrée en phase pilote au 8 Décembre 2008 Ouverture prévue en production au mois de Février 2009

21/09/201647

21/09/ La fédération Renater Un cadre technique : –Shibboleth 1.3 et 2.x –Utilisation Supann 2008 –Profile attribut Push –URL pour les IdP –OID pour les attributs Evolutions à venir –Distribution auto des attribute-filter.xml –Monitoring des IdPs

21/09/ Workflow d'inscription dans la fédération RENATER Activation du service dans SAGA –par responsable technique –désigne 2 responsables fédération Signature charte fédération –par responsable administratif (profil président d'université ou délégation de signature) Inscription technique –par responsables fédération (nommés) –description technique du service

21/09/ A qui s'adresser ? –À partir du 8 décembre –D'ici là –Et jusqu'à février 2009 Support / information –Liste