Le spécialiste européen de la formation certifiante en informatique et management pour les entreprises

La fédération d'identités (Single Sign On) ou le serpent de mer de la décennie

 

Plus ça va, plus le nombre de codes d’accès se multiplient, à tel point qu’il nous arrive (surtout à moi, je le confesse), de tout mélanger...

Trop de sécurité tue-t-il la sécurité ? Vaste question !

Alors que les entreprises continuent d'être confrontées à la difficulté de gérer un nombre toujours plus élevé d'identités d'utilisateurs internes et externes, il nous a paru intéressant de publier sur ce site la récente étude du Gartner qui propose de traiter le sujet via neuf questions élémentaires de fédération des identités afin d'intégrer les changements opérés sur le marché et dans la technologie.

1. Quel rôle la fédération d'identités joue-t-elle dans une stratégie de gestion des identités et dans une plate-forme de gestion des identités ? 
 
La gestion des identités constitue un moyen efficace, gérable, auditable et sécurisé de fournir aux utilisateurs ou processus l'accès aux ressources de l'entreprise, mais elle implique une charge d'administration et de support considérable pour chaque identité gérée. La fédération tente de limiter cette charge et d'améliorer la convivialité pour les utilisateurs en limitant le nombre de gestionnaires pour une identité donnée. Moins une identité spécifique compte de gestionnaires, plus le système tout entier sera efficace ; plus le nombre de systèmes auxquels les utilisateurs peuvent accéder sans s'authentifier de nouveau est élevé, plus la convivialité est grande pour eux.
 
La fédération agit comme un mécanisme périphérique qui se situe en bordure du réseau et partage les informations d'identité avec d'autres mécanismes de fédération avec lesquels il existe une relation de confiance. La technologie de fédération s'appuie sur la confiance accordée aux pratiques d'authentification, d'administration et de confirmation d'identité d'une entité membre, pour certifier que les utilisateurs ou services d'applications peuvent accéder à une ressource externe, et vice versa.
 
La fédération étend ensuite les principes de la gestion des identités au-delà des frontières de l'entreprise. Toutefois, ses objectifs vont bien au-delà de la seule amélioration de la convivialité pour les utilisateurs et englobent la minimisation des coûts et des impératifs de gestion des identités dans l'univers connecté.
 
2. Quels facteurs amènent les entreprises à s'intéresser à la fédération des identités ?

L'externalisation des processus métiers (BPO) a entraîné une multiplication des "îlots d'identités", c'est-à-dire des fournisseurs d'applications externes qui gèrent les identités dans des plates-formes distinctes des systèmes de gestion des identités des entreprises. De nombreuses entreprises considèrent cette pratique risquée et souhaitent gérer ses risques via une relation de confiance avec un partenaire ou un tiers.
 
La fédération d'identités offre un moyen d'atteindre cet objectif en se basant sur des standards, permettant à un fournisseur d'identités de transmettre des informations sur une identité gérée à un fournisseur de ressources ou prestataire de services (également appelé partie utilisatrice). Chaque entité de la communauté de confiance ainsi créée effectue le suivi des identités des individus particulièrement importants (par exemple, les employés et les contacts proches), et les individus authentifiés par leurs propres entités peuvent accéder aux ressources des autres entités sans devoir s'authentifier plusieurs fois.
 
3. Quels facteurs empêchent l'adoption à plus grande échelle de la fédération d'identités ?

L'un des facteurs clés des implémentations existantes de fédération d'identités - l'authentification unique inter domaine - ne constitue pas une proposition de valeur significative pour de nombreuses entreprises. Qui plus est, les initiatives de fédération à plus grande échelle avec des exigences de garantie d'identité élevées (par exemple, dans les services financiers, la santé et certaines initiatives gouvernementales) sont extrêmement complexes et impliquent de nombreuses entreprises différentes. Par contre, il est possible que les entreprises de taille moyenne ne disposent pas de l'infrastructure nécessaire de gestion de l'accès en place pour prendre en charge la fédération.
 
Un certain nombre d'autres facteurs peuvent également présenter des obstacles à l'adoption : il se peut notamment que l'objectif métier visant à fournir aux partenaires potentiels l'accès aux ressources internes soit déjà satisfait à l'aide de méthodes traditionnelles. Par exemple, un détenteur de ressources peut avoir créé des identités d'utilisateur distinctes pour les utilisateurs externes. La création d'une fédération présente encore de nombreux problèmes en matière de processus, de contrôle et de responsabilité.
 
