Membership and Role Provider

Article
09/12/2008

L'exemple Membership and Role Provider montre comment un service peut utiliser les fournisseurs d'appartenances et de rôles ASP.NET pour authentifier et autoriser des clients.

Dans cet exemple, le client est une application console (.exe) et le service est hébergé par les services IIS (Internet Information Services).

Remarque :
La procédure d'installation ainsi que les instructions de génération relatives à cet exemple figurent en fin de rubrique.

L'exemple montre comment :

Un client peut authentifier l'utilisation de la combinaison nom d'utilisateur et mot de passe.
Le serveur peut valider les informations d'identification du client à partir du fournisseur d'appartenances ASP.NET.
Le serveur peut être authentifié à l'aide du certificat X.509 du serveur.
Le serveur peut mapper le client authentifié à un rôle à l'aide du fournisseur de rôles ASP.NET.
Le serveur peut utiliser l'PrincipalPermissionAttribute pour contrôler l'accès à certaines méthodes exposées par le service.

Les fournisseurs d'appartenances et de rôles sont configurés pour utiliser un magasin soutenu par SQL. Une chaîne de connexion et différentes options sont spécifiées dans le fichier de configuration du service. Le fournisseur d'appartenances reçoit le nom SqlMembershipProvider tandis que le fournisseur de rôles reçoit le nom SqlRoleProvider.

<!-- Set the connection string for SQL Server -->
<connectionStrings>
  <add name="SqlConn" 
       connectionString="Data Source=localhost;Integrated Security=SSPI;Initial Catalog=aspnetdb;" />
</connectionStrings>

<system.web>
  <!-- Configure the Sql Membership Provider -->
  <membership defaultProvider="SqlMembershipProvider" userIsOnlineTimeWindow="15">
    <providers>
      <clear />
      <add 
        name="SqlMembershipProvider" 
        type="System.Web.Security.SqlMembershipProvider" 
        connectionStringName="SqlConn"
        applicationName="MembershipAndRoleProviderSample"
        enablePasswordRetrieval="false"
        enablePasswordReset="false"
        requiresQuestionAndAnswer="false"
        requiresUniqueEmail="true"
        passwordFormat="Hashed" />
    </providers>
  </membership>

  <!-- Configure the Sql Role Provider -->
  <roleManager enabled ="true" 
               defaultProvider ="SqlRoleProvider" >
    <providers>
      <add name ="SqlRoleProvider" 
           type="System.Web.Security.SqlRoleProvider" 
           connectionStringName="SqlConn" 
           applicationName="MembershipAndRoleProviderSample"/>
    </providers>
  </roleManager>
</system.web>

Le service expose un point de terminaison unique de communication avec le service, qui est défini à l'aide du fichier de configuration Web.config. Le point de terminaison se compose d'une adresse, d'une liaison et d'un contrat. La liaison est configurée avec une wsHttpBindingstandard, qui utilise par défaut l'authentification Windows. Cet exemple définit la wsHttpBinding standard de manière à utiliser l'authentification du nom d'utilisateur. Le comportement spécifie que le certificat de serveur sera utilisé pour l'authentification du service. Le certificat de serveur doit contenir la même valeur pour le SubjectName que l'attribut findValue dans l'élément de configuration serviceCertificate element of serviceCredentials. De plus, le comportement spécifie que l'authentification de paires nom d'utilisateur/mot de passe est effectuée par le fournisseur d'appartenances ASP.NET et le mappage de rôles est effectué par le fournisseur de rôles ASP.NET en spécifiant les noms définis pour les deux fournisseurs.

