Teilen über

Sicherheitsverhalten in WCF

  • Artikel

In Windows Communication Foundation (WCF) modifizieren Verhaltensweisen das Laufzeitverhalten auf Dienstebene oder auf Endpunktebene. (Weitere Informationen zu Verhaltensweisen im Allgemeinen finden Sie unter Angeben des Dienst-Run-Time-Verhaltens.) Sicherheitsverhalten ermöglicht die Kontrolle über Anmeldeinformationen, Authentifizierungs-, Autorisierungs- und Überwachungsprotokolle. Sie können Verhalten entweder mittels Programmierung oder mittels Konfiguration verwenden.

In diesem Artikel wird die Konfiguration der folgenden, auf Sicherheitsfunktionen bezogenen Verhalten erläutert:

Festlegen von Anmeldeinformationen mit Verhaltensweisen

Verwenden Sie serviceCredentials<> und <clientCredentials>, um Anmeldeinformationen für einen Dienst oder Client festzulegen. Durch die zugrunde liegende Bindungskonfiguration wird vorgegeben, ob Anmeldeinformationen festgelegt werden müssen. Wenn beispielsweise für den Sicherheitsmodus der Wert None gewählt wurde, findet keine gegenseitige Authentifizierung von Clients und Diensten statt. Es sind daher keine Anmeldeinformationen erforderlich.

Andererseits kann es sein, dass die Dienstbindung eine Art von Clientanmeldeinformation erfordert. In diesem Fall müssen Sie eventuell mithilfe eines Verhaltens einen Wert für die Anmeldeinformationen festlegen. (Weitere Informationen zu den möglichen Arten von Berechtigungsnachweisen finden Sie unter Auswählen eines Berechtigungstyps.) In einigen Fällen, z. B. wenn Windows-Anmeldeinformationen zur Authentifizierung benutzt werden, stellt die Umgebung automatisch den tatsächlichen Anmeldeinformationswert fest und Sie müssen den Anmeldeinformationswert nicht explizit festlegen (es sei denn, Sie möchten einen anderen Satz von Anmeldeinformationen angeben).

Alle Dienstnachweise befinden sich als untergeordnete Elemente der <serviceBehaviors>. Im folgenden Beispiel wird ein Zertifikat als Dienstanmeldeinformation verwendet:

<configuration>
 <system.serviceModel>
  <behaviors>
   <serviceBehaviors>
    <behavior name="ServiceBehavior1">
     <serviceCredentials>
      <serviceCertificate findValue="000000000000000000000000000"
                          storeLocation="CurrentUser"
      storeName="Root" x509FindType="FindByThumbprint" />
     </serviceCredentials>
    </behavior>
   </serviceBehaviors>
  </behaviors>
 </system.serviceModel>
</configuration>

Dienstanmeldeinformationen

<serviceCredentials> enthält vier untergeordnete Elemente. Diese Elemente und ihre Verwendung werden in den folgenden Abschnitten vorgestellt.

<serviceCertificate>-Element

Geben Sie mit diesem Element ein X.509-Zertifikat an, mit dem der Dienst bei den Clients im Modus für die Nachrichtensicherheit authentifiziert wird. Falls Sie ein Zertifikat verwenden, das immer wieder erneuert wird, ändert sich sein Fingerabdruck. Verwenden Sie in diesem Fall den Antragstellernamen als X509FindType, da das Zertifikat erneut mit demselben Antragstellernamen ausgestellt werden kann.

Weitere Informationen zur Verwendung des Elements finden Sie unter Gewusst wie: Angeben von Clientanmeldeinformations-Werten.

<certificate> des <clientCertificate>-Elements

Verwenden Sie das <Zertifikats>-Element, wenn dem Dienst das Zertifikat des Clients im Voraus bekannt sein muss, damit eine sichere Kommunikation mit dem Client stattfinden kann. Dies ist bei der Duplexkommunikation der Fall. Bei der üblicheren Kommunikation mit Anforderung und Antwort fügt der Client das Zertifikat in die Anforderung ein, das dann wiederum vom Dienst zum Schutz seiner Antwort an den Client verwendet wird. Bei der Duplexkommunikation gibt es keine Anforderungen und Antworten. Der Dienst kann das Zertifikat des Clients nicht aus der Kommunikation ableiten. Daher muss der Dienst bereits im Voraus über das Clientzertifikat verfügen, um seine Nachricht an den Client schützen zu können. Sie müssen das Zertifikat des Clients in einem Out-of-Band-Verfahren beziehen und das Zertifikat mit diesem Element angeben. Weitere Informationen zu Duplexdiensten finden Sie unter Gewusst wie: Erstellen eines Duplexvertrags.

