Apprentissage du langage de l’identité
Objectifs de formation
- 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é
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
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
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 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é
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éFlux SAML pour SSO
- L’utilisateur essaie d’accéder à Salesforce.
- Salesforce reconnaît la requête SSO et génère une requête SAML.
- Salesforce renvoie la requête SAML au navigateur.
- Le navigateur redirige la requête SAML au fournisseur d’identité externe.
- Le fournisseur d’identité vérifie l’identité de l’utilisateur et empaquette l’assertion SAML contenant l’authentification de l’utilisateur.
- Le fournisseur d’identité envoie l’assertion SAML au navigateur.
- Le navigateur redirige l’assertion vers Salesforce.
- Salesforce vérifie l’assertion.
- L’utilisateur est à présent authentifié et peut accéder à Salesforce.
Références terminologiques sur l’identité
Un terme | Aisément confondu avec ce terme |
---|---|
L’authentification correspond à l’identité de la personne. Aujourd’hui, l’authentification est souvent utilisée comme raccourci pour désigner l’autorisation et l’authentification. | L’autorisation correspond à ce que peut faire une personne. |
Le protocole précise l’ensemble de règles qui permettent aux systèmes d’échanger des informations. En général, les termes protocole et norme sont interchangeables. | La norme est une spécification, un ensemble de pratiques du marché que les fournisseurs acceptent de suivre. Souvent, une norme contient un protocole qui précise la manière dont les entreprises appliquent la norme. |
Le nom d’utilisateur et le mot de passe correspondent aux informations que l’utilisateur saisit pour se connecter à un système. | Le terme identifiants désigne les mêmes informations. |
L’authentification unique (SSO) permet à une personne de se connecter une seule fois et d’accéder à d’autres applications et services sans avoir à se reconnecter. | L’authentification sociale permet à une personne de se connecter à une application à l’aide des identifiants de son compte social tel que Google. L’application accepte les identifiants Google et l’utilisateur n’a pas besoin de créer un autre compte et un autre mot de passe. |
Le fournisseur d’identité est un service de confiance qui permet aux utilisateurs d’accéder à d’autres sites et services Web sans avoir à se reconnecter. | Le fournisseur de service est un site ou un service Web qui héberge des applications et accepte l’identité d’un fournisseur d’identité. |