Comment accéder à un compte Salesforce pour reproduire un bug ?
Tous ceux qui ont été administrateurs Salesforce ont déjà rencontré le besoin de tester ou reproduire une anomalie remontée en production. La première approche est de tenter de la reproduire dans une sandbox mais parfois c’est impossible. Il est alors essentiel de constater l’anomalie avec un utilisateur et on aimerait, pour éviter de le perturber à chaque test, être autonome et accéder à son compte.
Bien sûr, il existe la fonctionnalité recommandée par Salesforce : le « login as » / « se connecter en tant que ». Nous n’éluderons pas cette solution qui doit être privilégiée mais qui, pour diverses raisons, n’est pas toujours possible.
Il existe d’autres possibilités qui sont plus ou moins impactantes et dont on verra les avantages et désavantages.
1. le « login as » / « se connecter en tant que »
C’est la méthode officielle, celle que le support Salesforce utilise. Il faut que l’utilisateur concerné l’autorise en allant dans son paramétrage. Dans la rubrique « mes informations personnelles », sous rubrique « autoriser l’accès à la connexion », il peut donner le droit à l’administrateur de la société (ou au support Salesforce / Partenaire) de prendre en main son compte pendant un temps limité ( 1 jour, 3 jours, 1 semaine, 1 mois, 1 an).
A la suite de cette action, l’administrateur (ou administrateur délégué) peut se connecter à la place de l’utilisateur en allant sur la page de l’utilisateur et en cliquant sur « se connecter en tant que ».
L’avantage de cette solution est que l’accès est consenti par l’utilisateur, révocable et tracé dans le journal d’audit.
En revanche, les applications utilisant Salesforce comme IDP ne seront pas fonctionnelles pour l’administrateur ce qui peut limiter les tests.
L’obligation du consentement peut aussi être un frein si par exemple l’utilisateur n’a pas accès à un ordinateur. Cela pourrait retarder les investigations.
Nous allons donc explorer d’autres pistes.
2. Le partage de mot de passe
Cette solution va enrager tous les RSSI et toutes les personnes sensibles à la sécurité et devrait être à bannir mais je ne peux pas traiter le sujet sans en parler. Il faut donc le consentement de l’utilisateur puisque c’est lui qui va transmettre son mot de passe à l’administrateur. Ainsi ce dernier pourra se loguer exactement comme l’utilisateur.
Pour le MFA, l’administrateur pourra demander à l’utilisateur de valider le challenge ou alors générer un code temporaire sur la fiche de l’utilisateur avant de se connecter avec les informations de l’utilisateur.
Il y aura aucune trace de cette prise de contrôle de compte et j’insiste sur le fait qu’un mot de passe est personnel et ne devrait jamais se partager ! J’en profite pour rappeler les bonnes pratiques en terme de mot de passe:
Vous noterez le point 6.
3. Prendre le contrôle du compte
Si l’utilisateur n’est pas joignable, il est possible de prendre le contrôle de son compte. Pour cela, l’administrateur va replacer le mail du compte de l’utilisateur par son propre mail en demandant un changement de mot de passe et révoquer le MFA. Il pourra définir un mot de passe et un nouveau MFA. Ainsi il aura accès au compte tel que l’utilisateur. Cependant, pendant le test, l’utilisateur ne pourra pas se connecter à Salesforce et au retour de celui-ci, il faudra faire la démarche inverse. Il ne pourra pas accéder au CRM tant que l’administrateur n’aura pas changé son mail et demandé une réinitialisation son mot de passe.
4. Forcer le mot de passe
L’administrateur peut forcer un mot de passe en utilisant du code apex (en anonymous par exemple):
System.setPassword(UserID, password);Puis en générant un code temporaire pour le MFA, il peut se connecter avec le compte de l’utilisateur. Comme dans la solution précédente, l’utilisateur ne pourra donc plus se loguer durant le test et devra redéfinir son mot de passe après les tests.
C’est plus rapide et moins impactant que la solution précédente mais tout aussi intrusif. Attention cependant, en fonction des paramétrages de l’organisation, vous ne pourrez pas modifier 2 fois le mot de passe dans la même journée.
Ce n’est pas une solution que je recommanderais.
5. Utiliser le SSO
Cette méthode peu connue mais néanmoins élégante permet d’avoir un accès identique à l’utilisateur sans qu’il ne puisse réellement s’en apercevoir. Pour cela, vous devez avoir un SSO de configuré sur votre org qui ne se base pas sur l’ID Salesforce.
Supposons qu’il se base sur le champs “Federation ID”, en tant qu’admin vous aurez ce type de configuration :
Et l’utilisateur Standard avec lequel on souhaite reproduire un bug est le suivant :
Si vous avez les droits, vous pouvez donc changer le “Federation ID” pour mettre le votre sur celui de l’utilisateur (en pensant préalablement à avoir changé le vôtre pour éviter les doublons). En utilisant le bouton SSO de login, vous aurez donc accès avec le compte de l’utilisateur ciblé:
En jouant avec deux navigateurs, vous pouvez de plus remettre les bons “Federation ID” une fois la session acquise. Il est peu probable que pendant ces 2 minutes l’utilisateurs soit impacté.
Il faut faire attention à garder un accès avec votre compte admin (via user/mot de passe par exemple, ou avec une session sur un autre navigateur) pour éviter de se faire bloquer avec un compte utilisateur standard, qui, en plus, n’est pas le vôtre et qui vous empêcherait de remettre les “Federation ID”.
Cette approche reste auditable car la modification du champs “Federation Id” est tracé dans le setupAuditTrail.
6. Faire une authentification grâce au JWT Bearer Flow
Dernière méthode de cet article, un peu plus complexe et qui est utilisée dans les intégrations système à système. Il y a plus de prérequis, ce qui la rend plus compliquée à mettre en œuvre : vous aurez besoin d’une connected app sur votre org:
- Qui autorise les connexions pour l’utilisateur ciblé
- Possède le scope web (et d’autres)
- Permet le JWT Bearer flow avec un certificat.
Il vous faudra la clé privée du certificat qui est potentiellement sur l’org (SETUP > Certificate).
Vous trouvez les détails pour récupérer l’access token dans la documentation Salesforce :
Avec cet access token, vous avez accès à Salesforce avec les droits de l’utilisateurs ciblé.
En conclusion
Nous avons vu plusieurs méthodes qui ont des avantages et des inconvénients, il conviendra d’utiliser les plus risquées que dans les cas les plus extrêmes. Il est aussi important de garder en tête certains droits, notamment la modification du champ sur lequel se base le SSO sur les utilisateurs, donne de grands accès. Et que la gestion des certificats et leur sécurité sont extrêmement importantes. C’est d’ailleurs quelque chose qui m’a toujours étonné : lors de la création de sandbox, les certificats et leurs clés privées sont aussi répliquées et exportables.
