Mitgliedschafts- und Rollenanbieter

Artikel
09/03/2008

Im Beispiel zum Mitgliedschafts- und Rollenanbieter wird veranschaulicht, wie ein Dienst mithilfe der ASP.NET-Mitgliedschafts- und Rollenanbieter Clients authentifizieren und autorisieren kann.

In diesem Beispiel ist der Client eine Konsolenanwendung (.exe), und der Dienst wird von Internetinformationsdiensten (IIS) gehostet.

Tipp

Die Setupprozedur und die Erstellungsanweisungen für dieses Beispiel befinden sich am Ende dieses Themas.

In diesem Beispiel werden folgende Vorgänge veranschaulicht:

Ein Client kann die Authentifizierung mithilfe einer Kombination aus Benutzername und Kennwort durchführen.
Der Server kann die Clientanmeldeinformationen anhand des ASP.NET-Mitgliedschaftsanbieters überprüfen.
Der Server kann mit dem X.509-Zertifikat des Servers authentifiziert werden.
Der Server kann den authentifizierten Client mit dem ASP.NET-Rollenanbieter einer Rolle zuordnen.
Der Server kann mit PrincipalPermissionAttribute den Zugriff auf bestimmte Methoden steuern, die vom Dienst verfügbar gemacht werden.

Die Mitgliedschafts- und Rollenanbieter werden für die Verwendung eines Speichers konfiguriert, der von SQL unterstützt wird. Eine Verbindungszeichenfolge und verschiedene Optionen werden in der Dienstkonfigurationsdatei angegeben. Dem Mitgliedschaftsanbieter wird der Name SqlMembershipProvider zugewiesen, und dem Rollenanbieter wird der Name SqlRoleProvider zugewiesen.

<!-- 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>

Der Dienst macht einen einzigen Endpunkt zur Kommunikation mit dem Dienst verfügbar. Dieser wird mit der Konfigurationsdatei Web.config definiert. Der Endpunkt besteht aus einer Adresse, einer Bindung und einem Vertrag. Die Bindung wird mit einer Standard-wsHttpBinding konfiguriert, die standardmäßig die Windows-Authentifizierung verwendet. In diesem Beispiel wird die Standard-wsHttpBinding auf die Verwendung der Benutzernamenauthentifizierung festgelegt. Das Verhalten gibt an, dass das Serverzertifikat für die Dienstauthentifizierung verwendet werden soll. Das Serverzertifikat muss für SubjectName denselben Wert wie das findValue-Attribut im serviceCertificate element of serviceCredentials-Konfigurationselement enthalten. Außerdem gibt das Verhalten an, dass die Authentifizierung von Benutzername/Kennwort-Paaren vom ASP.NET-Mitgliedschaftsanbieter und die Rollenzuordnung vom ASP.NET-Rollenanbieter ausgeführt werden soll, indem die für die beiden Anbieter definierten Namen angegeben werden.

<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>

Wenn Sie das Beispiel ausführen, ruft der Client die unterschiedlichen Dienstvorgänge unter drei verschiedenen Benutzerkonten auf: Alice, Bob und Charlie. Die Anforderungen und Antworten des Vorgangs werden im Clientkonsolenfenster angezeigt. Alle 4 Aufrufe als Benutzer "Alice" sollten erfolgreich sein. Für Benutzer "Bob" sollte der Versuch, die Divide-Methode aufzurufen, zu einem Zugriffsverweigerungsfehler führen. Bei Benutzer "Charlie" sollte beim Versuch, die Multiply-Methode aufzurufen, ein Zugriffsverweigerungsfehler auftreten. Drücken Sie im Clientfenster die EINGABETASTE, um den Client zu schließen.

So richten Sie das Beispiel ein, erstellen es und führen es aus

Zum Erstellen der C#- oder Visual Basic .NET-Edition der Lösung befolgen Sie die unter Durchführen der Windows Communication Foundation-Beispiele aufgeführten Anweisungen.
Stellen Sie sicher, dass Sie die ASP.NET-Datenbank für die Anwendungsdienste (möglicherweise nur in englischer Sprache) konfiguriert haben.

Tipp

Wenn Sie SqlExpress ausführen, lautet der Servername .\SQLEXPRESS. Dieser Server sollte zum Konfigurieren der ASP.NET-Datenbank für die Anwendungsdienste sowie in der Web.config-Verbindungszeichenfolge verwendet werden.

Tipp

Das ASP.NET-Workerprozesskonto muss über Berechtigungen für die in diesem Schritt erstellte Datenbank verfügen. Verwenden Sie hierzu das sqlcmd-Dienstprogramm oder SQL Server Management Studio.
Wenn Sie das Beispiel in einer Konfiguration mit einem einzigen Computer oder computerübergreifend ausführen möchten, befolgen Sie die folgenden Anweisungen.

So führen Sie das Beispiel auf demselben Computer aus

Stellen Sie sicher, dass der Pfad den Ordner enthält, indem sich Makecert.exe befindet.
Führen Sie Setup.bat im dem Beispielinstallationsordner aus. So werden die Dienstzertifikate installiert, die zum Ausführen des Beispiels erforderlich sind.
Starten Sie Client.exe im Ordner \client\bin. In der Clientkonsolenanwendung wird Clientaktivität angezeigt.
Falls der Client und der Dienst nicht miteinander kommunizieren können, finden Sie weitere Informationen unter Hinweise zur Fehlerbehebung.

