Authentification dans Reporting Services

L'authentification est le processus d'établissement du droit d'un utilisateur à une identité. De nombreuses techniques vous permettent d'authentifier un utilisateur. La façon la plus courante consiste à utiliser des mots de passe. Lorsque vous implémentez l’authentification par formulaire, par exemple, vous souhaitez une implémentation qui interroge les utilisateurs pour les informations d’identification (généralement par une interface qui demande un nom de connexion et un mot de passe), puis valide les utilisateurs par rapport à un magasin de données, tel qu’une table de base de données ou un fichier de configuration. Si les informations d’identification ne peuvent pas être validées, le processus d’authentification échoue et l’utilisateur suppose une identité anonyme.

Authentification personnalisée dans Reporting Services

Dans Reporting Services, le système d’exploitation Windows traite l’authentification des utilisateurs par le biais de la sécurité intégrée ou de la réception explicite et de la validation des informations d’identification des utilisateurs. L’authentification personnalisée peut être développée dans Reporting Services pour prendre en charge davantage de schémas d’authentification. Cette prise en charge est rendue possible via l’interface IAuthenticationExtension2d’extension de sécurité. Toutes les extensions héritent de l'interface de base IExtension pour toute extension déployée et utilisée par le serveur de rapports. IExtension, et IAuthenticationExtension2, sont membres de l’espace Microsoft.ReportingServices.Interfaces de noms.

Le principal moyen d’authentification auprès d’un serveur de rapports dans Reporting Services est la méthode LogonUser. Ce membre du service Web Reporting Services peut être utilisé pour passer les informations d'identification de l'utilisateur à un serveur de rapports pour validation. Votre extension de sécurité sous-jacente implémente IAuthenticationExtension2.LogonUser qui contient votre code d’authentification personnalisé. Dans l’exemple d’authentification par formulaire, LogonUser effectue un contrôle d’authentification par rapport aux informations d’identification fournies et un magasin d’utilisateurs personnalisé dans une base de données. L’exemple suivant illustre une implémentation de LogonUser :

public bool LogonUser(string userName, string password, string authority)  
{  
   return AuthenticationUtilities.VerifyPassword(userName, password);  
}  
  

L'exemple de fonction suivant est utilisé pour vérifier les informations d'identification fournies :

  
internal static bool VerifyPassword(string suppliedUserName,  
   string suppliedPassword)  
{   
   bool passwordMatch = false;  
   // Get the salt and pwd from the database based on the user name.  
   // See "How To: Use DPAPI (Machine Store) from ASP.NET," "How To:  
   // Use DPAPI (User Store) from Enterprise Services," and "How To:  
   // Create a DPAPI Library" for more information about how to use  
   // DPAPI to securely store connection strings.  
   SqlConnection conn = new SqlConnection(  
      "Server=localhost;" +   
      "Integrated Security=SSPI;" +  
      "database=UserAccounts");  
   SqlCommand cmd = new SqlCommand("LookupUser", conn);  
   cmd.CommandType = CommandType.StoredProcedure;  
  
   SqlParameter sqlParam = cmd.Parameters.Add("@userName",  
       SqlDbType.VarChar,  
       255);  
   sqlParam.Value = suppliedUserName;  
   try  
   {  
      conn.Open();  
      SqlDataReader reader = cmd.ExecuteReader();  
      reader.Read(); // Advance to the one and only row  
      // Return output parameters from returned data stream  
      string dbPasswordHash = reader.GetString(0);  
      string salt = reader.GetString(1);  
      reader.Close();  
      // Now take the salt and the password entered by the user  
      // and concatenate them together.  
      string passwordAndSalt = String.Concat(suppliedPassword, salt);  
      // Now hash them  
      string hashedPasswordAndSalt =  
         FormsAuthentication.HashPasswordForStoringInConfigFile(  
         passwordAndSalt,  
         "SHA1");  
      // Now verify them. Returns true if they are equal.  
      passwordMatch = hashedPasswordAndSalt.Equals(dbPasswordHash);  
   }  
   catch (Exception ex)  
   {  
       throw new Exception("Exception verifying password. " +  
          ex.Message);  
   }  
   finally  
   {  
       conn.Close();  
   }  
   return passwordMatch;  
}  

Flux d’authentification

Le service web Reporting Services fournit des extensions d’authentification personnalisées pour permettre au portail web et au serveur de rapports d’effectuer l’authentification par formulaire.

La méthode LogonUser du service Web Reporting Services est utilisée pour envoyer des informations d'identification au serveur de rapports pour authentification. Le service Web utilise des en-têtes HTTP pour passer un ticket d’authentification (appelé « cookie ») du serveur au client pour les demandes de connexion validées.

