SHIBBOLETH – Fédération d’identité

18 décembre 2018 Non Par nospheratus

1 FEDERATION D’IDENTITE

La fédération d’identités permet de simplifier et sécuriser l’accès à des sites web dont l’accès est contrôlé : plate-forme d’enseignement à distance, portail documentaire, application métier…

Elle répond bien aux besoins de mutualisation entre organismes, aux problématiques d’utilisateurs nomades et facilite le respect de la loi “Informatique et libertés“.

Elle est particulièrement adaptée pour certains types de sites :

ceux dont les usagers sont rattachés à des organismes différents, par exemple une plate-forme d’enseignement à distance ou une application métier mutualisée entre les différents organismes d’une Université Numérique en Région
ceux qui doivent contrôler l’accès d’un très grand nombre d’utilisateurs, par exemple une Université Numérique Thématique qui souhaite limiter l’accès à tous les étudiants français d’une certaine discipline
ceux qui doivent contrôler l’accès des utilisateurs sans nécessairement devoir connaitre leur identité, par exemple le portail documentaire d’un éditeur privé de revues scientifiques.

1.1 PRINCIPE

Lr principe de fédération d’identité est un concept qui vise à mettre en place une centralisation des données, et notamment des données d’identité, au sein d’un domaine informatique.

Ainsi un utilisateur ne se connectera qu’une unique fois par session auprès d’une structure reconnue qui lui fournira la preuve de son identité (sous forme de jeton).

L’utilisateur le présentera aux autres ressources qui souhaitent s’assurer de son identité, sans qu’il n’ait à dérouler une nouvelle procédure d’authentification.

Une seule authentification (dite primaire), donc un seul mot de passe, (plus facile donc de faire appliquer une politique de renouvellement et complexité sans se confronter aux utilisateurs récalcitrants).

De plus, la fédération d’identité permet également de centraliser les données d’un utilisateur (comme son adresse mail de contact, un nom, une langue).

Ces données seront appelées attributs et la centralisation permettra notamment de pouvoir modifier ces données plus facilement.

1.2 FONCTIONNEMENT

1.2.1 ACTEURS

La fédération d’identité s’appuie sur 4 acteurs :

les utilisateurs finaux sont les personnes qui vont effectivement se connecter à des sites web via une fédération d’identités. En général elles ne savent pas et ne voient pas que leur connexion a lieu vers une fédération d’identités, c’est transparent pour elles.
les fournisseurs d’identités sont les organismes auxquels sont rattachés les utilisateurs finaux. Par exemple dans la fédération Éducation-Recherche il s’agit d’organismes de recherche et d’établissements d’enseignement. Un fournisseur d’identités a pour rôle d’authentifier ses utilisateurs quand ceux accèdent un site web via la fédération d’identités.
les ressources sont les sites web auxquels peuvent accéder les utilisateurs finaux via une fédération d’identités. Il peut s’agir par exemple de sites d’enseignement à distance, d’outils collaboratifs en ligne, de portail de documentations numérisées…
l’opérateur de la fédération est l’entité qui gère la fédération, a défini ses règles de fonctionnement et prend en charge l’inscription des fournisseurs d’identités et des ressources dans la fédération.

1.2.2 FLUX

Voici le déroulement de l’accès à une ressource par un utilisateur via une fédération d’identités :

l’utilisateur se rend avec son navigateur sur la page d’accueil d’une ressource, par exemple cours-en-ligne.example.org.
Il clique sur le lien “Me connecter”, un nouvelle page s’affiche et il choisit dans cette nouvelle page son organisme de rattachement.
l’utilisateur est automatiquement renvoyé vers la page d’authentification classique de son organisme sur laquelle il peut saisir son identifiant et mot de passe habituel.
si l’authentification réussit, le logiciel fournisseur d’identités de l’organisme va automatiquement récupérer des informations sur l’utilisateur dans le ou les référentiels de l’organisme.
l’utilisateur est renvoyé sur la ressource où il est alors automatiquement authentifié et peut alors l’utiliser.
lors de la redirection de l’utilisateur depuis le fournisseur d’identités vers la ressource, cette dernière reçoit de la part du fournisseur d’identités une preuve informatique d’authentification de l’utilisateur et éventuellement des informations sur l’utilisateur

Remarque : les étapes 3 et 5 ne sont pas vues par l’utilisateur

1.2.3 LOGICIELS

La fédération d’identité utilise les redirections pour rendre les flux transparents pour l’utilisateur.

Pour que la séquence de ces flux fonctionne, il faut que l’organisme jouant le rôle de fournisseur d’identités installe un logiciel de fédération d’identités, appelé identity provider (fournisseur d’identités).

