J'ai récemment travaillé sur une solution personnalisée de réinitialisation de mot de passe en libre-service (SSPR) en utilisant FIM 2010 R2. La fonctionnalité SSPR fournie par FIM 2010 R2 est assez complète. Lors des sessions de conception avec le client, ce dernier a décidé qu'il souhaitait utiliser un niveau de sécurité plus élevé pour que les utilisateurs sur Internet puissent réinitialiser leurs mots de passe. Cela a certainement du sens - l'exposition d'une interface où les utilisateurs de l'entreprise peuvent réinitialiser leurs mots de passe est une aubaine pour le service desk, mais elle introduit une surface de menace importante et un risque de sécurité associé.
Il s'agit de s'assurer que la personne qui réinitialise le mot de passe est bien l'utilisateur et non une personne ou un agent malveillant. La principale méthode d'authentification pour la réinitialisation implique que l'utilisateur réponde à une série de questions dont il est le seul à connaître la réponse. Cette méthode est très souvent utilisée de nos jours. Cependant, elle ne satisfait qu'un seul mécanisme d'authentification (appelé "facteur"), que l'utilisateur connaît. Une plus grande sécurité est obtenue en ajoutant un autre facteur : par exemple, un objet (physique) que l'utilisateur a en sa possession.
Une méthode similaire, mais qui n'est pas précisément une méthode à deux facteurs, consiste à exploiter un canal "hors bande" pour envoyer un code à un utilisateur, qu'il n'entrera qu'une seule fois, lors de la réinitialisation de son mot de passe. Il n'est pas surprenant que cette méthode soit appelée "mot de passe à usage unique" (OTP). L'envoi de ce mot de passe à usage unique à l'adresse électronique personnelle de l'utilisateur est un canal évident et de loin le plus courant. (Nous pourrions considérer la "possession" d'une adresse électronique distincte et l'accès à celle-ci comme undeuxième facteur, mais ce n'est pas la même chose que d'avoir une carte à puce physique, un porte-clés ou un dongle). Toutefois, le téléphone portable d'un utilisateur est sans aucun doute un facteur physique que l'utilisateur gardera vraisemblablement en sa possession.
Heureusement, la fonction SSPR de FIM a la capacité d'envoyer un OTP, et peut l'envoyer de plusieurs façons par le biais d'un code d'extension personnalisé. Les utilisateurs peuvent être invités à entrer un mot de passe à usage unique soit par l'intermédiaire d'une autre adresse électronique, soit par un message SMS. Nous avons décidé que le message texte était le meilleur choix pour l'organisation.
Alors, comment le FIM peut-il envoyer des messages SMS ? Nous avons besoin d'un fournisseur de services SMS capable de recevoir et d'acheminer les messages de manière appropriée. Twilio est l'un de ces fournisseurs basés sur Internet. Twilio fournit un service web RESTful et une API publiée permettant une intégration facile avec les applications. J'ai été très impressionné par la simplicité et les performances de son API SMS. Le prix est également très attractif. Cela dépasse le cadre de cet article, mais je pense que toute organisation, quelle que soit sa taille, peut se l'offrir.
Alors, comment faire fonctionner cela avec FIM ? FIM fournit une interface via l'assemblage Microsoft.IdentityManagement.SmsServiceProviderContract inclus dans FIM. La procédure est décrite dans cet article de TechNet.
Voyons donc un exemple d'utilisation de l'API Twilio :
en utilisant Twilio ;
classe Exemple
{
static void Main(string[] args)
{
// your Account Sid and Auth Token are found in your account information online
string AccountSid = " BD7eb96075d6bf7377c05f8bcf25a5294b" ;
string AuthToken = "" ;
var twilio = new TwilioRestClient(AccountSid, AuthToken) ;
var message = twilio.SendMessage(“+14158141829”, “+15558675309”, “Jenny please?! I love you <3”, newstring[] {“https://www.example.com/hearts.png”});
Console.WriteLine(message.Sid) ;
}
}
C'est aussi simple que cela, et c'est l'une des raisons pour lesquelles nous avons choisi Twilio plutôt que d'autres options.
Ainsi, pour FIM SSPR, nous devons créer la dll SmsServiceProvider que FIM utilisera et exploitera cette API. Le code correspondant ressemble à ceci :
using Microsoft.IdentityManagement.SmsServiceProvider ;
en utilisant Twilio ;
public class SmsServiceProvider : ISmsServiceProvider
{
public void SendSms(string mobileNumber,
message en chaîne,
Guid requestId,
Dictionary<string, object> deliveryAttributes)
{
mySMSProvider.SendSms(mobileNumber, message) ;
}
}
classe mySMSProvider
{
chaîne statique AccountSid = "BD7eb96075d6bf7377c05f8bcf25a5294b" ;
chaîne statique AuthToken = "58a93f5d342e842dc572ab131af83757" ;
monSMSProvider()
{
}
public static int SendSms(string userMobileNumber, string message)
{
Int32 result ;
erreur de chaîne ;
// instantiate a new Twilio Rest Client
var client = new TwilioRestClient(AccountSid, AuthToken) ;
var transaction = client.SendMessage(
"678-967-4113", // Le numéro "From" doit être un numéro Twilio compatible avec les SMS.
userMobileNumber, // Numéro "To", en cas d'utilisation du bac à sable, voir la note ci-dessus
// message content, passed in as a parameter from FIM
message) ;
}
...
Nous devons également créer un flux de réinitialisation du mot de passe qui utilise la porte OTP et gérer quelques autres détails de configuration, bien sûr.
Nous savons que la sophistication des attaques automatisées, les techniques de craquage de mots de passe et la fréquence de ces attaques sur des cibles de grande valeur font qu'il est plus important que jamais pour une organisation de trouver un équilibre entre des opérations efficaces et des mesures de sécurité adéquates. La fréquence des failles de sécurité observées récemment montre clairement la nécessité d'une authentification forte telle que les mots de passe à usage unique dans le SSPR.
