• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Presentation 18 06 2007
 

Presentation 18 06 2007

on

  • 1,066 views

 

Statistics

Views

Total Views
1,066
Views on SlideShare
1,066
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Presentation 18 06 2007 Presentation 18 06 2007 Presentation Transcript

  • Installation d’un fournisseur d’identités Shibboleth CRU / UNR Paris 18 juin 2007, Paris 5 Olivier Salaün, Mehdi Hached, Florent Guilleux
  • Programme
    • 9h30 : accueil et introduction à Shibboleth
    • 10h00 : début des travaux pratiques
    • 12h30 : repas
    • 14h00 : reprise des travaux pratiques
    • 17h00 : conclusion
  • Etapes de la formation
    • Installer et configurer un fournisseur d’identités Shibboleth ( Identity Provider – IdP )
    • Le tester dans la fédération de test du CRU
    • Connecter le fournisseur d’identités avec un serveur CAS
    • Tester la diffusion d’attributs
  • Organisation des travaux pratiques
    • En binômes
    • Un document détaillant les instructions
    • N’hésitez pas à nous demander des précisions ou plus d’explications !
    • Au cours de la journée quelques diapos de présentation pour l’ensemble des participants
  • Introduction à Shibboleth
  • Avant c’était la zone…
    • Certaines ressources pas protégées du tout
    • Contrôle d’accès par adresses IP souvent utilisé
    • Problèmes de gestion des utilisateurs au niveau de la ressource
    • Multiplication des procédures de login
    • Multiplication des comptes donc des mots de passe
    • Difficultés de mise en place de ressources inter-établissements
    Sympa Moodle Université C Moodle Thèses Bibliothèque B Fond docu. Périodiques Contrôle d’accès Ressource Gestion utilisateurs / Authentification Université A Copyright SWITCHaai
  • Avec le SSO, c’était un peu mieux Sympa Moodle Université C Moodle Thèses Bibliothèque B Fond docu. Périodiques Contrôle d’accès Ressource Gestion utilisateurs / Authentification Université A Copyright SWITCHaai
  • Avec le SSO, c’était un peu mieux
    • au niveau local…
    • … mais pareil pour le reste !
    Sympa Moodle Université C Moodle Thèses Bibliothèque B Fond docu. Périodiques Contrôle d’accès Ressource Gestion utilisateurs / Authentification Université A Copyright SWITCHaai SSO SSO
  • Heureusement, la fédération est arrivée ! Sympa Moodle Université C Moodle Thèses Bibliothèque B Fond docu. Périodiques Contrôle d’accès Ressource Gestion utilisateurs / Authentification Université A Copyright SWITCHaai SSO SSO
  • Heureusement, la fédération est arrivée !
    • Pas de gestion de mots de passe des utilisateurs au niveau de la ressource
    • L’utilisateur s’authentifie une seule fois, dans son établissement
    • L’utilisateur a accès à de nouvelles ressources
    • Les ressources ont une plus grande audience
    Sympa Moodle Université C Moodle Thèses Bibliothèque B Fond docu. Périodiques Contrôle d’accès Ressource Gestion utilisateurs / Authentification Université A Copyright SWITCHaai SSO SSO
  • Fonctionnement de Shibboleth : première requête vers un fournisseur de services (SP) Navigateur Fournisseur d’identités (IdP) Fournisseur de services (SP)
  • Fonctionnement de Shibboleth : première requête vers un fournisseur de services (SP) Navigateur Fournisseur d’identités (IdP) Fournisseur de services (SP) userId password nameId nameId nameId attributes
  • Fonctionnement de Shibboleth : point de vue de l’utilisateur Navigateur Fournisseur d’identités (IdP) Fournisseur de services (SP) userId password 1 2 3 4
  • Fonctionnement de Shibboleth : requêtes suivantes vers le même fournisseur de services (SP) Navigateur Fournisseur d’identités (IdP) Fournisseur de services (SP)
  • Architecture logique du SP Fournisseur de service Navigateur Fournisseur d’identités (IdP) attributes nameId userId password nameId nameId attributes Consommateur d’assertions Demandeur d’attributs Contrôleur d’accès Ressource
  • Architecture logique de l’IdP Fournisseur d’identités Service d’authentification Autorité d’authentification Autorité d’attributs nameId attributes userId Consommateur d’assertions Demandeur d’attributs Contrôleur d’accès Ressource Navigateur attributes nameId nameId nameId userId password userId attributes Référentiel utilisateurs Base d’authentification
  • Installation des briques Shibboleth
    • Application J2EE
      • Nécessite Tomcat
    • Module d’authentification
      • Pour Apache
    • Filtre ISAPI
      • Pour IIS
    • Version Java
      • Actuellement en version bêta
    Navigateur Fournisseur de service Fournisseur d’identités
  • Intégration dans le SI d’un fournisseur d’identités Navigateur Service d’authentification Autorité d’authentification Autorité d’attributs Référentiel utilisateurs Serveur SSO Fournisseur de service userId ticket attributes userId nameId nameId
  • Connexion avec le système d’authentification
    • Intégration
      • Filtre J2EE
      • Module Apache
    • Couplage faible
      • Champ d’entête HTTP
    Navigateur Service d’authentification Autorité d’authentification Autorité d’attributs Référentiel utilisateurs Serveur SSO Fournisseur de service userId ticket attributes userId nameId nameId
  • Diffusion d’attributs
    • Comment l'IdP accède-t-il aux attributs et les transfère aux SP ?
    • À quels types de référentiel peut on brancher l'IdP ?
    • Quels sont les types d'attributs que l'on peut définir ?
    • Comment définir les règles qui déterminent quelles attributs fournir aux SP ? Quelle politique de fourniture d'attributs établir ?
  • Connexion avec le référentiel utilisateurs
    • Des sources multiples
      • Bases de données
      • Annuaires LDAP
      • Autres sources
    Navigateur Service d’authentification Autorité d’authentification Autorité d’attributs Référentiel utilisateurs Serveur SSO Fournisseur de service userId ticket attributes userId nameId nameId
  • Contrôle de la diffusion des attributs utilisateur
    • Attribute Release Policy
    • Filtrage des attributs par
      • Fournisseur de services
      • Valeur de l’attribut
    Navigateur Service d’authentification Autorité d’authentification Autorité d’attributs Référentiel utilisateurs Serveur SSO Fournisseur de service userId ticket attributes userId nameId ARP nameId
  • Exemple d’attributs diffusés
    • supannOrganisme
    • eduPersonAffiliation
    • edupersonPrincipalName
    • supannRole
    • mail
    Navigateur Service d’authentification Autorité d’authentification Autorité d’attributs Référentiel utilisateurs Serveur SSO Fournisseur de service C userId ticket attributes userId nameId ARP nameId Fournisseur de service B Fournisseur de service A
      • Comment est ce que l'IdP accède aux attributs et les transfère aux SP ?
    • Les administrateurs de l'IdP définissent les attributs que l'on accepte de relayer aux SP ;
    • L'IdP Shibboleth s'appuie sur des référentiels utilisateurs externes desquels il déduit les attributs à fournir ;
    • Ces attributs sont extraits de la base de données grâce à ce que l'on appelle des data connectors il en existe 3 types : JNDI, JDBC et Static;
    • Les attributs et les data connectors sont définis dans le fichier "reslover.xml" ;
  • resolver.xml <AttributeResolver xmlns: ... > < SimpleAttributeDefinition id=&quot;urn:mace:dir:attribute-def:givenName&quot;> <DataConnectorDependency requires=&quot; data_base &quot; /> </SimpleAttributeDefinition> < SimpleAttributeDefinition id=&quot;urn:mace:cru.fr:attribute-def:supannOrganisme&quot;> <DataConnectorDependency requires=&quot; supann-test &quot;/> </SimpleAttributeDefinition> ... < JDBCDataConnector id=&quot; data_base &quot; minResultSet=&quot;1&quot; maxResultSet=&quot;1&quot; propagateErrors=&quot;true&quot; dbURL=&quot;jdbc:mysql://database.univ-test.fr/test-shib?user=shibboleth&quot; dbDriver=&quot;com.mysql.jdbc.Driver&quot; maxActive=&quot;10&quot; maxIdle=&quot;5&quot;> <Query>SELECT name AS givenName FROM shibboleth WHERE name=?</Query> </JDBCDataConnector> < JNDIDirectoryDataConnector id=&quot; supann-test &quot;> <Search filter=&quot;uid=%PRINCIPAL%&quot;> <Controls searchScope=&quot;SUBTREE_SCOPE&quot; returningObjects=&quot;false&quot; /> </Search> <Property name=&quot;java.naming.factory.initial&quot; value=&quot;com.sun.jndi.ldap.LdapCtxFactory&quot; /> <Property name=&quot;java.naming.provider.url&quot; value=&quot;ldap://ldap.cru.fr/ou=people,dc=univ-test,dc=fr&quot;/> </JNDIDirectoryDataConnector> </AttributeResolver>
  • Les différents types d'attributs possibles
    • simple attribute definition ;
    • composite attribute definition ;
    • regular expression attribute definition ;
    • scriptlet attribute definition ;
    • SAML2 persistent ID attribute definition ;
    Comment se passe le transfert des attributs vers le SP ? La requête du SP contient simplement les noms des attributs demandés en se basant sur le champs id contenant obligatoirement une URN dans la balise de définition de l'attribut : <SimpleAttributeDefinition id =&quot; urn:mace:dir:attribute-def:givenName &quot;>
    • La politique de fourniture d'attributs se définie dans le fichier arp.site.xml ;
    • Un IdP peut accepter de délivrer ou pas des attributs selon les SP :
      • <Rule>
        • <Description>release to anyone</Description>
          • <Target>
            • < AnyTarget />
          • </Target>
        • <Attribute name=&quot;urn:mace:dir:attribute-def:eduPersonAffiliation&quot;>
          • < AnyValue release=&quot; permit &quot; />
        • </Attribute>
      • </Rule>
    Comment définir les règles qui déterminent quelles attributs fournir aux SP ?
  • Comment définir les règles qui déterminent quelles attributs fournir aux SP ? Transfert d'un attribut à tout SP: <Attribute name=&quot; urn:mace:dir:attribute-def:eduPersonPrincipalName &quot;> < AnyValue release=&quot; Permit &quot;> </Attribute> Transfert d'un attribut interdit pour un pour une valeur donnée : <Attribute name=&quot; urn:mace:dir:attribute-def:eduPersonScopedAffiliation &quot;> < Value release=&quot; deny &quot;>member@example.edu</Value> </Attribute>
  • Quelle politique de fourniture d'attributs établir ?
    • Les IdP sont libres de leur politique de fourniture d'attributs, cette politique est définie dans le fichier arp.site.xml ;
    • Il est cependant préférable de ne pas multiplier les cas exceptionnels pour rendre cette politique plus facile à administrer et à faire évoluer si nécessaire ;
    • Les utilisateurs peuvent eux-mêmes décider de délivrer ou pas certains de leur attributs, des applications graphiques de gestion des attributs par les utilisateurs existe : SHARPE ou ArpViewer
    • Page ARP Internet2 : https://spaces.internet2.edu/display/SHIB/IdPARPConfig
  • Conclusion
  • Mise en production d'un fournisseur d'identités
    • Installation de Shibboleth
    • Configuration du resolver d'attributs
    • Paramétrage de l'ARP pour chaque fournisseur de services
    • Définition d'un shibmaster
    • Enregistrement dans la fédération du CRU
      • Convention puis enregistrement web
  • Obligations de la convention
    • Utiliser Shibboleth
    • Utiliser le nommage, la sémantique et les nomenclatures des attributs de la fédération (basé sur SUPANN) http://federation.cru.fr/cru/frattributs.html
    • Documenter le processus d'alimentation des référentiels
    • Journalisation des connexions
    • Assurer une « bonne » disponibilité et sécurité du service d'authentification et des référentiels
  • La fédération du CRU est un cadre technique et organisationnel
    • Aspects non couverts : administratifs, financiers, fonctionnels, etc.
    • La fédération du CRU n’est pas signataire d’un contrat qui peut lier un fournisseur de services à des fournisseurs d’identités
    • Chaque fournisseur est libre de travailler avec les fournisseurs de son choix
  • Les membres de la fédération du CRU
    • 27 fournisseurs d'identités ( établissements d’enseignement supérieur sous tutelle du ministère en charge de l’enseignement supérieur)
      • Universités, IUFM
    • 15 fournisseurs de services (tout type d’institution ou d’entreprise)
      • Ressources documentaires (ABES, Science Direct, EBSCO)
      • Ressources UNR (pédagogiques, wi-fi)
    • Le CRU : pilotage, administrativia (inscriptions), support aux établissement, information/formation
  • A venir...
    • IdP par défaut (opéré par le CRU)
    • Nouveaux services
      • Editeurs : Ovid, JSTOR, Cairn
      • Les UNT (planifié pour UNJF)
      • Les services du CRU (universalistes, sourcesup,...)
      • Groupe logiciel : serveur d'antivirus, intranet
      • Projet avec les rectorats
      • Microsoft (MSDN-AA)
  • Évolutions de la fédération du CRU
    • Passage à Shibboleth 2.0
    • Extension des attributs reconnus dans la fédération
      • Étapes, disciplines, entitlement, ...
    • Distribution des ARPs associées à chaque fournisseur de services
    • Elargissement du périmètre de la fédération du CRU ?
  • Shibboleth 2.0
    • Actuellement en version beta
    • Apports :
      • Utilise SAML 2.0
      • Attribute push (donc cryptage des données)
      • Fonctionnement multi-tiers
      • Single logout
      • Resolver d'attributs au niveau du SP
      • Changement d'API entre d'IdP et le SSO (IdP en frontal) ; permet les niveaux d'authentification
  • Les applications compatibles
    • Tous les pays contribuent
      • http://wiki.internet2.edu/confluence/display/seas
    • Contribution du CRU
      • Sympa, dokuwiki, mod_authSympa, gforge
    • Comment « shibboliser » ?
      • Article du CRU pour JRES, novembre 2007
      • Formation à la rentrée 2007 ?