La réponse courte
L'architecture d'identité dans Salesforce n'est pas un projet technique ponctuel, mais plutôt une couche de contrôle opérationnelle au quotidien : qui se connecte, avec quelle identité, avec quelles permissions, et ce qui se passe quand l'accès n'est plus requis. Le choix entre SAML et OIDC, entre JIT et SCIM, et entre une politique MFA au niveau de l'IdP et une application interne à Salesforce – tous ces éléments peuvent sembler être de simples paramètres de configuration, mais en réalité, ils déterminent le temps nécessaire pour bloquer l'accès d'un employé licencié, et la proportion d'incidents qui ne seront découverts qu'à l'audit.
L'approche correcte ne commence pas par le protocole, mais par deux questions fondamentales : quelle est la source de vérité pour l'identité de l'utilisateur, et quel est le délai maximal autorisé entre un événement d'offboarding et le blocage effectif de l'accès. Toutes les autres décisions en découlent : le type de fédération, la méthode de provisionnement, la politique de session et le processus de « Break Glass ».
Les organisations qui s'interrogent également sur les permissions elles-mêmes, et pas seulement sur l'authentification, trouveront des informations complémentaires dans le modèle de permissions de Salesforce.
La carte des décisions : quatre couches d'identité dans Salesforce
| Couche | Question à résoudre | Options principales | Ce qui se brise si la décision est incorrecte |
|---|---|---|---|
| Fédération et authentification | Qui est le fournisseur d'identité (IdP) et comment Salesforce lui fait confiance | SAML 2.0, OIDC, authentification déléguée | Double connexion, non-conformité d'attributs, brèche de confiance |
| Provisionnement et cycle de vie | Comment un utilisateur est créé, mis à jour et désactivé | Provisionnement JIT, SCIM, création manuelle | Comptes orphelins, accès persistant après le départ |
| Session et MFA | Où le niveau d'authentification et la durée de la session sont appliqués | MFA au niveau de l'IdP, MFA interne à Salesforce, politiques de session | Contournement du MFA par un chemin alternatif, sessions illimitées |
| Break Glass et audit | Que se passe-t-il si l'SSO tombe en panne et qui vérifie les anomalies | Utilisateur d'urgence contrôlé, historique de connexion, Event Monitoring | Dépendance totale à l'IdP, incapacité d'investigation rétrospective |
SAML vs OIDC : pas une question de « ce qui est le plus récent »
Le choix entre les deux protocoles ne doit pas être dicté par une tendance, mais par l'infrastructure existante. SAML fonctionne avec XML et des assertions signées, et est courant dans les organisations dotées de services de fédération Active Directory ou d'un fournisseur d'identité (IdP) existant déjà utilisé par des dizaines d'autres systèmes. OIDC est basé sur OAuth 2.0, est plus léger à maintenir et est particulièrement pratique lorsque le même IdP doit servir à la fois des consommateurs d'API modernes et des connexions utilisateur.
L'erreur fréquente est de choisir ce qui semble « plus avancé » sans vérifier les attributs que l'IdP existant envoie déjà, et comment ils sont mappés à Salesforce (Nom d’utilisateur, ID de fédération, Profil, Groupe d'ensembles d'autorisations). Un mappage d'attributs incorrect lors de la configuration initiale entraîne le plus souvent une correction manuelle de dizaines d'utilisateurs en production, et pas seulement un changement de configuration.
Un point souvent négligé : même en choisissant OIDC ou SAML, il est conseillé de planifier séparément les connexions initiées par l'IdP (IdP-Initiated) et les connexions initiées par le fournisseur de services (SP-Initiated). Certaines des incidents de sécurité les plus courants sont dus au fait que le SP-Initiated reste ouvert alors que l'ensemble du processus de connexion a été conçu uniquement via le portail de l'IdP.
Provisionnement JIT vs SCIM : quand le « juste à temps » ne suffit pas
Le provisionnement JIT (Just-In-Time) crée ou met à jour l'utilisateur dans Salesforce lors de la première connexion, en fonction des données reçues de l'IdP via l'assertion SAML ou le jeton OIDC. C'est pratique, peu coûteux à implémenter et suffisant pour la plupart des organisations où les utilisateurs se connectent régulièrement.
Le problème : le JIT ne résout pas la déprovisionnement. Si un employé est retiré de l'IdP mais ne se connecte plus, son utilisateur reste actif dans Salesforce indéfiniment, car aucun événement ne déclenche de mise à jour. C'est précisément là qu'intervient SCIM (System for Cross-domain Identity Management) : il permet une synchronisation proactive de l'IdP vers Salesforce, y compris la désactivation immédiate lorsqu'un utilisateur est supprimé à la source.
La règle pratique : si l'organisation a une exigence d'offboarding en quelques heures plutôt qu'en jours – sous-traitants, employés temporaires, accès à des données sensibles – SCIM n'est pas un « luxe » mais une exigence de conformité. Si le turnover est lent et que la gouvernance inclut déjà un examen trimestriel des accès, le JIT seul peut suffire, à condition qu'il soit accompagné d'un processus manuel documenté pour un blocage immédiat.
La planification du provisionnement doit toujours être évaluée en fonction de la complexité de l'automatisation qui l'entoure - par exemple, lorsque des Flows sont impliqués pour exécuter une logique d'attribution de permissions lors de la création de l'utilisateur, la comparaison dans Flow vs Apex concernant l'endroit où le code personnalisé est utile est pertinente.
MFA et politique de session : deux couches, pas une seule
Une erreur courante consiste à se contenter du MFA appliqué par le fournisseur d'identité et à supposer qu'il couvre tous les chemins de connexion à Salesforce. En réalité, tant qu'il existe un utilisateur pouvant se connecter directement via login.salesforce.com – par exemple, une intégration, un utilisateur API ou un administrateur disposant d'un accès de secours – une politique MFA distincte est requise, configurée au sein de Salesforce même (Vérification d'identité, Niveaux de sécurité de session).
Parallèlement, la politique de session définit des éléments faciles à manquer : le délai d'expiration de la session (Session Timeout), le « Forcer la déconnexion en cas d'expiration de session », les plages d'adresses IP de connexion (Login IP Ranges), et la nécessité d'une session de haute assurance (High Assurance Session) pour les opérations sensibles (par exemple, la modification de permissions ou l'exportation massive de données). Une organisation qui configure un MFA robuste mais laisse le délai d'expiration de session à la valeur par défaut de deux heures ouvre une fenêtre pendant laquelle un ordinateur volé conserve un accès actif bien au-delà d'un délai raisonnable.
Break Glass et audit : quand le SSO tombe en panne, qui se connecte ?
Une dépendance totale à un IdP externe crée un point de défaillance unique : si l'IdP tombe en panne ou si une erreur est présente dans la configuration de la fédération, personne ne peut se connecter, y compris ceux qui doivent corriger le problème. La solution habituelle est un utilisateur « Break Glass » : un compte super-administrateur avec une authentification indépendante (ne dépendant pas du SSO), un mot de passe géré dans un coffre-fort (Vault) plutôt que stocké dans la mémoire d'une personne, et un MFA distinct.
Il est important de noter que le compte "Break Glass" n'est pas une "porte dérobée pratique" – c'est un mécanisme d'urgence contrôlé. Son utilisation doit déclencher une alerte automatique et être examinée dans un délai d'un jour ouvrable par une partie autre que celle qui l'a utilisé. De nombreuses organisations configurent correctement l'utilisateur, mais négligent la surveillance continue : le mot de passe n'est pas renouvelé, et ses permissions sont trop larges par défaut.
Scénario d'entreprise : échec de l'offboarding dans une compagnie d'assurance de taille moyenne
Imaginons une compagnie d'assurance comptant environ six cents employés, utilisant Okta comme fournisseur d'identité (IdP) et une configuration SAML avec Salesforce mise en place il y a environ trois ans. Le provisionnement est entièrement basé sur le JIT : lorsqu'un nouvel employé se connecte pour la première fois, un utilisateur est créé avec un profil et un groupe d'ensembles d'autorisations en fonction du groupe Okta auquel il appartient.
Dans un cas de figure, un représentant du service client a été licencié un vendredi après-midi. L'équipe informatique l'a immédiatement désactivé dans Okta. En pratique, comme il n'y avait pas de mécanisme SCIM ou de webhook pour synchroniser la désactivation dans Salesforce, son utilisateur est resté actif dans Salesforce – et comme sa session était déjà active depuis le matin et que la fonction "Déconnexion forcée en cas d'expiration de session" n'était pas configurée, il a continué à accéder au système après son licenciement, jusqu'à ce que quelqu'un le remarque lors d'un examen hebdomadaire des accès le lundi.
La solution mise en œuvre n'a pas été une transition complète vers SCIM (ce qui aurait nécessité un projet distinct et un budget d'intégration), mais plutôt l'intégration immédiate de trois actions : l'activation de la fonction « Déconnexion forcée en cas d'expiration de session » pour tous les profils sensibles, la réduction du délai d'expiration de session de 120 minutes à 30 minutes pour les rôles en contact avec les clients, et l'ajout d'une étape automatisée dans le processus d'offboarding de l'entreprise qui exécute une désactivation directe dans Salesforce comme une action indépendante, et non seulement comme une conséquence indirecte de la désactivation dans Okta. SCIM est resté un objectif pour le prochain trimestre, avec un budget et une approbation, mais la lacune la plus dangereuse a été comblée en une semaine.
Risques courants et actions préventives
| Risque | Comment il se manifeste en pratique | Action préventive |
|---|---|---|
| Dépendance totale au JIT sans déprovisionnement | Les utilisateurs ayant quitté l'entreprise restent actifs indéfiniment | Ajouter une étape d'offboarding autonome dans Salesforce, indépendante de la synchronisation |
| MFA uniquement au niveau de l'IdP | Les utilisateurs d'intégration et les administrateurs contournent le MFA par une connexion directe | Politique MFA interne à Salesforce pour tous les types d'utilisateurs |
| Délai d'expiration de session trop long | Un ordinateur volé ou une session laissée ouverte conserve l'accès pendant des heures | Réduire le délai d'expiration et forcer la déconnexion pour les profils sensibles |
| Compte « Break Glass » sans contrôle | L'utilisation du compte d'urgence n'est pas détectée à temps | Alerte automatique et examen dans un jour ouvrable pour chaque utilisation |
| Mappage d'attributs incorrect depuis l'IdP | L'utilisateur reçoit un profil ou un rôle incorrect lors de la première connexion | Vérification complète du mappage dans un environnement Sandbox avant le déploiement en production |
Check-list pour la mise en place ou l'audit de l'architecture d'identité
- ☐ Un IdP unique est défini comme source de vérité, et les conséquences en cas de défaillance sont connues.
- ☐ Un protocole (SAML ou OIDC) a été choisi en fonction de l'infrastructure existante et non d'une tendance.
- ☐ Le mappage des attributs entre l'IdP et le profil/groupe d'ensembles d'autorisations a été testé dans un environnement Sandbox.
- ☐ Une politique claire a été définie : JIT uniquement, ou JIT combiné à SCIM selon les exigences d'offboarding.
- ☐ Le MFA est appliqué également au sein de Salesforce, et pas seulement au niveau de l'IdP.
- ☐ Le délai d'expiration de session et la déconnexion forcée sont configurés en fonction de la sensibilité du profil.
- ☐ Un utilisateur « Break Glass » contrôlé existe, avec un MFA distinct et un mot de passe stocké dans un coffre-fort.
- ☐ Le processus d'offboarding inclut une étape autonome de désactivation dans Salesforce.
- ☐ L'historique de connexion et l'Event Monitoring sont examinés selon un calendrier régulier.
- ☐ Un plan d'examen périodique (Access Review) existe, non pas uniquement basé sur la mémoire du service informatique.
Comment mesurer l'efficacité de l'architecture
La mesure principale n'est pas "le SSO est-il actif", mais le temps de réponse entre un événement dans la source de vérité et un changement correspondant dans Salesforce : combien de temps s'écoule entre la suppression d'un utilisateur dans l'IdP et sa désactivation effective. Un indicateur complémentaire est le pourcentage de connexions effectuées via un chemin inattendu (connexion directe au lieu de passer par l'IdP), qui devrait tendre vers zéro à l'exception des utilisations documentées de "Break Glass". Une troisième mesure est la fréquence de l'examen des permissions par rapport à la situation réelle : tous les changements organisationnels ne transitent pas par l'IdP, c'est pourquoi un examen trimestriel reste essentiel même avec un provisionnement entièrement automatisé.
Pour la mise en œuvre ou l'audit d'une architecture d'identité dans un environnement Salesforce existant, vous pouvez avancer via les Services d'Architecture CRM. Les organisations qui vérifient également la connexion aux systèmes ERP et de paie dans le cadre d'une vision globale de l'identité trouveront des informations complémentaires dans Intégrer Salesforce à un ERP, et une vision architectural plus large dans le Guide d'Architecture CRM.
Résumé
L'architecture d'identité dans Salesforce est conçue une seule fois mais est mise à l'épreuve chaque jour à travers des incidents isolés : un employé qui quitte l'entreprise, une session qui oublie de se fermer, une intégration qui contourne le MFA. Les choix cruciaux (SAML vs OIDC, JIT vs SCIM, double MFA, « Break Glass » contrôlé) ne doivent pas découler des paramètres par défaut de l'IdP, mais du temps de réponse requis pour bloquer l'accès et du niveau de sensibilité des informations exposées. Une organisation qui planifie cette couche en amont, plutôt que de découvrir les lacunes lors d'un audit ou après un incident de sécurité, économise à la fois les coûts de correction et les risques d'atteinte à la réputation et de non-conformité réglementaire.