Chaque participant doit faire confiance aux autres participants pour qu'ils exécutent leurs fonctions de gestion des identités et protègent les références d'identité émises ; or l'instauration de la confiance nécessaire peut être extrêmement difficile. Les fédérations reposent généralement sur le principe que les fournisseurs d'identités désactiveront ou supprimeront les identités numériques lorsque les individus partiront ou changeront de statut, mais ces pratiques ne sont ni auditées ni confirmées. En outre, les applications que les partenaires souhaitent fédérer ne sont pas encore forcément adaptées au web, et il peut être trop difficile ou trop onéreux de les modifier.
 
Néanmoins, on constate une hausse des déploiements à mesure que les technologies de fédération deviennent plus omniprésentes, notamment dans le cadre d'autres technologies, telles que les produits de fédération autonomes, les produits de gestion de l'accès web, les passerelles SaaS, les outils de gestion des identités en code source ouvert, et Active Directory de Microsoft. Des boîtes à outils d'intégration plus nombreuses et  plus efficaces, prenant en charge les applications commerciales prêtes à l'emploi, deviennent disponibles. De plus, nous pensons que les entreprises finiront sans doute par trouver de la valeur dans d'autres utilisations des technologies de fédération, telles que le déploiement de services fédérés, les services de jetons de sécurité et les capacités de fédération natives des applications d'entreprise.

4. Quels sont les types d'entreprises qui tirent le plus profit de la fédération d'identités ?

La fédération d'identités est actuellement déployée en grande partie par des entreprises tournées vers l'avenir qui ont identifié des dossiers économiques convaincants (basés sur les économies d'échelle, la convivialité pour les utilisateurs, la réduction de la charge de gestion ou un meilleur contrôle de l'accès). Ces entreprises qui font partie de la "majorité précoce" ont généralement étendu leurs infrastructures informatiques pour inclure un certain nombre de services externes ou d'environnements de cloud computing.
 
Elles gèrent un grand nombre d'identités externes et ont des entreprises partenaires ou des tiers qui gèrent (ou pourraient gérer) ces identités. La fédération d'identités offre une valeur particulière aux très grandes organisations décentralisées (par exemple, l'armée ou d'autres entités gouvernementales) qui y ont recours afin de lier leurs unités opérationnelles ou d'autres départements internes.
 
Un autre cas d'utilisation apportant des avantages élevés implique de vastes communautés de confiance, dans lesquelles les partenaires offrent l'accès aux ressources à d'autres membres de la communauté (par exemple, un consortium d'éducation fournissant des ressources partagées à de multiples universités, ou un grand fabricant fournissant l'accès à ses spécifications de fabrication et informations de maintenance à un grand nombre de parties prenantes externes). Pour plus de détails sur l'implémentation en production de la fédération d'identités et pour connaître des sources d'informations, lisez la note 1.
 
5. La fédération est-elle appropriée pour les entreprises qui utilisent l'externalisation ou les logiciels en tant que service ?

Bon nombre d'entreprises qui recourent à l'externalisation d'applications ou aux logiciels en tant que service recherchent des moyens de réduire la charge d'administration des identités et d'améliorer la convivialité pour les utilisateurs. La fédération devient plus attractive à mesure que le nombre d'applications externalisées augmente, mais l'entreprise et le fournisseur externe doivent être prêts à se fédérer.
 
Le fournisseur doit prendre en charge les protocoles de fédération et être préparé à accepter de nouveaux projets de fédération pour de nouveaux clients, tandis que l'entreprise doit avoir les capacités et compétences techniques nécessaires. Les grands fournisseurs de SaaS les plus sollicités (dont Google et salesforce.com) proposent la fédération à leurs clients professionnels, mais la plupart des fournisseurs de SaaS ne le font pas encore. Les entreprises qui souhaitent se fédérer avec des fournisseurs de logiciels en tant que service cherchent généralement à étendre les capacités de fédération établies, qu'elles soient déployées de manière autonome ou en tant qu'extension d'une implémentation de gestion de l'accès web.
 
Il existe également un marché restreint mais en pleine croissance pour les intermédiaires qui fournissent des passerelles entre les points d'authentification et d'identité d'entreprise (généralement des annuaires) et les services des fournisseurs de SaaS. Ces passerelles peuvent ou non configurer les comptes sur les systèmes SaaS cible, mais elles peuvent exploiter l'authentification des annuaires d'entreprise, ou l'authentification sur la passerelle, pour réduire l'authentification à une ou plusieurs applications SaaS. 
 
6. L'authentification unique pour les ressources à travers différents domaines présente-t-elle des risques pour les entreprises ?

