Apprentissage du langage de l’identité

Objectifs de formation

Après avoir terminé ce module, vous pourrez :

• Identifier les normes du marché utilisées en gestion d’identité et gestion d’accès
  
• Connaître le lien entre les SAML et le XML
  
• Connaître la différence entre un fournisseur d’identité et un fournisseur de service
  

Normes et protocoles d’identité

Vous avez du mal à croire que vous pouvez continuer à sécuriser les identités de vos utilisateurs alors qu’ils n’ont pas à s’inscrire sur des sites Web ou des applications externes ? Comment les produits si nombreux des entreprises, parfois des produits en concurrence, peuvent-ils travailler ensemble ?

La réponse : grâce aux normes et aux protocoles que le marché utilise pour la gestion d’identité et la gestion d’accès. Cela peut sembler intimidant, mais le concept est simple. Une norme est un ensemble de pratiques largement adoptées par les acteurs du marché. Une norme peut inclure un protocole qui précise la façon dont les systèmes échangent les informations.

Voici les trois protocoles que Salesforce et les autres fournisseurs d’identité suivent pour mettre en œuvre les solutions d’identité.

• SAML
  
• OAuth 2.0
  
• OpenID Connect
  

Protocole SAML

Lorsque vous voulez que les utilisateurs basculent sans heurt entre les organisations et les applications Salesforce sans avoir à se connecter à plusieurs reprises, vous configurez une authentification unique (SSO). Security Assertion Markup Language (SAML) est le protocole qui permet d’y parvenir.

Voici quelques exemples de SAML en action.

• Lorsque vous êtes connecté à Salesforce et que vous cliquez sur le lanceur d’application pour accéder directement à votre boîte de réception Gmail, c’est bien le protocole SAML qui est utilisé.
  
• Lorsque les utilisateurs qui sont déjà connectés à une autre application peuvent accéder à leur organisation Salesforce sans avoir à se reconnecter, c’est encore SAML qui est en action.
  

Assertion SAML

Voici comment fonctionne SAML. Un utilisateur essaie d’accéder à un service. Le fournisseur de service envoie une requête au fournisseur d’identité en lui demandant grosso modo « Bonjour, cet utilisateur peut-il accéder à mon service ? » Le fournisseur d’identité s’assure que les utilisateurs sont ceux qu’ils prétendent être en consultant sa base de données et en renvoyant une réponse (une assertion) disant : « Oui, cet utilisateur est autorisé et voici quelques informations le concernant ».

Attendez une minute. Quelle est la différence entre un fournisseur d’identité et un fournisseur de service ? Le fournisseur d’identité est en fait celui qui authentifie l’utilisateur. Le fournisseur de service demande l’authentification de l’identité. Dans cette unité, nous parlerons plus tard plus en détail des fournisseurs d’identité et de service.

L’assertion correspond aux informations qui sont envoyées. Une assertion peut comporter des informations détaillées sur un utilisateur. Elle peut également inclure des attributs concernant l’utilisateur comme ses prénom et nom, ses coordonnées, peut-être même un poste.

SAML s’exécute en arrière-plan. Vos utilisateurs ne le voient aucunement agir. Ils se contentent de cliquer sur une icône ou un lien et d’ouvrir une autre application sans avoir à fournir d’autres informations ou à se reconnecter. Il arrive que leur destination ait déjà des informations sur eux (ces attributs utilisateur) quand ils y accèdent.

SAML et XML

SAML est un protocole au format XML, ce qui signifie que les packages d’informations échangés sont rédigés en XML. Le langage XML est censé être (presque) lisible par l’utilisateur, de manière à ce que vous ayez une idée de ce qui se passe. C’est une bonne chose lorsque vous essayez de savoir si les choses fonctionnent correctement.

Le diagramme qui suit montre une partie d’assertion SAML. Cela vous paraît du charabia ? Regardez encore et vous verrez que ce n’est pas si compliqué. Elle contient des informations sur le nom d’utilisateur d’un utilisateur, son numéro de téléphone et son prénom.

Dans cet exemple, l’organisation Salesforce transmet les informations de l’utilisateur à une autre application. L’application peut utiliser ces informations pour autoriser l’utilisateur et personnaliser son expérience. Mais chose encore plus importante, l’utilisateur n’a pas à s’identifier une nouvelle fois pour accéder à l’application.

Protocole OAuth 2.0

Oauth (Open Authorization) 2.0 est un protocole ouvert qui permet le partage sécurisé des données entre les applications. L’utilisateur travaille dans une application, mais voit les données dans une autre. Par exemple, vous êtes connecté à votre application mobile Salesforce et vous visualisez les données depuis votre organisation Salesforce.

En arrière-plan, les applications procèdent à une sorte de liaison et demandent ensuite à l’utilisateur d’autoriser ce partage de données. Lorsque les développeurs veulent intégrer leur application dans Salesforce, ils utilisent les API OAuth.

Voici quelques exemples.

• Une application mobile qui extrait des contacts depuis une organisation Salesforce utilise OAuth.
  
• Une organisation Salesforce qui obtient des contacts auprès d’un autre service utilise également OAuth.
  

Vous trouverez ci-dessous un exemple d’une application qui demande à l’utilisateur l’autorisation d’accéder aux informations à l’aide du protocole OAuth 2.0.

Protocole OpenID Connect