<authentication> des <clientCertificate>-Elements

Mit dem <Authentifizierungs>-Element können Sie die Art der Clientauthentifizierung anpassen. Sie können als Wert für das CertificateValidationMode-Attribut None, ChainTrust, PeerOrChainTrust, PeerTrust oder Custom festlegen. Standardmäßig wird die Stufe ChainTrust verwendet, die angibt, dass jedes Zertifikat in einer Zertifizierungshierarchie zu finden sein muss, die in eine Stammzertifizierungsstelle am Anfang der Kette mündet. Dies ist der sicherste Modus. Sie können auch den Wert PeerOrChainTrust verwenden, der vorgibt, dass neben den Zertifikaten in einer Vertrauenskette auch selbst ausgestellte Zertifikate (Peervertrauen) akzeptiert werden. Sie können diesen Wert beim Entwickeln und Debuggen von Clients und Diensten verwenden, da selbst ausgestellte Zertifikate nicht von einer vertrauenswürdigen Zertifizierungsstelle bezogen werden müssen. Verwenden Sie beim Bereitstellen eines Clients jedoch den Wert ChainTrust. Sie können den Wert auch auf Custom setzen. Wenn Sie den Wert Custom verwenden, müssen Sie für das CustomCertificateValidatorType-Attribut zudem ein Assembly und einen Typ, mit dem das Zertifikat überprüft wird, festlegen. Wenn Sie Ihre eigene Überprüfung erstellen möchten, müssen Sie die abstrakte X509CertificateValidator-Klasse vererben.

<issuedTokenAuthentication>-Element