Les entreprises perçoivent généralement le risque dans la relation de confiance entre le fournisseur d'identités et le consommateur d'identités. Il est toutefois important de reconnaître que bon nombre d'entreprises fournissent déjà "manuellement" des informations d'identités à leurs fournisseurs de ressources et partenaires de confiance (par exemple, via des listes d'utilisateurs approuvés).
 
Les entreprises doivent certes envisager des accords de confiance entre les partenaires et les conséquences juridiques possibles de la fédération, mais elles doivent aussi reconnaître que la fédération d'identités n'est guère plus qu'une version automatisée de la confiance qu'elles ont déjà établie. Les entreprises qui envisagent de nouvelles relations de confiance doivent effectuer une analyse du risque qui prend en compte les conséquences juridiques, technologiques et relatives aux processus, et qui identifie les dommages éventuels si la fédération est mal employée. Les questions les plus importantes auxquelles il faut répondre sont les suivantes.
 
- Comment chaque entité participante confirmera-t-elle les identités des utilisateurs internes individuels avant de leur remettre des références d'identité qui peuvent être utilisées, en interne et en externe, dans le cadre de la fédération ?
Les entités doivent s'entendre sur des procédures cohérentes et acceptables pour tous les participants pour une application ou un ensemble d'applications donné. Les entités doivent établir des impératifs et des contrôles pour désactiver ou supprimer les comptes lorsque les individus partent ou changent de poste, et déterminer si les procédures seront auditées. S'il n'existe aucun suivi défini pour s'assurer que les comptes sont correctement gérés, alors des contrôles d'atténuation (généralement dans la clause des responsabilités de l'accord de fédération) doivent être en place.
 
- À quel point la technologie et l'authentification en ligne de chaque entité doivent-elles être sécurisées ?
Prenons un exemple courant : un identifiant et un mot de passe utilisateur seront-ils suffisants pour répondre aux préoccupations liées au risque, ou bien une forme d'authentification plus sécurisée est-elle nécessaire ?
 
- Quels sont les contrôles qui atténueront les attaques de hameçonnage (phishing) et de type "Man-in-the-Browser" (MITB) ?
Les fédérations basées sur le navigateur, telles que les applications web non fédérées, sont vulnérables aux attaques de hameçonnage et MITB, mais une attaque réussie sur le compte d'un utilisateur de la fédération compromet potentiellement les comptes sur tous les services fédérés. L'abandon des mots de passe au profit de méthodes d'authentification renforcées peut atténuer les attaques de hameçonnage, mais les attaques MITB nécessitent d'autres contrôles compensatoires, tels que des capacités de prévention des fraudes.
 
- Quelles entreprises seront responsables (et dans quelle mesure) si la référence d'identité d'une entreprise participante est utilisée pour commettre une fraude ou pour accéder à mauvais escient aux ressources d'une autre entreprise participante ?
Cette question doit être traitée dans l'accord de gouvernance de la fédération si elle ne l'est pas déjà dans les contrats établis.

7. Quels sont les standards utilisés par les fédérations d'identités ?

Le langage de balisage des assertions de sécurité (SAML) d'OASIS (Organization for the Advancement of Structured Information Standards) est le standard de fédération le plus courant dans les implémentations en production. Toutefois, de multiples versions de SAML sont en production, SAML 2.0 (la dernière spécification en date) étant celle qui connaît à ce jour le plus grand succès sur le marché.
 
WSFederation est un standard concurrent qui est soutenu par plusieurs fournisseurs, parmi lesquels Microsoft. WS-Federation utilise le format de jeton SAML pour communiquer les assertions d'identité, mais pas le protocole SAML, et est incompatible avec les fédérations basées sur SAML, sauf si une passerelle de traduction de protocole est introduite. Gartner estime que WSFederation est utilisé dans 10 à 25 % des fédérations en production, la majorité étant des entités centrées sur Microsoft qui se fédèrent entre elles ou qui rejoignent des fédérations multiprotocoles en utilisant des capacités de passerelle. La prise en charge de WS-Federation est disponible "gratuitement" via les services de fédération Active Directory (ADFS), qui accompagnent Windows Server 2003 et ultérieur.
 
Microsoft a annoncé que la prise en charge du protocole SAML et de cas d'utilisation limités de l'authentification unique SAML sera disponible en 2010, avec la sortie d'ADFS 2.0, qui nécessite Windows Server 2008 comme plateforme d'exploitation. WS-Federation restera le protocole de fédération fondamental utilisé dans la pile d'identités de Microsoft, qui repose fortement sur la suite de protocoles WS-*. Toutefois, la capacité de passerelle de fédération SAML d'ADFS 2.0 mettra bel et bien un terme à la bataille mineure entre protocoles qui oppose WS-Federation et SAML, et offrira aux entreprises un moyen de rejoindre des fédérations basées sur SAML sans devoir acheter un outil de fédération autonome ni enrichir un outil de gestion de l'accès web avec des capacités de fédération.
 
OpenID et les fiches d'informations constituent des alternatives à la fédération basique reposant sur SAML pour l'authentification unique. OpenID ne fournit qu'une prise en charge réduite et rudimentaire de l'authentification et est rarement utilisé dans les implémentations qui nécessitent davantage qu'une garantie d'identité limitée. Les fiches d'informations (qui utilisent le standard Identity Metasystem Interoperability sont en train de s'imposer en tant que technologie d'authentification réduite. OpenID et les fiches d'informations seront probablement utilisés au premier plan des cas d'utilisation de l'authentification, tandis que SAML, WSFederation ou les technologies propriétaires seront utilisés en arrièreplan pour effectuer la fédération.
 
8. Comment la fédération et les services web se recoupent-ils ?

Les services web offrent la meilleure méthode de transport pour la transmission des informations de fédération. Les standards et protocoles liés à la fédération (SAML et WSFederation, par exemple) supposent généralement l'existence de mécanismes de services web, et pratiquement toutes les initiatives de fédération actuelles utilisent les services web comme couche de transport.
 
L'environnement orienté services introduit également une autre utilisation des technologies de fédération : les services sont couplés de façon lâche et peuvent consister en de multiples couches de services combinés, si bien que les transactions au sein de l'environnement orienté services sont souvent découplées de l'utilisateur, du processus ou de la session auxquels elles se rapportent. Cela signifie que les informations d'identité doivent être jointes à la transaction de manière sécurisée par un service de jeton de sécurité qui sert d'autorité de confiance. Ce service peut effectuer la conversion, ainsi que la création, des jetons, offrant le type d'assertion d'identité adéquat dans n'importe quelle situation.
 
9. Comment peut-on évaluer les avantages potentiels de la fédération d'identités ?

Toute entreprise qui évalue la fédération d'identités doit commencer en prenant en compte deux facteurs. Le premier facteur à considérer est le nombre d'identités que l'entreprise gère, ainsi que la proportion de ces identités qui sont internes ou externes. Si l'entreprise gère l'accès à ses systèmes internes par un grand nombre d'utilisateurs externes (et s'ils appartiennent à une autre entité ou s'authentifient régulièrement auprès d'un tiers), les arguments jouent fortement en faveur de la fédération.
 
L'arrangement idéal est ce qu'on qualifie parfois de "fédération dans les deux sens", où chaque partenaire gère des ressources pour les utilisateurs de l'autre, et où les deux partenaires tirent ainsi de la valeur de la fédération des identités. Le second facteur à considérer est le nombre de ressources de services externes auxquelles l'entreprise donne accès. Les arguments en faveur de la fédération d'identités ou, sur le court terme, d'une passerelle de gestion des identités et de l'accès (IAM) SaaS, sont plus convaincants lorsque les pratiques de gestion de l'accès sont faibles ou diverses, ou lorsque les utilisateurs doivent gérer un certain nombre de références d'identité pour ces ressources externes dans le cadre de leur travail.
 
________
Note 1
Sources d'informations sur la fédération d'identités et exemples d'implémentations en production
OASIS est une bonne source d'informations sur les standards de fédération.
SAML XML.org offre une liste des gouvernements, établissements d'enseignement supérieur et autres industries qui participent à des projets de fédération.
La Liberty Allianceest une autre source d'informations utile sur les standards de fédération et a publié plusieurs études de cas. La majeure partie de son travail est aujourd'hui reprise par Kantara Initiative.
L'initiative Shibboleth est parrainée par Internet2, un consortium composé en grande partie d'établissements d'enseignement supérieur et de partenaires parmi les gouvernements et organisations internationales. Le nom Shibboleth est également utilisé pour le logiciel que l'initiative a développé afin de prendre en charge la fédération. Plusieurs fédérations basées sur la structure Shibboleth sont déjà en service.
 
Au moins l'une d'entre elles (la fédération InCommon) a documenté ses pratiques, règles et informations techniques. Il existe beaucoup d'autres fédérations basées sur Shibboleth, dont certaines sont relativement importantes. Les gouvernements fournissent de nombreux exemples de fédérations d'identités. Le portail d'authentification électronique du gouvernement fédéral américain n'est aujourd'hui plus en service, mais plusieurs agences du gouvernement américain continuent d'utiliser la fédération pour réunir des propriétés web disparates et pour prendre en charge les interactions avec les entités dans leurs communautés d'intérêt (consultez le site http://idmanagement.gov/ pour plus d'informations). De nombreux autres gouvernements régionaux et nationaux utilisent également la fédération.
 
Légende des acronymes
• ADFS Services de fédération Active Directory
• BPO Externalisation des processus métiers (Business Process Outsourcing)
• IAM Gestion des identités et de l'accès (Identity And Access Management)
• OASIS Organization for the Advancement of Structured Information Standards
• SAML Langage de balisage des assertions de sécurité (Security Assertion Markup Language)

 

Rappels

A/ Les 7 règles pour réussir son projet de single sign-on

1/ Etablir et partager clairement les objectifs du single sign on
2/ Démontrer que le single sign on améliore la conformité réglementaire
3/ Associer activement les utilisateurs au projet
4/ Tenir compte des procédures et politiques établies
5/ Viser la simplicité en termes d’architecture
6/ Publier régulièrement des indicateurs chiffrés
7/ Evaluer l’atteinte des objectifs et planifier la gestion des identités

B/ Les objectifs du single sign-on

1/ Simplifier pour l'utilisateur la gestion de ses mots de passe : plus l'utilisateur doit gérer de mots de passe, plus il aura tendance à utiliser des mots de passe similaires ou simples à mémoriser, abaissant par la même occasion le niveau de sécurité que ces mots de passe offrent ;
2/ Simplifier la gestion des données personnelles détenues par les différents services en ligne, en les coordonnant par des mécanismes de type méta-annuaire ;
3/ Simplifier la définition et la mise en œuvre de politiques de sécurité.

C/ Les trois grandes classes d'approches pour la mise en œuvre de systèmes d'authentification unique :

1/ L’approche centralisée : Le principe de base est ici de disposer d'une base de données globale et centralisée de tous les utilisateurs ou d'un annuaire. Cela permet également de centraliser la gestion de la politique de sécurité. Un exemple de mise en œuvre est le logiciel libre LemonLDAP:NG, un autre exemple est le logiciel libre Vulture.
Cette approche est principalement destinée à des services dépendant tous d'une même entité, par exemple à l'intérieur d'une société au sein de leur gestion des Middleware.

2/ L’approche fédérative : Dans cette approche, dont le système Liberty Alliance est le principal exemple, chaque service gère une partie des données d'un utilisateur (l'utilisateur peut donc disposer de plusieurs comptes), mais partage les informations dont il dispose sur l'utilisateur avec les services partenaires.
Cette approche a été développée pour répondre à un besoin de gestion décentralisée des utilisateurs, où chaque service partenaire désire conserver la maîtrise de sa propre politique de sécurité, comme par exemple un ensemble de sites marchands indépendants d'un point de vue commercial et organisationnel.

3/ L’approche coopérative : L'approche coopérative, dont les systèmes Shibboleth et Central Authentication Service sont les principaux représentants, part du principe que chaque utilisateur dépend d'une des entités partenaires. Ainsi, lorsqu'il cherche à accéder à un service du réseau, l'utilisateur est authentifié par le partenaire dont il dépend. Comme dans l'approche fédérative, cependant, chaque service du réseau gère indépendamment sa propre politique de sécurité.

D/ Les avantages du single sign-on

1/ La réduction de la fatigue de mot de passe : manque de souplesse liée à l'utilisation de différentes combinaisons de nom d'utilisateur et de mot de passe
2/ La réduction du temps passé à saisir le même mot de passe pour le même compte
3/ La réduction du temps passé en support informatique pour des oublis de mots de passe
4/ La centralisation des systèmes d'authentification
5/ La sécurisation à tous les niveaux d'entrée/de sortie/d'accès aux systèmes sans sollicitation multiple des utilisateurs
6/ La centralisation des informations de contrôles d'accès pour les tests de conformités aux différentes normes

E/ Les dangers du single sign-on

Comme le single sign on donne accès à de nombreuses ressources une fois l'utilisateur authentifié (il a les "clés du château"), les pertes peuvent être lourdes si une personne mal intentionnée a accès à des informations d'identification des utilisateurs.
La mise en place du single sign on requiert donc une attention particulière aux informations et méthodes d'authentification qui devraient idéalement être combinées.
 

EGILIA a obtenu
4.9 / 5 sur
11 avis avec Avis-vérifiés.com

EGILIA https://www.egilia.com/images/egilia-v3/home/logo-egilia.png 22 rue du General Foy, 75008 PARIS +33 800 800 900 De 295€ à 15455€