SHIBBOLET

Vitthagna BARNIERPaul CLEMENT

M2 MIAGE Nancy 2009/2010

Plan

Introduction Origines Objectifs

I Fonctionnement 1 Définitions : les briques 2 Déroulement 3 Confiance 4 Socle organisationnel

2

Plan (suite)

II Intégration 1 Sans fédération d’identités 2 Avec fédération d’identités 3 Requêtes 4 Délégation avec Shibboleth

III Avantages / Inconvénients 1 Avantages 2 Inconvénients

IV Conclusion

3

Introduction

Shibboleth Mot hébreu : épi, branche, flot, torrent Signification : phrase ou un mot ne pouvant être utilisé

ou prononcé correctement que par les membres d'un groupe (Wikipédia)

Qu’est-ce que c’est ? Logiciel open source pour l’identification sur le web Mécanisme de propagation d’identité développé par

Internet2 regroupant universités et centres de recherches.

4

Introduction (suite)

Internet2 : consortium à but non lucratif pour le développement des technologies permettant de faire atteindre de hauts débits au réseau Internet (Sun Microsystems, Intel, Cisco, etc.)

Très utilisé par la communauté enseignement / recherche

5

Introduction (suite)

Objectifs de Shibboleth : Gain de temps Déléguer l'authentification à l'établissement

d'origine de l'utilisateur Obtenir certains attributs de l'utilisateur (gestion du

contrôle d'accès ou personnalisation des contenus)

6

I Fonctionnement

Basé sur Security Assertion Markup Language (SAML v2 depuis 2005) Standard définissant un protocole pour échanger des

informations liées à la sécurité (authentification, autorisation, attributs) entre un fournisseur d’identités et un fournisseur de services

Interconnexion des Single Sign-On (redirection, cookies, …) entre établissements

Single Sign-On : centralisation des authentifications Approche coopérative avec Shibboleth Chaque utilisateur dépend d'une des entités partenaires L'utilisateur est authentifié par le partenaire dont il dépend

lors de l’accès à un service du réseau. Chaque service du réseau gère indépendamment sa

propre politique de sécurité.

7

I Fonctionnement (suite)

La délégation d’authentification est basée sur le SSO web : une seule authentification pour accéder à plusieurs ressources informatiques. Réduction de temps Centralisation des informations

Simplification Propagation des attributs utilisateur Partage de méta données Définition de règles de confiance

8

I.1 Définitions : les briques

Fournisseur de services (service provider SP) : module d’authentification pour le serveur Web Délègue l'authentification des utilisateurs à un

fournisseur d'identités Transmet le profil utilisateur Gère le contrôle d'accès de manière optionnelle

Un SP choisit à quels fournisseurs de services ses utilisateurs accèdent

9

I.1 Définitions : les briques (suite)

Fournisseur d’identités (Identity provider idP) : module de gestion d’authentification des utilisateurs en réponse à la requête d’un SP L’authentification peut être déléguée à un serveur

CAS (Central Authentification Service) Authentification via login / mot de passe ou certificat

électronique ou les deux Les attributs de l'utilisateur sont extraits d'un

annuaire LDAP, d'une base SQL ou bien calculés, puis propagés au fournisseur de services

Un SP choisit à quels fournisseurs d’identités il ouvre l’accès 10

I.1 Définitions : les briques (suite)

Service de découverte (WAYF) : permet à un utilisateur de sélectionner son organisme de rattachement, c'est-à-dire celui auprès duquel il pourra s'authentifier.

Fédération d’identités : délégation d’authentification et propagation des attributs Niveau de confiance minimal partagé entre les

fournisseurs

11

I.1 Définitions : les briques (suite)

12

I.2 Déroulement

Etapes Accès à une ressource numérique Redirection vers le service de découverte de la

fédération Sélection de l’établissement d’origine Renvoi vers le fournisseur d’identités

Le fournisseur doit disposer d’une Central Authentification Service (CAS) : système d’authentification unique

Obtention des attributs selon l’utilisateur définis par le fournisseur d’identités

13

I.3 Confiance

Confiance accordée par un SP Qualité d’authentification des utilisateurs Qualité des attributs propagés Disponibilité des services d’authentification et de

propagation des attributs

Confiance accordée par un idP Les attributs propagés ne servent qu’aux usages

initialement prévus (accès authentifié mais anonyme avec Shibboleth)

14

I.3 Confiance (suite)

Formalisation des relations de confiance établir un niveau de confiance minimal

Exemples d’engagements pour un idP Disponibilité et sécurisation du service d’authentification Mise à jour du référentiel …

Les formes possibles Respect des bonnes pratiques Engagement contractuel …

15

I.4 Socle organisationnel