So führen Sie das Beispiel computerübergreifend aus

Erstellen Sie auf dem Dienstcomputer ein Verzeichnis. Erstellen Sie mithilfe des Verwaltungstools für Internetinformationsdienste (IIS) für dieses Verzeichnis eine virtuelle Anwendung namens "servicemodelsamples".
Kopieren Sie die Dienstprogrammdateien aus \inetpub\wwwroot\servicemodelsamples in das virtuelle Verzeichnis auf dem Dienstcomputer. Stellen Sie sicher, dass Sie die Dateien in das \bin-Unterverzeichnis kopieren. Kopieren Sie außerdem die Dateien "Setup.bat", "GetComputerName.vbs" und "Cleanup.bat" auf den Dienstcomputer.
Erstellen Sie auf dem Clientcomputer ein Verzeichnis für die Clientbinärdateien.
Kopieren Sie die Clientprogrammdateien in das Clientverzeichnis auf dem Clientcomputer. Kopieren Sie außerdem die Dateien "Setup.bat", "Cleanup.bat" und "ImportServiceCert.bat" auf den Client.
Führen Sie auf dem Server setup.bat service aus. Durch Ausführen von setup.bat mit dem Argument service wird ein Dienstzertifikat mit dem vollqualifizierten Domänennamen des Computers erstellt und das Dienstzertifikat in eine Datei namens "Service.cer" exportiert.
Bearbeiten Sie Web.config so, dass die Datei den neuen Zertifikatnamen (im findValue-Attribut in serviceCertificate element of serviceCredentials) enthält, der dem vollqualifizierten Domänennamen des Computers entspricht**.**
Kopieren Sie die Datei "Service.cer" aus dem Dienstverzeichnis in das Clientverzeichnis auf dem Clientcomputer.
Ändern Sie in der Datei "Client.exe.config" auf dem Clientcomputer den Wert für die Adresse des Endpunkts so, dass er mit der neuen Adresse Ihres Diensts übereinstimmt.
Führen Sie auf dem Client "ImportServiceCert.bat" aus. Dadurch wird das Dienstzertifikat aus der Datei "Service.cer" in den CurrentUser – TrustedPeople-Speicher importiert.
Starten Sie auf dem Clientcomputer die Datei "Client.exe" über eine Eingabeaufforderung. Falls der Client und der Dienst nicht miteinander kommunizieren können, finden Sie weitere Informationen unter Hinweise zur Fehlerbehebung.

So bereinigen Sie nach dem Beispiel

Führen Sie Cleanup.bat im Beispielordner aus, nachdem Sie das Beispiel fertig ausgeführt haben.

Tipp

Wenn dieses Beispiel computerübergreifend ausgeführt wird, entfernt dieses Skript keine Dienstzertifikate auf einem Client. Wenn Sie Windows Communication Foundation (WCF)-Beispiele ausgeführt haben, die Zertifikate computerübergreifend verwenden, müssen Sie sicherstellen, dass Sie die Dienstzertifikate entfernen, die im CurrentUser-TrustedPeople-Speicher installiert wurden. Verwenden Sie dazu den folgenden Befehl: certmgr -del -r CurrentUser -s TrustedPeople -c -n <Fully Qualified Server Machine Name> Beispiel: certmgr -del -r CurrentUser -s TrustedPeople -c -n server1.contoso.com.

Die Setupbatchdatei

Mit der in diesem Beispiel enthaltenen Setup.bat-Batchdatei können Sie den Server mit relevanten Zertifikaten zum Ausführen einer selbst gehosteten Anwendung konfigurieren, die serverzertifikatbasierte Sicherheit erfordert. Diese Batchdatei muss so geändert werden, dass sie computerübergreifend oder in einem nicht gehosteten Fall funktioniert.

Nachfolgend erhalten Sie einen kurzen Überblick über die verschiedenen Abschnitte der Batchdateien, damit Sie sie so bearbeiten können, dass sie in der entsprechenden Konfiguration ausgeführt werden.

Erstellen des Serverzertifikats.
Mit den folgenden Zeilen aus der Setup.bat-Batchdatei wird das zu verwendende Serverzertifikat erstellt. Die Variable %SERVER_NAME% gibt den Servernamen an. Ändern Sie diese Variable, und geben Sie Ihren eigenen Servernamen an. Standardmäßig lautet sie in dieser Batchdatei "localhost".
Das Zertifikat wird im persönlichen Speicher unter dem Speicherort "LocalMachine" gespeichert.
```
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
```
Installieren des Serverzertifikats im Clientspeicher für vertrauenswürdige Zertifikate
Mit den folgenden Zeilen in der Setup.bat-Batchdatei wird das Serverzertifikat in den Clientspeicher für vertrauenswürdige Personen kopiert. Dieser Schritt ist erforderlich, da von Makecert.exe generierten Zertifikaten nicht implizit vom Clientsystem vertraut wird. Wenn Sie bereits über ein Zertifikat verfügen, dass von einem vertrauenswürdiges Clientstammzertifikat stammt (z. B. ein von Microsoft ausgegebenes Zertifikat), ist dieser Schritt zum Füllen des Clientzertifikatspeichers mit dem Serverzertifikat nicht erforderlich.
```
certmgr.exe -add -r LocalMachine -s My -c -n %SERVER_NAME% -r CurrentUser -s TrustedPeople
```

Freigeben über