<system.serviceModel>
  <services>
    <service 
        name="Microsoft.ServiceModel.Samples.CalculatorService"
        behaviorConfiguration="CalculatorServiceBehavior">
      <!-- use base address provided by host -->
      <endpoint address=""
                binding="wsHttpBinding"
                bindingConfiguration="Binding1" 
                contract="Microsoft.ServiceModel.Samples.ICalculator" />
      <endpoint address="mex"
                binding="mexHttpBinding"
                contract="IMetadataExchange" />
    </service>
  </services>

  <bindings>
    <wsHttpBinding>
      <!-- Set up a binding that uses Username as the client credential type -->
      <binding name="Binding1">
        <security mode ="Message">
          <message clientCredentialType ="UserName"/>
        </security>
      </binding>
    </wsHttpBinding>
  </bindings>

  <behaviors>
    <serviceBehaviors>
      <behavior name="CalculatorServiceBehavior">
        <!-- Configure role based authorization to use the Role Provider -->
        <serviceAuthorization principalPermissionMode ="UseAspNetRoles"
                              roleProviderName ="SqlRoleProvider" />
        <serviceCredentials>
          <!-- Configure user name authentication to use the Membership Provider -->
          <userNameAuthentication userNamePasswordValidationMode ="MembershipProvider" 
                                  membershipProviderName ="SqlMembershipProvider"/>
          <!-- Configure the service certificate -->
          <serviceCertificate storeLocation ="LocalMachine" 
                              storeName ="My" 
                              x509FindType ="FindBySubjectName"
                              findValue ="localhost" />
        </serviceCredentials>
        <!--For debugging purposes set the includeExceptionDetailInFaults attribute to true-->
        <serviceDebug includeExceptionDetailInFaults="false" />
        <serviceMetadata httpGetEnabled="true"/>
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Lorsque vous exécutez l'exemple, le client appelle plusieurs opérations de service sous trois comptes d'utilisateurs différents : Alice, Bob et Charlie. Les demandes et réponses de l'opération sont affichées dans la fenêtre de console cliente. Les 4 appels passés par l'utilisateur « Alice » doivent réussir. L'utilisateur « Bob » doit obtenir à une erreur d'accès refusé lors de la tentative d'appel de la méthode Divide. L'utilisateur « Charlie » doit obtenir à une erreur d'accès refusé lors de la tentative d'appel de la méthode Multiply. Appuyez sur ENTER dans la fenêtre du client pour fermer celui-ci.

Pour configurer, générer et exécuter l'exemple

Pour générer l'édition C# ou Visual Basic .NET de la solution, suivez les instructions indiquées dans Exécution des exemples Windows Communication Foundation.

Assurez-vous d'avoir configuré la base de données des services d'application ASP.NET.

Remarque :
Si vous exécutez SqlExpress, le nom de votre serveur est .\SQLEXPRESS. Ce serveur doit être utilisé lors de la configuration de la base de données des services d'application ASP.NET ainsi que dans la chaîne de connexion Web.config.

Remarque :
Le compte du processus de traitement ASP.NET doit avoir des autorisations sur la base de données créée à cette étape. Utilisez l'utilitaire sqlcmd ou SQL Server Management Studio pour ce faire.

Pour exécuter l'exemple dans une configuration à un ou plusieurs ordinateurs, suivez les instructions ci-dessous.

Pour exécuter l'exemple sur le même ordinateur

Assurez-vous que le chemin d'accès inclut le dossier dans lequel Makecert.exe se trouve.
Exécutez Setup.bat à partir du dossier d'installation de l'exemple. Tous les certificats de service requis pour l'exécution de l'exemple sont ainsi installés.
Lancez Client.exe à partir de \client\bin. L'activité du client s'affiche sur son application de console.
Si le client et le service ne parviennent pas à communiquer, consultez Conseils de dépannage.

Pour exécuter l'exemple sur plusieurs ordinateurs