L'illustration suivante représente la méthode d'authentification d'utilisateurs auprès du service Web lorsque votre application est déployée avec un serveur de rapports configuré pour utiliser une extension d'authentification personnalisée.

Comme indiqué dans la figure 2, le processus d'authentification est le suivant :

1. Une application cliente appelle la méthode LogonUser du service Web pour authentifier un utilisateur.

2. Le service web passe un appel à la méthode LogonUser de votre extension de sécurité, plus précisément la classe qui implémente IAuthenticationExtension2.

3. Votre implémentation de LogonUser valide le nom d'utilisateur et le mot de passe dans le magasin d'utilisateurs ou l'autorité de sécurité.

4. En cas d'authentification réussie, le service Web crée un cookie et le gère pour la session.

5. Le service Web retourne le ticket d'authentification à l'application appelante sur l'en-tête HTTP.

Lorsque le service Web authentifie avec succès un utilisateur par le biais de l'extension de sécurité, il génère un cookie qui est utilisé pour les demandes suivantes. Le cookie peut ne pas persister dans l’autorité de sécurité personnalisée, car le serveur de rapports ne possède pas l’autorité de sécurité. Le cookie est retourné par la méthode LogonUser du service Web et est utilisé dans les appels de méthode du service Web suivants et dans l'accès URL.

Si vous accédez au serveur de rapports par l’accès URL lorsqu’une extension de sécurité personnalisée est installée, les services Internet (IIS) et ASP.NET gèrent automatiquement la transmission du ticket d’authentification. Si vous accédez au serveur de rapports via l’API SOAP, votre implémentation de la classe proxy doit inclure une prise en charge supplémentaire pour la gestion du ticket d’authentification. Pour plus d'informations sur l'utilisation de l'API SOAP et la gestion du ticket d'authentification, consultez « Utilisation du service Web avec la sécurité personnalisée ».

Authentification par formulaire

L’authentification par formulaire est un type d’authentification ASP.NET dans laquelle un utilisateur non authentifié est dirigé vers un formulaire HTML. Lorsque l'utilisateur fournit des informations d'identification, le système émet un cookie qui contient un ticket d'authentification. Lors des demandes ultérieures, le système case activée d’abord le cookie pour voir si le serveur de rapports a authentifié l’utilisateur.

Reporting Services peut être étendu pour prendre en charge l’authentification par formulaire à l’aide des interfaces d’extensibilité de la sécurité disponibles par le biais de l’API Reporting Services. Si vous étendez Reporting Services pour utiliser l’authentification par formulaire, utilisez le chiffrement TLS (Transport Layer Security), précédemment appelé SSL (Secure Sockets Layer) pour toutes les communications avec le serveur de rapports afin d’empêcher des utilisateurs malveillants d’accéder au cookie d’un autre utilisateur. Le chiffrement TLS permet aux clients et au serveur de rapports de s'authentifier mutuellement et garantit qu'aucun autre ordinateur ne peut lire le contenu des communications entre les deux ordinateurs. Toutes les données envoyées à partir d’un client via une connexion TLS sont chiffrées afin que les utilisateurs malveillants ne puissent pas intercepter les mots de passe ou les données envoyées à un serveur de rapports.

L’authentification par formulaire est implémentée pour prendre en charge les comptes et l’authentification pour les plateformes autres que Windows. Une interface graphique est présentée à un utilisateur qui demande l'accès à un serveur de rapports, et les informations d'identification fournies sont envoyées à une autorité de sécurité pour authentification.

L'authentification par formulaire nécessite qu'une personne soit présente pour entrer des informations d'identification. Pour les applications sans assistance qui communiquent directement avec le service Web Reporting Services, l'authentification par formulaire doit être associée à un schéma d'authentification personnalisé.

L’authentification par formulaire est adaptée à Reporting Services lorsque vous devez répondre aux exigences suivantes :

• Vous devez stocker et authentifier les utilisateurs qui n’ont pas de comptes Microsoft Windows et

• Vous devez fournir votre propre formulaire d’interface utilisateur en tant que page de connexion entre différentes pages d’un site web.

Tenez compte des points suivants lors de l’écriture d’une extension de sécurité personnalisée prenant en charge l’authentification par formulaire :

• Si vous utilisez l'authentification par formulaire, l'accès anonyme doit être activé sur le répertoire virtuel du serveur de rapports dans les services Internet (IIS).

• L’authentification ASP.NET doit avoir la valeur « Forms ». Vous configurez l’authentification ASP.NET dans le fichier Web.config pour le serveur de rapports.

• Reporting Services peut authentifier et autoriser des utilisateurs avec l’authentification Windows ou l’authentification personnalisée, mais pas les deux à la fois. Reporting Services ne prend pas en charge l’utilisation simultanée de plusieurs extensions de sécurité.

Contenu connexe

• Implémenter une extension de sécurité