De même pour le site jouant le rôle de ressource, qui doit installer un logiciel service provider en frontal de son application ; cette dernière doit elle-même être rendue compatible avec ce logiciel.

Ces logiciels permettent le rediriger l’utilisateur automatiquement entre la ressource et le fournisseur d’identités, et gère la transmission de la preuve d’authentification et des informations sur l’utilisateur.

Shibboleth est le logiciel de fédération d’identités le plus utilisé dans la communauté enseignement supérieur et recherche.

1.2.4 META-DONNEES : WAYF

L’opérateur de la fédération maintient la liste des ressources et des fournisseurs d’identités inscrits dans la fédération ainsi que les informations techniques sur chacun.

Ces informations sont distribuées publiquement sous forme du fichier de méta-données (voir le fichier de méta-données de la fédération Education-Recherche) et permettent de faire fonctionner les briques logicielles les une avec les autres.

Lors de l’accès à une ressource de la fédération, un utilisateur doit pouvoir indiquer l’organisme qui est capable de l’authentifier. A cet effet la ressource lui présente un menu déroulant (appelé Where Are You From ou ”Discovery Service“) qui répertorie tous les fournisseurs d’identités de la fédération, ou dans certains cas le sous-ensemble de ces fournisseurs d’identités qui permettent l’accès à cette ressource.

Le WAYF est donc la face visible de la fédération pour les utilisateurs.

2 SHIBBOLETH

Shibboleth est une suite de logiciels développée à l’origine par le consortium Internet2 et sous la responsabilité du consortium Shibboleth à présent. Cette suite fournit une solution complète de fédération d’identités. Le principe de la fédération d’identités est de déléguer l’authentification web des utilisateurs à un service d’authentification dans l’organisme d’origine de l’utilisateur.

Le protocole utilisé est SAML 2, utilisé également par d’autres solutions logicielles de ce type.

Les trois briques Shibboleth sont le fournisseur de services, le fournisseur d’identités et le service de découverte (ou DS/WAYF).

Le fournisseur de services est un module d’authentification pour le serveur Web. Il permet de :

déléguer l’authentification des utilisateurs à un fournisseur d’identités,
transmettre le profil utilisateur,
gérer le contrôle d’accès de manière optionnelle.

Le fournisseur d’identités est une application Java (servlet) ; il permet de gérer l’authentification des utilisateurs, en réponse à la requête d’un fournisseur de services. L’authentification peut être déléguée à un serveur SSO-CAS (Central Authentication Service) : l’authentification se fait par login/mot de passe ou certificat électronique ou encore propose les deux ; les attributs de l’utilisateur sont extraits d’un annuaire (AD ou LDAP), d’une base SQL ou bien calculés, puis propagés au fournisseur de services.

Le service de découverte (DS) permet à un utilisateur de sélectionner son organisme de rattachement, c’est-à-dire celui auprès duquel il pourra s’authentifier.

Le service de découverte propose un menu déroulant à l’utilisateur avec la liste des fournisseurs d’identités reconnus.

2.1 GESTION DES META DONNEES

RENATER gère plusieurs cercles de confiance et publie un ou plusieurs fichiers de méta-données pour chacune de ces fédérations :

la Fédération Education-Recherche : l’environnement de production pour la communauté Education/Recherche française.
l’inter-fédération eduGAIN (plus d’info) : l’environnement de production pour la communauté Education/Recherche internationale. Les données publiées proviennent de GEANT, opérateur de eduGAIN.
la Fédération de Test (plus d’info) : l’environnement de test pour les organismes Education/Recherche.

Les fichiers de méta-données font l’objet d’un processus de mise à jour automatique, à partir des données saisies dans le guichet fédération. Ce processus prend en charge la validation du format des méta-données, l’agrégation éventuelle (cas de eduGAIN) et la signature XML des fichiers de méta-données.

Les mises à jour sont publiées à des fréquences différentes selon la version du fichier utilisée, voir la description des versions de méta-données ci-après.

Les méta-données SAML publiées ont une durée de validité de 9 jours. Après cette échéance votre IdP/SP ne sera vraisemblablement plus capable d’utiliser une copie locale d’un fichier de méta-données.

Les méta-données sont construites à partir des informations techniques fournies par les administrateurs des IdP/SP via le guichet fédération. L’enregistrement d’un SP/IdP dans une fédération de production ainsi que la modification de certaines informations techniques sont soumis à validation par les contacts fédération désignés par l’organisme (membre ou partenaire) dont vous dépendez.