Créez un répertoire sur l'ordinateur de service. Créez une application virtuelle appelée servicemodelsamples pour ce répertoire à l'aide de l'outil de gestion IIS (Internet Information Services).
Copiez les fichiers du programme de service de \inetpub\wwwroot\servicemodelsamples vers le répertoire virtuel sur l'ordinateur de service. Assurez-vous de copier les fichiers dans le sous-répertoire \bin. Copiez également les fichiers Setup.bat, GetComputerName.vbs et Cleanup.bat sur l'ordinateur de service.
Créez un répertoire sur l'ordinateur client pour les fichiers binaires du client.
Copiez les fichiers programme du client dans le répertoire client sur l'ordinateur client. Copiez également les fichiers Setup.bat, Cleanup.bat et ImportServiceCert.bat sur le client.
Sur le serveur, exécutez setup.bat service. L'exécution de setup.bat à l'aide de l'argument service crée un certificat de service portant le nom de domaine complet de l'ordinateur et exporte ce certificat vers un fichier appelé Service.cer.
Modifiez Web.config afin de prendre en compte le nouveau nom de certificat (dans l'attribut findValue de serviceCertificate element of serviceCredentials), qui est identique au nom de domaine complet de l'ordinateur**.**
Copiez le fichier Service.cer du répertoire de service vers le répertoire client sur l'ordinateur client.
Dans le fichier Client.exe.config sur l'ordinateur client, modifiez la valeur d'adresse du point de terminaison afin qu'elle corresponde à la nouvelle adresse de votre service.
Sur le client, exécutez ImportServiceCert.bat. Cette opération importe le certificat de service du fichier Service.cer dans le magasin CurrentUser - TrustedPeople.
Sur l'ordinateur client, lancez Client.exe à partir d'une invite de commandes. Si le client et le service ne parviennent pas à communiquer, consultez Conseils de dépannage.

Pour procéder au nettoyage après l'exécution de l'exemple

Exécutez Cleanup.bat dans le dossier d'exemples après avoir exécuté l'exemple.

Remarque :
Ce script ne supprime pas de certificats de service sur un client lors de l'exécution de cet exemple sur plusieurs ordinateurs. Si vous avez exécuté des exemples Windows Communication Foundation (WCF) qui utilisent des certificats sur plusieurs ordinateurs, assurez-vous d'effacer les certificats de service installés dans le magasin CurrentUser - TrustedPeople. Pour ce faire, utilisez la commande suivante : `certmgr -del -r CurrentUser -s TrustedPeople -c -n <Fully Qualified Server Machine Name>`, par exemple : `certmgr -del -r CurrentUser -s TrustedPeople -c -n server1.contoso.com`.

Remarque :

Ce script ne supprime pas de certificats de service sur un client lors de l'exécution de cet exemple sur plusieurs ordinateurs. Si vous avez exécuté des exemples Windows Communication Foundation (WCF) qui utilisent des certificats sur plusieurs ordinateurs, assurez-vous d'effacer les certificats de service installés dans le magasin CurrentUser - TrustedPeople. Pour ce faire, utilisez la commande suivante : certmgr -del -r CurrentUser -s TrustedPeople -c -n <Fully Qualified Server Machine Name>, par exemple : certmgr -del -r CurrentUser -s TrustedPeople -c -n server1.contoso.com.

Le fichier de commandes d'installation

Le fichier de commandes Setup.bat inclus avec cet exemple permet de configurer le serveur avec les certificats pertinents pour exécuter une application auto-hébergée qui requiert une sécurité basée sur le certificat du serveur. Ce fichier de commandes doit être modifié pour fonctionner sur plusieurs ordinateurs ou sans hébergement.

Les éléments suivants fournissent une vue d'ensemble des différentes sections des fichiers de commandes afin qu'ils puissent être modifiés pour s'exécuter dans la configuration appropriée.

Création du certificat de serveur
Les lignes suivantes du fichier de commandes Setup.bat créent le certificat de serveur à utiliser. La variable %SERVER_NAME% spécifie le nom du serveur. Modifiez cette variable pour spécifier votre propre nom de serveur. Ce fichier de commandes a comme valeur par défaut « localhost ».
Le certificat est stocké dans le magasin My (personnel) sous l'emplacement de magasin LocalMachine.
```
echo ************
echo Server cert setup starting
echo %SERVER_NAME%
echo ************
echo making server cert
echo ************
makecert.exe -sr LocalMachine -ss MY -a sha1 -n CN=%SERVER_NAME% -sky exchange -pe
```
Installation du certificat de serveur dans le magasin de certificats approuvé du client.
Les lignes suivantes du fichier de commandes Setup.bat copient le certificat de serveur dans le magasin de personnes de confiance du client. Cette étape est requise car les certificats générés par Makecert.exe ne sont pas implicitement approuvés par le système client. Si vous disposez déjà d'un certificat associé au certificat racine approuvé du client, par exemple un certificat émis par Microsoft, cette étape de remplissage du magasin de certificats client avec le certificat de serveur n'est pas requise.
```
certmgr.exe -add -r LocalMachine -s My -c -n %SERVER_NAME% -r CurrentUser -s TrustedPeople
```

Partager via