Sicherheitsverhalten in WCF
In Windows Communication Foundation (WCF) beeinflussen Verhalten das Laufzeitverhalten auf Dienstebene bzw. auf Endpunktebene. (Weitere Informationen über zu Verhaltensweisen im Allgemeinen finden Sie unter Angeben des Dienstlaufzeitverhaltens.) Sicherheitsverhalten geben Ihnen die Kontrolle über Anmeldeinformationen, Authentifizierung und Autorisierung und über Überwachungsprotokolle. Sie können Verhalten entweder mittels Programmierung oder mittels Konfiguration verwenden. In diesem Thema wird die Konfiguration der folgenden, auf Sicherheitsfunktionen bezogenen Verhalten erläutert:
<serviceMetadata> Element: Bei diesem Element haben Sie zudem die Möglichkeit, einen sicheren Endpunkt festzulegen, der Clients Zugriff auf Metadaten bietet.
Festlegen von Anmeldeinformationen mithilfe von Verhalten
Legen Sie die Anmeldeinformationswerte für einen Dienst oder Client über das serviceCredentials element und das clientCredentials element fest. 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 über zu den möglichen Arten von Anmeldeinformationen finden Sie unter Wählen eines Typs von Anmeldeinformationen.) Gelegentlich wird der tatsächliche Anmeldeinformationswert automatisch durch die Umgebung festgesetzt, zum Beispiel bei Verwendung von Windows-Anmeldeinformationen für die Authentifizierung. In diesem Fall müssen Sie den Wert für die Anmeldeinformationen nicht explizit festlegen, außer Sie möchten andere Anmeldeinformationen verwenden.
Alle Dienstanmeldeinformationen sind untergeordnete Elemente und im serviceBehaviors section zu finden. 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
Das <serviceCredentials> Element verfügt über 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 über zur Verwendung des Elements finden Sie unter Gewusst wie: Angeben der Clientanmeldeinformationswerte.
<certificate>-Element des <clientCertificate>-Elements
Verwenden Sie das <certificate>-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 als Out-of-Band-Zertifikat beziehen und das Zertifikat mit diesem Element angeben. Weitere Informationen über zu Duplexdiensten finden Sie unter Vorgehensweise: Erstellen eines Duplexvertrags.
<authentication>-Element des <clientCertificate>-Elements
Mit dem <authentication>-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 Validierung 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. Das <issuedTokenAuthentication>-Element ist das Repository für die Zertifikate des Sicherheitstokendiensts. Verwenden Sie zum Hinzufügen von Zertifikaten das <knownCertificates>. Fügen Sie wie im folgenden Beispiel gezeigt ein <add> of <knownCertificates> für jedes Zertifikat 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 für <issuedTokenAuthentication> auf Always oder auf 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 <add> element <AllowedAudienceUris> Element ein.
Weitere Informationen finden Sie unter SamlSecurityTokenAuthenticator.
Weitere Informationen über zur Verwendung dieses Konfigurationselements finden Sie unter Vorgehensweise: Konfigurieren von Anmeldeinformationen auf einem 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 über zu Verbundszenarien finden Sie unter Verbund und ausgestellte Token. Alle Clientanmeldeinformationen befinden sich wie im folgenden Code zu sehen im endpointBehaviors section.
<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>
<clientCertifictate>-Element
Legen Sie mit diesem Element das Zertifikat fest, mit dem der Client authentifiziert wird. Weitere Informationen finden Sie unter Gewusst wie: Angeben der Clientanmeldeinformationswerte.
<httpDigest>
Für diese Funktion müssen Active Directory unter Windows und die Internetinformationsdienste (IIS) aktiviert sein. Weitere Informationen finden Sie unter Digestauthentifizierung in IIS 6.0 (möglicherweise in englischer Sprache).
<issuedToken>-Element
Das <issuedToken> of <clientCredentials> element enthält die Elemente, die zum Konfigurieren eines lokalen Tokenausstellers verwendet werden, bzw. die mit einem Sicherheitstokendienst verwendeten Verhalten. Anweisungen, wie Sie einen Client für die Verwendung eines lokalen Ausstellers konfigurieren können, finden Sie unter Vorgehensweise: Konfigurieren eines lokalen Ausstellers.
<localIssuerAddress>
Gibt eine Standardadresse für den Sicherheitstokendienst an. Diese Adresse wird verwendet, wenn die WSFederationHttpBinding keine URL für den Sicherheitstokendienst bereitstellt oder wenn die Ausstelleradresse einer Verbundbindung https://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous bzw. NULL lautet. 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>
Fügen Sie mit dem <issuerChannelBehaviors> Element WCF-Clientverhalten hinzu, die bei der Kommunikation mit einem Sicherheitstokendienst verwendet werden. Definieren Sie Clientverhalten im endpointBehaviors-Abschnitt. Fügen Sie dem <issuerChannelBehaviors>-Element ein <add>-Element mit zwei Attributen hinzu, um ein definiertes Verhalten zu verwenden. 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="https://www.contoso.com"
behaviorConfiguration="clientBehavior1" />
<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 das <scopedCertificates> Element-Element und das <add> of <scopedCertificates> Element, um Dienstzertifikate festzulegen, die bestimmten Diensten zugeordnet sind. Das <add>-Element beinhaltet ein targetUri-Attribut, mit dem das Zertifikat dem Dienst zugeordnet wird.
Mit dem <authentication>-Element wird die Ebene der Vertrauenswürdigkeit angegeben, mit der Zertifikate authentifiziert werden. 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". Sie können auch den Wert "Custom" bzw. "None" verwenden. Wenn Sie "Custom" verwenden möchten, 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. Weitere Informationen finden Sie unter Vorgehensweise: Erstellen eines Dienstes, der ein benutzerdefiniertes Zertifikats-Validierungssteuerelement verwendet.
Das <authentication>-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 Verwenden von 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. Sie können auch "UseAspNetRoles" angeben, damit ein benutzerspezifischer, unter dem <system.web >-Element konfigurierter Rollenanbieter verwendet wird, wie im folgenden Code zu sehen ist.
<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 der Sicherheitsüberwachung
Legen Sie mit dem serviceSecurityAudit element fest, in welches Protokoll geschrieben wird und welche Arten von Ereignissen protokolliert werden sollen. Weitere Informationen finden Sie unter Überwachen von Sicherheitsereignissen.
<system.serviceModel>
<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 Verwenden von Zertifikaten.) Fügen Sie dann der Dienstkonfiguration ein <serviceMetadata> Element hinzu, und legen Sie für das HttpsGetEnabled-Attribut den Wert true fest. Legen Sie abschließend, wie im folgenden Beispiel veranschaulicht, das HttpsGetUrl-Attribut auf die URL des Dienstmetadatenendpunkts fest.
<behaviors>
<serviceBehaviors>
<behavior name="NewBehavior">
<serviceMetadata httpsGetEnabled="true"
httpsGetUrl="https://myComputerName/myEndpoint" />
</behavior>
</serviceBehaviors>
</behaviors>
Siehe auch
Konzepte
Überwachen von Sicherheitsereignissen