2.1.1 CERTIFICAT

Dans Shibboleth, nous configurons la vérification de la signature XML des nouveaux fichiers de méta-données.

Ce certificat disponible sur :

https://metadata.federation.renater.fr/certs/renater-_metadata-_signing-_cert-_2016.pem

est placé dans /opt/shibboleth-idp/credentials.

2.1.2 CONFIGURATION

Pour que l’IdP ou le SP fonctionne vis à vis des autres entités SAML d’une fédération, il faut configurer la brique technique pour charger régulièrement le fichier de méta-données de la fédération.

Nous ajoutons dans le fichier de configuration les 3 ficheirs de méta-données :
: /opt/shibboleth-idp/conf/attribute-resolver.xml…
<MetadataProvider id= »ShibbolethMetadata » xsi:type= »ChainingMetadataProvider » xmlns= »urn:mace:shibboleth:2.0:metadata »>

  …

  <MetadataProvider id= »RENATER−TEST » xsi:type= »metadata:FileBackedHTTPMetadataProvider »
       metadataURL= »https://metadata.federation.renater.fr/test/preview/preview−sps−renater−test−metadata.xml »
       backingFile= »/opt/shibboleth−idp/metadata/preview−sps−renater−test−metadata.xml »>
     <MetadataFilter xsi:type= »metadata:SignatureValidation »
       trustEngineRef= »shibboleth.MetadataTrustEngine2″
       requireSignedMetadata= »true » />
  </MetadataProvider>
  <MetadataProvider id= »EDUGAIN » xsi:type= »metadata:FileBackedHTTPMetadataProvider »
       metadataURL= »https://metadata.federation.renater.fr/edugain/main/main−sps−edugain−metadata.xml »
       backingFile= »/opt/shibboleth−idp/metadata/main−sps−edugain−metadata.xml »>
     <MetadataFilter xsi:type= »metadata:SignatureValidation »
       trustEngineRef= »shibboleth.MetadataTrustEngine2″
       requireSignedMetadata= »true » />
  </MetadataProvider>
  <MetadataProvider id= »RENATER » xsi:type= »metadata:FileBackedHTTPMetadataProvider »
       metadataURL= »https://metadata.federation.renater.fr/renater/main/main−sps−renater−metadata.xml »
       backingFile= »/opt/shibboleth−idp/metadata/main−sps−renater−metadata.xml »>
     <MetadataFilter xsi:type= »metadata:SignatureValidation »
       trustEngineRef= »shibboleth.MetadataTrustEngine2″
       requireSignedMetadata= »true » />
  </MetadataProvider>

</MetadataProvider>
…

Une fois l’application shibboleth redémarrée, les fichiers de méta-données sont récupérés et stockés dans /opt/shibboleth-idp/metadata/ :

/opt/shibboleth-idp/metadata/preview-sps-renater-test-metadata.xml
/opt/shibboleth-idp/metadata/main-sps-edugain-metadata.xml
/opt/shibboleth-idp/metadata/main-sps-renater-metadata.xml

3 DROITS D’ACCES

3.1 LEXISNEXIS

LexisNexis SA est une société française d’édition professionnelle.

Elle couvre les 3 domaines suivants :

La Recherche documentaire & Information.
Lexis 360, la centaine codes et ouvrages publiés chaque année ainsi que plus de 450 volumes d ’encyclopédies JurisClasseur permettent aux professionnels du droit de trouver rapidement des informations pertinentes et de rester à la pointe de l’actualité.
La Gestion de Cabinet.
LexisNexis édite Lexis Poly, des solutions logicielles dédiées à la performance de l’activité des professionnels de tous les secteurs du droit, en s’appuyant sur les technologies les plus avancées et son expertise éditoriale (près de 7500 actes intégrés).
L’Actualité Juridique. Avec ses 31 revues, LexisNexis offre un large choix de titres couvrant l’ensemble des domaines juridiques. Ces revues permettent aux professionnels de maîtriser l’actualité juridique et proposent des analyses de fond rédigées par les plus grandes signatures.

Depuis le 31/12/2016, les accès numériques à LexisNexis se font via une authentication auprès de la fédération d’identité Renater.

Le SP est disponible à l’adresse : https://shib.lexisnexis.com

Pour assurer l’authentication, le SP doit disposer de l’accès à 2 attributs :

eduPersonTargetedID : calculé à partir de l’UID de l’individu et du d’une clé de hashage
eduPersonScopedAffiliation : provient de l’annuaire LDAP de l’Université

