Upload
denver
View
42
Download
1
Tags:
Embed Size (px)
DESCRIPTION
SHIBBOLET. Vitthagna BARNIER Paul 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. Plan (suite). II Intégration 1 Sans fédération d’identités - PowerPoint PPT Presentation
Citation preview
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