Le protocole OpenID Connect ajoute une couche d’authentification en plus d’OAuth 2.0 pour permettre un échange sécurisé des informations utilisateur. À l’instar de SAML, OpenID Connect envoie des informations d’identification d’un service à un autre. Contrairement à SAML, OpenID Connect est conçu pour les réseaux sociaux actuels. Vous est-il déjà arrivé d’installer une nouvelle application et de recevoir une invite du type « Connectez-vous avec votre compte Google » ? L’application utilise dans ce cas le protocole OpenID Connect. Lorsque vous vous identifiez avec Google, vous ne créez pas de compte ni d’autre mot de passe. Google est le seul à détenir ces informations.

Le développeur de l’application a utilisé le protocole OpenID Connect pour activer l’authentification sociale.

Par exemple, lorsque Google vérifie l’identité d’un utilisateur pour le compte d’un autre service, il authentifie l’utilisateur. De cette façon, Google est un fournisseur d’identité.

Salesforce assure une prise en charge pour plusieurs grands fournisseurs d’identité sociale, notamment Google, Facebook et LinkedIn. Si un fournisseur n’est pas pris en charge par défaut, vous pouvez toujours l’utiliser s’il applique le protocole OpenID Connect, comme Amazon et PayPal, par exemple.

Le protocole OpenID Connect présente l’avantage de permettre aux utilisateurs de pouvoir réduire le nombre de comptes, de noms d’utilisateur et de mots de passe distincts. D’un autre côté, les développeurs peuvent authentifier leurs utilisateurs sur les sites Web et les applications sans avoir à détenir et à gérer des fichiers de mots de passe. Ce processus complique davantage la tâche des pirates qui veulent compromettre les comptes utilisateurs.

Fournisseurs de service et fournisseurs d’identité

Au cours du processus d’authentification des utilisateurs, SAML échange les informations d’identité entre le titulaire de l’information, appelé fournisseur d’identité (FI), et le service désiré, appelé fournisseur de service.

Si un utilisateur se connecte à Salesforce, puis accède à Gmail, Salesforce est le fournisseur d’identité et Google le fournisseur de service. Salesforce peut être à la fois un fournisseur de service et un fournisseur d’identité.

Salesforce en tant que fournisseur de service

Les utilisateurs authentifiés peuvent passer d’un fournisseur d’identité externe à Salesforce. Dans ce cas, Salesforce est un fournisseur de service : les utilisateurs veulent avoir accès à ce service et leur fournisseur d’identité leur permet. On retrouve souvent cette configuration Salesforce, car votre entreprise utilise déjà souvent un fournisseur d’identité. Le fournisseur d’identité peut être l’un des nombreux fournisseurs disponibles sur le marché comme Active Directory Federation Services (ADFS) de Microsoft, PingFederate de Ping Identity, la solution open-source Shibboleth ou OpenAM de ForgeRock.

Les utilisateurs se connectent depuis un fournisseur d’identité, puis sont redirigés vers Salesforce (le fournisseur de service). Dans un autre module, vous allez configurer l’authentification SSO avec Salesforce comme fournisseur de service et une application tierce comme fournisseur d’identité externe.

Salesforce en tant que fournisseur d’identité

Les utilisateurs authentifiés peuvent également passer de Salesforce à d’autres clouds et applications. Dans ce cas, Salesforce agit comme fournisseur d’identité et fournit l’authentification SSO aux utilisateurs pour qu’ils se connectent aux différents fournisseurs de service.

Flux SAML pour SSO

Avis aux curieux ! Le diagramme qui suit montre le flux de communication SAML au cours d’une authentification SSO. C’est ce qui se déroule en arrière-plan. Ne vous inquiétez pas si vous ne voulez pas plonger au cœur du processus. Cela ne fait pas partie du test.

L’authentification SSO se déroule à une vitesse fulgurante, mais en plusieurs étapes.

1. L’utilisateur essaie d’accéder à Salesforce.
   
2. Salesforce reconnaît la requête SSO et génère une requête SAML.
   
3. Salesforce renvoie la requête SAML au navigateur.
   
4. Le navigateur redirige la requête SAML au fournisseur d’identité externe.
   
5. Le fournisseur d’identité vérifie l’identité de l’utilisateur et empaquette l’assertion SAML contenant l’authentification de l’utilisateur.
   
6. Le fournisseur d’identité envoie l’assertion SAML au navigateur.
   
7. Le navigateur redirige l’assertion vers Salesforce.
   
8. Salesforce vérifie l’assertion.
   
9. L’utilisateur est à présent authentifié et peut accéder à Salesforce.
   

Références terminologiques sur l’identité

Qu’avez-vous pensé de cours récapitulatif sur les protocoles d’identité ? Quand les termes se ressemblent et que les différences relèvent de la nuance, il peut s’avérer difficile de s’y retrouver. Voici donc un aide-mémoire. En espérant qu’il vous aidera !

Et maintenant ?

Vous avez obtenu beaucoup d’informations sur les normes du marché en matière d’accès et de gestion des identités. Ne vous inquiétez pas s’il est difficile de mettre tout cela en ordre. Pour le moment, rappelez-vous simplement que Salesforce Identity utilise des protocoles pour mettre en œuvre ses fonctionnalités.

À présent, faisons-nous plaisir ! Vous en avez assez des concepts et des définitions ? Mettons un peu en pratique ce que vous avez appris. Plus tard dans ce parcours, vous configurerez les fonctionnalités de sécurité dans votre organisation de développement Salesforce.

Ressources

• Aide Salesforce : Flux SSO SAML
  
• Aide Salesforce : Identification de vos utilisateurs et gestion de leurs accès