Das Szenario für ausgestellte Token weist drei Phasen auf. In der ersten Phase wird ein Client, der versucht, auf einen Dienst zuzugreifen, an einen Sicherheitstokendienst (Security Token Service, STS) verwiesen. Der STS authentifiziert den Client und stellt dann ein Token (in der Regel ein SAML-Token (SAML = Security Assertions Markup Language, XML-basierte Auszeichnungssprache für Sicherheitsbestätigungen) für den Client aus. Der Client kehrt dann mit dem Token zum Dienst zurück. Der Dienst überprüft das Token auf Daten, die ihm die Authentifizierung des Tokens und somit des Clients erlauben. Damit das Token authentifiziert werden kann, muss dem Dienst das vom Sicherheitstokendienst verwendete Zertifikat bekannt sein. Dieses <issuedTokenAuthentication>-Element ist das Repository für solche sicheren Tokendienstzertifikate. Verwenden Sie zum Hinzufügen von Zertifikaten die <knownCertificates>. Fügen Sie, wie im folgenden Beispiel gezeigt, für jedes Zertifikat ein <add> ein.

<issuedTokenAuthentication>
   <knownCertificates>
      <add findValue="www.contoso.com"
           storeLocation="LocalMachine" storeName="My"
           X509FindType="FindBySubjectName" />
    </knownCertificates>
</issuedTokenAuthentication>

Standardmäßig müssen die Zertifikate von einem Sicherheitstokendienst bezogen werden. Durch diese "bekannten" Zertifikate wird sichergestellt, dass nur berechtigte Clients auf einen Dienst zugreifen können.

Verwenden Sie die <allowedAudienceUris>-Auflistung in einer Verbundanwendung, die einen Sicherheitstokendienst (Security Token Service, STS) nutzt, der SamlSecurityToken-Sicherheitstoken ausstellt. Wenn der STS das Sicherheitstoken ausstellt, kann er den URI des Webdiensts angeben, für den das Sicherheitstoken verwendet werden soll, indem SamlAudienceRestrictionCondition dem Sicherheitstoken hinzugefügt wird. Der SamlSecurityTokenAuthenticator für den Webdienst kann so überprüfen, ob das ausgestellte Sicherheitstoken für diesen Webdienst ausgelegt ist, indem diese Überprüfung durchgeführt wird. Führen Sie hierzu die folgenden Schritte aus:

  • Legen Sie das audienceUriMode Attribut von <issuedTokenAuthentication> auf Always oder BearerKeyOnly fest.

  • Geben Sie den Satz gültiger URIs an, indem Sie die URIs dieser Auflistung hinzufügen. Fügen Sie hierzu für jeden URI ein <hinzufügen> ein

Weitere Informationen finden Sie unter SamlSecurityTokenAuthenticator.

Weitere Informationen zur Verwendung dieses Konfigurationselements finden Sie unter Gewusst wie: Konfigurieren von Anmeldeinformationen für einen Verbunddienst.

Zulassen anonymer CardSpace-Benutzer

Wenn Sie das AllowUntrustedRsaIssuers-Attribut des <IssuedTokenAuthentication>-Elements auf true setzen, dürfen alle Clients ein selbst ausgestelltes und mit einem beliebigen RSA-Schlüsselpaar signiertes Token vorweisen. Der Aussteller ist nicht vertrauenswürdig, da dem Schlüssel keine Ausstellerdaten zugeordnet sind. CardSpace-Benutzer können eine selbst ausgestellte Karte mit von ihnen selbst bereitgestellten Identitätsansprüchen erstellen. Daher sollte diese Funktion nur mit Vorsicht verwendet werden. Falls Sie diese Funktion verwenden möchten, stellen Sie sich den öffentlichen RSA-Schlüssel als sichereres Kennwort vor, das mit dem Benutzernamen in einer Datenbank gespeichert werden sollte. Überprüfen Sie den vom Client vorgelegten öffentlichen RSA-Schlüssel, indem Sie ihn mit dem für diesen Benutzernamen gespeicherten öffentlichen Schlüssel vergleichen, bevor Sie einem Client Zugriff auf den Dienst gewähren. Dies setzt voraus, dass Sie einen Registrierungsvorgang eingerichtet haben, bei dem Benutzer ihre Benutzernamen registrieren und diesen die selbst ausgestellten öffentlichen RSA-Schlüssel zuordnen können.

Clientanmeldeinformationen

Durch die Clientanmeldeinformationen wird der Client bei den Diensten authentifiziert, wenn eine gegenseitige Authentifizierung erforderlich ist. Sie können den Abschnitt zur Angabe von Dienstzertifikaten in Szenarien verwenden, bei denen der Client seine Nachrichten an einen Dienst mithilfe des Dienstzertifikats schützen muss.

Sie können einen Client auch als Teil eines Verbundszenarien konfigurieren, in dem die Token eines Sicherheitstokendiensts oder eines lokalen Tokenausstellers verwendet werden. Weitere Informationen zu Verbundszenarios finden Sie unter Partnerverbund und ausgestellten Token. Alle Clientanmeldeinformationen befinden sich wie im folgenden Code zu sehen im <endpointBehaviors>.

<behaviors>
 <endpointBehaviors>
  <behavior name="EndpointBehavior1">
   <clientCredentials>
    <clientCertificate findValue="cn=www.contoso.com"
        storeLocation="LocalMachine"
        storeName="AuthRoot" x509FindType="FindBySubjectName" />
    <serviceCertificate>
     <defaultCertificate findValue="www.cohowinery.com"
                    storeLocation="LocalMachine"
                    storeName="Root" x509FindType="FindByIssuerName" />
    <authentication revocationMode="Online"
                    trustedStoreLocation="LocalMachine" />
    </serviceCertificate>
   </clientCredentials>
  </behavior>
 </endpointBehaviors>
</behaviors>

<clientCertificate>-Element

Legen Sie mit diesem Element das Zertifikat fest, mit dem der Client authentifiziert wird. Weitere Informationen finden Sie unter Gewusst wie: Angeben von Werten für Clientanmeldeinformationen.

<httpDigest>

Diese Funktion muss mit Active Directory unter Windows und unter IIS (Internet Information Services) aktiviert werden. Weitere Informationen finden Sie unter Digestauthentifizierung in IIS 6.0.

<issuedToken>-Element

<issuedToken> umfasst die Elemente, mit denen ein lokaler Tokenaussteller konfiguriert wird, oder Verhaltensweisen, die mit einem Sicherheits-Token-Dienst verwendet werden. Anweisungen zum Konfigurieren eines Clients für die Verwendung eines lokalen Ausstellers finden Sie unter Vorgehensweise: Konfigurieren eines lokalen Ausstellers.

<localIssuerAddress>

Gibt eine Standardadresse für den Sicherheitstokendienst an. Dies wird verwendet, wenn der WSFederationHttpBinding keine URL für den Sicherheits-Token-Dienst bereitstellt oder wenn die Ausstelleradresse einer Verbundanbindung http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous oder null ist. In diesem Fall muss ClientCredentials mit der Adresse des lokalen Ausstellers und der für die Kommunikation mit diesem Aussteller zu verwendenden Bindung konfiguriert werden.

<issuerChannelBehaviors>

Verwenden Sie <issuerChannelBehaviors>, um WCF-Clientverhaltensweisen hinzuzufügen, die bei der Kommunikation mit einem Sicherheitstoken-Dienst verwendet werden. Definieren Sie das Clientverhalten im Abschnitt <endpointBehaviors> . Um ein definiertes Verhalten zu verwenden, fügen Sie ein <add>-Element mit zwei Attributen zum <issuerChannelBehaviors>-Element hinzu. Verwenden Sie für issuerAddress die URL des Sicherheitstokendiensts, und verwenden Sie für das behaviorConfiguration-Attribut den Namen des definierten Endpunktverhaltens, wie im folgenden Beispiel gezeigt:

<clientCredentials>
   <issuedToken>
      <issuerChannelBehaviors>
         <add issuerAddress="http://www.contoso.com"
               behaviorConfiguration="clientBehavior1" />
      </issuerChannelBehaviors>
   </issuedToken>
</clientCredentials>

<serviceCertificate>-Element

Verwenden Sie dieses Element, um die Authentifizierung von Dienstzertifikaten zu steuern.

Das <defaultCertificate>-Element kann ein einzelnes Zertifikat speichern, das verwendet wird, wenn der Dienst kein Zertifikat angibt.

Verwenden Sie <scopedCertificates> und <add>, um Dienstzertifikate festzulegen, die mit bestimmten Diensten verbunden sind. Das <add>-Element beinhaltet ein targetUri-Attribut, mit dem das Zertifikat dem Dienst zugeordnet wird.

Das <Authentifizierungselement> gibt den Grad des Vertrauens an, der für die Authentifizierung von Zertifikaten verwendet wird. Standardmäßig wird die Stufe "ChainTrust" verwendet, die angibt, dass jedes Zertifikat in einer Zertifizierungshierarchie zu finden sein muss, die in eine vertrauenswürdige Zertifizierungsstelle am Anfang der Kette mündet. Dies ist der sicherste Modus. Sie können auch den Wert "PeerOrChainTrust" verwenden, der vorgibt, dass neben den Zertifikaten in einer Vertrauenskette auch selbst ausgestellte Zertifikate (Peervertrauen) akzeptiert werden. Sie können diesen Wert beim Entwickeln und Debuggen von Clients und Diensten verwenden, da selbst ausgestellte Zertifikate nicht von einer vertrauenswürdigen Zertifizierungsstelle bezogen werden müssen. Verwenden Sie beim Bereitstellen eines Clients jedoch den Wert "ChainTrust". Außerdem können Sie den Wert auf „Benutzerdefiniert“ oder „Keine“ setzen. Um den Wert „Benutzerdefiniert“ zu verwenden, müssen Sie das CustomCertificateValidatorType-Attribut auch auf eine Assembly und einen Typ setzen, die zur Validierung des Zertifikats verwendet werden. Wenn Sie Ihre eigene Überprüfung erstellen möchten, müssen Sie die abstrakte X509CertificateValidator-Klasse vererben. Weitere Informationen finden Sie unter Gewusst wie: Erstellen eines Diensts, der ein benutzerdefiniertes Zertifikat-Validierungssteuerelement verwendet.

Das <Authentifizierungs>-Element beinhaltet ein RevocationMode-Attribut, das angibt, wie Zertifikate auf eine Sperre hin überprüft werden. Der Standardwert ist "online", wodurch angegeben wird, dass Zertifikate automatisch auf eine Sperre hin überprüft werden. Weitere Informationen finden Sie unter Arbeiten mit Zertifikaten.

ServiceAuthorization

Das <serviceAuthorization>-Element enthält Elemente, die sich auf die Autorisierung, benutzerspezifische Rollenanbieter und den Identitätswechsel auswirken.

Die PrincipalPermissionAttribute-Klasse wird auf eine Dienstmethode angewendet. Das Attribut gibt die Benutzergruppen an, mit denen die Verwendung einer geschützten Methode autorisiert wird. Der Standardwert lautet "UseWindowsGroups". Er gibt an, das in Windows-Gruppen wie der der Administratoren oder Benutzer nach einer Identität gesucht wird, die versucht, auf eine Ressource zuzugreifen. Außerdem können Sie „UseAspNetRoles“ angeben, um einen benutzerdefinierten Rollenanbieter zu verwenden, der unter dem <system.web>-Element konfiguriert ist, wie im folgenden Code gezeigt.

<system.web>
  <membership defaultProvider="SqlProvider"
   userIsOnlineTimeWindow="15">
     <providers>
       <clear />
       <add
          name="SqlProvider"
          type="System.Web.Security.SqlMembershipProvider"
          connectionStringName="SqlConn"
          applicationName="MembershipProvider"
          enablePasswordRetrieval="false"
          enablePasswordReset="false"
          requiresQuestionAndAnswer="false"
          requiresUniqueEmail="true"
          passwordFormat="Hashed" />
     </providers>
   </membership>
  <!-- Other configuration code not shown.-->
</system.web>

Im folgenden Code wird roleProviderName mit dem principalPermissionMode-Attribut verwendet.

<behaviors>
 <behavior name="ServiceBehaviour">
  <serviceAuthorization principalPermissionMode ="UseAspNetRoles"
                        roleProviderName ="SqlProvider" />
</behavior>
   <!-- Other configuration code not shown. -->
</behaviors>

Konfigurieren von Sicherheitsaudits

Legen Sie mit <serviceSecurityAudit> fest, in welches Protokoll geschrieben wird und welche Arten von Ereignissen protokolliert werden sollen. Für weitere Informationen siehe Überwachung

<behaviors>
 <serviceBehaviors>
  <behavior name="NewBehavior">
    <serviceSecurityAudit auditLogLocation="Application"
             suppressAuditFailure="true"
             serviceAuthorizationAuditLevel="Success"
             messageAuthenticationAuditLevel="Success" />
  </behavior>
 </serviceBehaviors>
</behaviors>

Sicherer Metadatenaustausch

Das Exportieren von Metadaten auf Clients ist hilfreich für Dienst- und Cliententwickler, da so das Herunterladen von Konfigurations- und Clientcode möglich wird. Damit der Dienst möglichst gut vor böswilligen Benutzern geschützt wird, können Sie für die Übertragung den HTTPS-Mechanismus (SSL über HTTP) verwenden. Hierfür müssen Sie zunächst ein geeignetes X.509-Zertifikat an einen bestimmten Port des Computers, auf dem der Dienst gehostet wird, binden. (Weitere Informationen finden Sie unter Arbeiten mit Zertifikaten.) Zweitens fügen Sie der Dienstkonfiguration ein <serviceMetadata> hinzu und setzen das Attribut HttpsGetEnabled auf true fest. Setzen Sie abschließend wie im folgenden Beispiel gezeigt das HttpsGetUrl-Attribut auf den URL des Dienstmetadaten-Endpunkts:

<behaviors>
 <serviceBehaviors>
  <behavior name="NewBehavior">
    <serviceMetadata httpsGetEnabled="true"
     httpsGetUrl="https://myComputerName/myEndpoint" />
  </behavior>
 </serviceBehaviors>
</behaviors>

Siehe auch