La configuration de ces attributs se fait dans le fichier :
: /opt/shibboleth-idp/conf/attribute-resolver.xml…
<resolver:AttributeDefinition id= »eduPersonScopedAffiliation » xsi:type= »Scoped »
    xmlns= »urn:mace:shibboleth:2.0:resolver:ad »  scope= »nosland.com »  sourceAttributeID= »eduPersonAffiliation »>
    <resolver:Dependency ref= »myLDAP » />
    <resolver:AttributeEncoder xsi:type= »SAML1ScopedString » xmlns= »urn:mace:shibboleth:2.0:attribute:encoder »
            name= »urn:mace:dir:attribute−def:eduPersonScopedAffiliation » />
    <resolver:AttributeEncoder xsi:type= »SAML2ScopedString » xmlns= »urn:mace:shibboleth:2.0:attribute:encoder »
            name= »urn:oid:1.3.6.1.4.1.5923.1.1.1.9″ friendlyName= »eduPersonScopedAffiliation » />
</resolver:AttributeDefinition>

<resolver:AttributeDefinition xsi:type= »ad:SAML2NameID » id= »eduPersonTargetedID »
    nameIdFormat= »urn:oasis:names:tc:SAML:2.0:nameid−format:persistent » sourceAttributeID= »computedID »>
    <resolver:Dependency ref= »computedID » />
    <resolver:AttributeEncoder xsi:type= »enc:SAML1XMLObject » name= »urn:oid:1.3.6.1.4.1.5923.1.1.1.10″ />
    <resolver:AttributeEncoder xsi:type= »enc:SAML2XMLObject » name= »urn:oid:1.3.6.1.4.1.5923.1.1.1.10″
         friendlyName= »eduPersonTargetedID » />
</resolver:AttributeDefinition>

<resolver:DataConnector xsi:type= »dc:ComputedId »
    id= »computedID »
    generatedAttributeID= »computedID »
    sourceAttributeID= »uid »
    salt= »XXXXXXXXXXXXXXXXXXXXXX »>
    <resolver:Dependency ref= »myLDAP » />
</resolver:DataConnector>
..

Les autorisations d’accès à ces attributs sont réalisées dans le fichier :
: /opt/shibboleth-idp/conf/attribute-filter.xml…
    <!−− categorie principale d’usager et organisme de rattachement administratif  −−>
    <AttributeRule attributeID= »eduPersonScopedAffiliation »>
      <PermitValueRule xsi:type= »basic:ANY » />
    </AttributeRule>

    <!−− identifiant utilisateur opaque, persistent et specifique a un couple SP/IdP −−>
    <AttributeRule attributeID= »eduPersonTargetedID »>
      <PermitValueRule xsi:type= »basic:ANY » />
    </AttributeRule>
..

3.1.1 TEST

# /opt/shibboleth−idp/bin/aacli.sh −−principal nospheratus−−configDir /opt/shibboleth−idp/conf \
       −−requester https://shib.lexisnexis.com

<?xml version= »1.0″ encoding= »UTF−8″?><saml2:AttributeStatement
   xmlns:saml2= »urn:oasis:names:tc:SAML:2.0:assertion »>
   <saml2:Attribute FriendlyName= »eduPersonScopedAffiliation » Name= »urn:oid:1.3.6.1.4.1.5923.1.1.1.9″
      NameFormat= »urn:oasis:names:tc:SAML:2.0:attrname−format:uri »>
      <saml2:AttributeValue xmlns:xs= »http://www.w3.org/2001/XMLSchema »
          xmlns:xsi= »http://www.w3.org/2001/XMLSchema−instance » xsi:type= »xs:string »>employee@nosland.com
      </saml2:AttributeValue>
      <saml2:AttributeValue xmlns:xs= »http://www.w3.org/2001/XMLSchema »
          xmlns:xsi= »http://www.w3.org/2001/XMLSchema−instance » xsi:type= »xs:string »>member@nosland.com
      </saml2:AttributeValue>
   </saml2:Attribute>

   <saml2:Attribute FriendlyName= »eduPersonTargetedID » Name= »urn:oid:1.3.6.1.4.1.5923.1.1.1.10″
      NameFormat= »urn:oasis:names:tc:SAML:2.0:attrname−format:uri »>
      <saml2:AttributeValue>
         <saml2:NameID Format= »urn:oasis:names:tc:SAML:2.0:nameid−format:persistent »
               SPNameQualifier= »https://shib.lexisnexis.com »>XXXXXXX
         </saml2:NameID>
      </saml2:AttributeValue>
   </saml2:Attribute>
</saml2:AttributeStatement>

CatégorieInformatique