Utilisation d’un socle organisationnel : fédération d’autorités d’authentification. Ex : organismes publics, universités, etc.

Les autorités d’identification peuvent définir et normaliser les attributs d’authentification

16

II Intégration

Intérêt de la mise en place d’une fédération d’identités Gérer des accès à des ressources en ligne Accessibilité aux utilisateurs externes

Contexte Mise en place de SSO dans les établissements Nécessité de collaboration entre les établissements

17

II Intégration

Shibboleth fournit un module pour le serveur Web (Apache et IIS).

Ce module permet de protéger des ressources Web sur le serveur de façon assez sommaire. Si ces ressources sont des scripts, les attributs de

l’utilisateur leur seront passés via des variables d’environnement comme pour les scripts CGI.

Tous les fournisseurs de ressources doivent être dûment validés a priori auprès de l’IdP avant de pouvoir l’utiliser, ce qui est une contrainte assez lourde.

18

II.1 Sans fédération d’identités

19

II.2 Avec fédération d’identités

20

II.3 SSO + WAYF

21

Service Provider Le consommateur d’assertions agit comme un pré-filtre Le demandeur d’attributs est chargé de la récupération des

attributs des utilisateurs auprès de l’IdP Le contrôleur d’accès est chargé d’autoriser ou non l’accès

aux ressources demandées

Identity Provider Le service SSO est chargé de l’authentification des utilisateurs L’autorité d’authentification associe le nameIdentifier à

l’identifiant de l’utilisateur. L’autorité d’attributs délivre, en réponse à une demande d’un

SP

II.3 SSO + WAYF (suite)

22

1ère requête vers un SP

1

Celui-ci ne sachant pas quel IdP sera utilisé, le SP redirige le navigateur vers le WAYF

Le WAYF affiche à l’utilisateur une liste d’IdP possibles.

II.3 SSO + WAYF (suite)

23

1

qui a son tour redirige le navigateur vers le serveur SSO, qui propose alors un formulaire d’authentification

La requête suivante vers le WAYF redirige le navigateur vers l’IdP choisi

II.3 SSO + WAYF (suite)

24

Login + Password

1

Le navigateur s’authentifie auprès du serveur SSO, et l’authentification se déroule comme suit :

II.3 SSO + WAYF (suite)

25

Requêtes suivantes vers le même SP

1

Une session étant mise en place entre le navigateur et le SP (ou plutôt le consommateur d’assertions du SP), ni le WAYF, ni l’IdP ni le serveur SSO n’interviennent ensuite pour l’accès au même SP

II.3 SSO + WAYF (suite)

Requêtes suivantes vers un autre SP Lors du choix de l’IdP par l’utilisateur :

Possibilité pour le WAYF de mémoriser ce choix dans le navigateur (à l’aide d’un cookie).

Le WAYF peut utiliser ultérieurement cette information les requêtes suivantes deviennent non bloquantes

(en redirigeant automatiquement vers l’IdP choisi la première fois).

II.3 SSO + WAYF (suite)

27

1

Dans ce cas, l’authentification de l’utilisateur est totalement transparente lors de l’accès à un autre SP.

II.4 Délégation avec Shibboleth

L’utilisateur contacte un SP1.

SP1 fait appel à un SP2. L’utilisateur n’est pas directement en contact avec le SP2, SP1 joue le rôle d’intermédiaire entre l’idP et le SP Final.

Les assertions SAML délivrées par le fournisseur d’identités pourront être chiffrées à destination du SP2 afin d’en assurer la confidentialité (vis-à-vis du SP1).

28

II.4 Délégation avec Shibboleth (suite)

29

nameId

attributs pour SP1

attributs pour SP2 cryptés

attributs pour SP2 cryptés

III Avantages / Inconvénients

Listing des principaux avantages et inconvénients

30

III.1 Avantages

Basé sur des standards (Single sign on, etc.). Interopérabilité avec d’autres logiciels utilisant les mêmes standards.

Apache License 2.0 : open source

Publication sélective des informations

Accès protégé aux ressources en ligne + simplication

Augmentation de la sécurité

Préservation des données personnelles

31

III.2 Inconvénients

Complexité technique SAML, SSL, Tomcat, Apache, LDAP Edition des fichiers de configuration manuelle

Complexité organisationnelle Répartition des tâches Migration des comptes Dédoublonnage de compte

Usine à gaz, formations et supports auprès du CRU ou RENATER

32

IV Conclusion

Bonne solution en termes de gestion de ressources avec accès sécurisé à ces dernières

Gratuité et interopérabilité

Complexe : des formations existent

Intéressant à utiliser pour les institutions publiques ou université pour le partage des ressources communes

33