Comportements de sécurité dans WCF
Dans Windows Communication Foundation (WCF), les comportements modifient le comportement d’exécution au niveau du service ou au niveau du point de terminaison. (Pour plus d’informations sur les comportements en général, consultez Spécification du comportement du runtime de service.) Les comportements de sécurité permettent de contrôler les informations d’identification, l’authentification, l’autorisation et les journaux d’audit. Vous pouvez les utiliser via la programmation ou la configuration. Cette rubrique se concentre sur la configuration des comportements relatifs aux fonctions de sécurité suivants :
<serviceMetadata>, qui vous permet également de spécifier un point de terminaison sécurisé auquel les clients peuvent accéder pour les métadonnées.
Définition d'informations d'identification avec des comportements
Utilisez <serviceCredentials> et <clientCredentials> pour définir des valeurs d’informations d’identification pour un service ou un client. La configuration de liaison sous-jacente détermine si une information d’identification doit être définie. Par exemple, si le mode de sécurité a la valeur None, les clients et les services ne s'authentifient pas l'un l'autre et ne requièrent pas d'information d'identification d'aucun type.
En revanche, la liaison de service peut requérir un type d'informations d'identification du client. Dans ce cas, il peut s'avérer nécessaire de définir une valeur d'information d'identification à l'aide d'un comportement. (Pour plus d’informations sur les types d’informations d’identification possibles, consultez Sélection d’un type d’informations d’identification.) Dans certains cas, par exemple lorsque des informations d’identification Windows sont utilisées pour l’authentification, l’environnement établit automatiquement la valeur d’informations d’identification réelle, et il n’est donc pas nécessaire de la définir explicitement (sauf si vous souhaitez spécifier un autre ensemble d’informations d’identification).
Toutes les informations d’identification du service apparaissent comme des éléments enfants de <serviceBehaviors>. L'exemple suivant présente un certificat utilisé en tant qu'information d'identification du service.
<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>
Informations d'identification du service
<serviceCredentials> contient quatre éléments enfants. Les éléments et leurs utilisations sont traités dans les sections suivantes.
Élément <serviceCertificate>
Cet élément vous permet de spécifier un certificat X.509 qui est utilisé pour authentifier le service auprès des clients à l'aide du mode de sécurité Message. Si vous utilisez un certificat qui est périodiquement renouvelé, son empreinte numérique change. Dans ce cas, utilisez le nom du sujet comme X509FindType car le certificat peut être réémis avec le même nom du sujet.
Pour plus d’informations sur l’utilisation de l’élément, consultez le Guide pratique pour spécifier des valeurs d’informations d’identification du client.
Élément <certificate> de <clientCertificate>
Utilisez l’élément <certificate> lorsque le service doit avoir le certificat du client à l’avance afin de communiquer de manière sécurisée avec le client. Cela se produit lors de l'utilisation du modèle de communication duplex. Dans le modèle demande-réponse plus classique, le client inclut son certificat dans la demande, que le service utilise pour sécuriser de nouveau sa réponse au client. Toutefois, le modèle de communication duplex n’a pas de demande et de réponse. Le service ne peut pas déduire le certificat du client de la communication, et par conséquent, il en a besoin à l'avance pour sécuriser les messages au client. Vous devez obtenir le certificat du client hors bande et l'indiquer à l'aide de cet élément. Pour plus d’informations sur les services duplex, consultez le Guide pratique pour créer un contrat duplex.
Élément <authentication> de <clientCertificate>
L’élément <authentication> vous permet de personnaliser la manière dont les clients sont authentifiés. Vous pouvez affecter CertificateValidationMode, None, ChainTrust, PeerOrChainTrust ou PeerTrust à l'attribut Custom. Par défaut, le niveau a la valeur ChainTrust, laquelle spécifie que chaque certificat doit se trouver dans une hiérarchie de certificats se terminant dans une autorité racine au sommet de la chaîne. C’est le mode le plus sécurisé. Vous pouvez également affecter la valeur PeerOrChainTrust, laquelle spécifie que les certificats auto-émis (approbation homologue) sont acceptés, de même que les certificats qui se trouvent dans une chaîne approuvée. Cette valeur est utilisée lors du développement et du débogage des clients et des services car il n'est pas nécessaire d'acheter les certificats auto-émis auprès d'une autorité approuvée. Lorsque vous déployez un client, utilisez à la place la valeur ChainTrust. Vous pouvez également utiliser Custom. Lorsque vous utilisez Custom, vous devez également affecter l'assembly et le type utilisés pour valider le certificat à l'attribut CustomCertificateValidatorType. Pour créer votre propre validateur personnalisé, vous devez hériter de la classe X509CertificateValidator abstraite.
Élément <issuedTokenAuthentication>
Le scénario de jeton émis comporte trois étapes. Au cours de la première étape, un client qui essaie d’accéder à un service est désigné par le terme de service de jeton sécurisé (STS). Le STS authentifie le client et émet ensuite un jeton pour ce dernier, généralement un jeton SAML (Security Assertions Markup Language). Le client retourne ensuite au service avec le jeton. Le service recherche dans le jeton les données lui permettant de l'authentifier, et par conséquent d'authentifier le client. Pour authentifier le jeton, le service doit connaître le certificat utilisé par le service d'émission de jeton sécurisé. L’élément <issuedTokenAuthentication> est le référentiel pour les certificats de service d’émission de jeton sécurisé de ce type. Pour ajouter des certificats, utilisez les <knownCertificates>. Insérez <add> pour chaque certificat, tel qu’indiqué dans l’exemple suivant.
<issuedTokenAuthentication>
<knownCertificates>
<add findValue="www.contoso.com"
storeLocation="LocalMachine" storeName="My"
X509FindType="FindBySubjectName" />
</knownCertificates>
</issuedTokenAuthentication>
Par défaut, les certificats doivent être obtenus auprès d'un service d'émission de jeton sécurisé. Ces certificats « connus » garantissent que seuls les clients légitimes peuvent accéder à un service.
Vous devez utiliser la collection <allowedAudienceUris> dans une application fédérée qui utilise un service de jeton de sécurité (STS) qui émet des jetons de sécurité SamlSecurityToken. Lorsque le STS émet le jeton de sécurité, il peut spécifier l'URI des services Web pour lesquels le jeton de sécurité est prévu en ajoutant un SamlAudienceRestrictionCondition au jeton de sécurité. Cela permet au SamlSecurityTokenAuthenticator du service Web destinataire de vérifier que le jeton de sécurité émis est prévu pour ce service Web en spécifiant que ce contrôle doit arriver en effectuant les opérations suivantes :
Définissez l’attribut
audienceUriModede <issuedTokenAuthentication> surAlwaysouBearerKeyOnly.Spécifiez le jeu d'URI valides en ajoutant les URI à cette collection. Pour cela, insérez un <add> pour chaque URI
Pour plus d’informations, consultez SamlSecurityTokenAuthenticator.
Pour plus d’informations sur l’utilisation de cet élément de configuration, consultez Guide pratique pour configurer des informations d’identification sur un service FS (Federation Service).
Autorisation d'accès aux utilisateurs CardSpace anonymes
L'affectation de AllowUntrustedRsaIssuers à l'attribut <IssuedTokenAuthentication> de l'élément true permet aux clients de présenter un jeton auto-émis signé avec une paire de clés RSA arbitraire. L’émetteur est non approuvé car la clé n’est pas associée à des données d’émetteur. Un utilisateur CardSpace peut créer une carte auto-émise incluant des revendications d’identité auto-fournies. Utilisez cette fonction avec précaution. Pour utiliser cette fonctionnalité, considérez la clé publique RSA comme un mot de passe plus sécurisé qui doit être stocké dans une base de données avec un nom d’utilisateur. Avant d'autoriser l'accès d'un client au service, vérifiez la clé publique RSA présentée par celui-ci en le comparant avec celle stockée pour le nom d'utilisateur présenté. Cela suppose que vous ayez établi un processus d'inscription permettant aux utilisateurs d'enregistrer leurs noms d'utilisateur et de les associer avec les clés publiques RSA auto-émises.
Informations d’identification du client
Les informations d'identification du client permettent d'authentifier le client auprès des services dans les cas où l'authentification mutuelle est requise. Vous pouvez utiliser la section pour spécifier des certificats de service pour les scénarios dans lesquels le client doit sécuriser des messages auprès d'un service à l'aide du certificat de ce dernier.
Vous pouvez également configurer un client dans le cadre d'un scénario de fédération afin d'utiliser des jetons émis par un service d'émission de jeton sécurisé ou un émetteur local de jetons. Pour plus d’informations sur les scénarios fédérés, consultez Fédération et jetons émis. Toutes les informations d’identification du client se trouvent sous <endpointBehaviors>, tel qu’indiqué dans le code suivant.
<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>
Élément <clientCertificate>
Définissez le certificat utilisé pour authentifier le client avec cet élément. Pour plus d’informations, consultez Guide pratique pour spécifier des valeurs d’informations d’identification du client.
<httpDigest>
Cette fonction doit être activée avec Active Directory sur Windows et les services IIS (Internet Information Services). Pour plus d’informations, consultez Authentification Digest dans IIS 6.0.
Élément <issuedToken>
Le <issuedToken> contient les éléments permettant de configurer un émetteur local de jetons ou les comportements utilisés avec un service d’émission de jeton de sécurité. Pour obtenir des instructions sur la configuration d’un client pour utiliser un émetteur local, consultez Guide pratique pour configurer un émetteur local.
<localIssuerAddress>
Spécifie une adresse de service d'émission de jeton de sécurité par défaut. Cela est utilisé lorsque le WSFederationHttpBinding ne fournit pas d’URL pour le service de jeton de sécurité, ou lorsque l’adresse de l’émetteur d’une liaison fédérée est http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous ou null. Dans ce cas, vous devez configurer ClientCredentials avec l’adresse de l’émetteur local et la liaison à utiliser pour communiquer avec celui-ci.
<issuerChannelBehaviors>
Utilisez les <issuerChannelBehaviors> pour ajouter des comportements de client WCF utilisés lors de la communication avec un service de jeton de sécurité. Définissez les comportements des clients dans la section <endpointBehaviors>. Pour utiliser un comportement défini, ajoutez un élément <add> à l’élément <issuerChannelBehaviors> avec deux attributs. Affectez l'URL du service d'émission de jeton de sécurité à issuerAddress, et affectez le nom du comportement de point de terminaison défini à l'attribut behaviorConfiguration, tel qu'indiqué dans l'exemple suivant.
<clientCredentials>
<issuedToken>
<issuerChannelBehaviors>
<add issuerAddress="http://www.contoso.com"
behaviorConfiguration="clientBehavior1" />
</issuerChannelBehaviors>
</issuedToken>
</clientCredentials>
Élément <serviceCertificate>
Cet élément vous permet de contrôler l'authentification des certificats de service.
L’élément <defaultCertificate> peut stocker un certificat unique utilisé lorsque le service ne spécifie aucun certificat.
Utilisez <scopedCertificates> et <add> pour définir des certificats de service associés à des services spécifiques. L'élément <add> inclut un attribut targetUri permettant d'associer le certificat au service.
L’élément <authentication> spécifie le niveau de confiance utilisé pour authentifier les certificats. Par défaut, le niveau a la valeur « ChainTrust », laquelle spécifie que chaque certificat doit se trouver dans une hiérarchie de certificats se terminant dans une autorité de certification approuvée au sommet de la chaîne. C’est le mode le plus sécurisé. Vous pouvez également affecter la valeur « PeerOrChainTrust », laquelle spécifie que les certificats auto-émis (approbation homologue) sont acceptés, de même que les certificats qui se trouvent dans une chaîne approuvée. Cette valeur est utilisée lors du développement et du débogage des clients et des services car il n'est pas nécessaire d'acheter les certificats auto-émis auprès d'une autorité approuvée. Lorsque vous déployez un client, utilisez à la place la valeur "ChainTrust". Vous pouvez également affecter Custom ou None. Pour utiliser la valeur Custom, vous devez également définir l’attribut CustomCertificateValidatorType à un assembly et à un type utilisés pour valider le certificat. Pour créer votre propre validateur personnalisé, vous devez hériter de la classe X509CertificateValidator abstraite. Pour plus d’informations, consultez Comment : créer un service qui utilise un validateur de certificat personnalisé.
L’élément <authentication> inclut un attribut RevocationMode qui spécifie la manière dont les certificats sont vérifiés pour révocation. La valeur par défaut est « online », laquelle indique que les certificats sont automatiquement vérifiés pour révocation. Pour plus d’informations, consultez Utilisation des certificats.
ServiceAuthorization
L’élément <serviceAuthorization> contient des éléments qui affectent l’autorisation, les fournisseurs de rôles personnalisés et l’emprunt d’identité.
La classe PrincipalPermissionAttribute est appliquée à une méthode de service. L'attribut spécifie les groupes d'utilisateurs à utiliser lors de l'autorisation d'utilisation d'une méthode protégée. La valeur par défaut est "UseWindowsGroups", laquelle spécifie qu'une identité essayant d'accéder à une ressource est recherchée dans les groupes Windows, tels que "Administrators" ou "Users". Vous pouvez également spécifier « UseAspNetRoles » pour utiliser un fournisseur de rôles personnalisé configuré sous l’élément <system.web>, tel qu’indiqué dans le code suivant.
<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>
Le code suivant présente le roleProviderName utilisé avec l'attribut principalPermissionMode.
<behaviors>
<behavior name="ServiceBehaviour">
<serviceAuthorization principalPermissionMode ="UseAspNetRoles"
roleProviderName ="SqlProvider" />
</behavior>
<!-- Other configuration code not shown. -->
</behaviors>
Configuration des audits de sécurité
Utilisez <serviceSecurityAudit> pour spécifier le journal à utiliser et les types des événements à enregistrer. Pour plus d’informations, consultez également Audit.
<behaviors>
<serviceBehaviors>
<behavior name="NewBehavior">
<serviceSecurityAudit auditLogLocation="Application"
suppressAuditFailure="true"
serviceAuthorizationAuditLevel="Success"
messageAuthenticationAuditLevel="Success" />
</behavior>
</serviceBehaviors>
</behaviors>
Échange de métadonnées sécurisé
L'exportation des métadonnées vers des clients s'avère pratique pour les développeurs de service et de client car elle permet des téléchargements de la configuration et du code client. Pour éviter l'exposition d'un service aux utilisateurs malveillants, il est possible de sécuriser le transfert à l'aide du mécanisme HTTPS (SSL over HTTP). Pour ce faire, vous devez d'abord lier un certificat X.509 approprié à un port spécifique sur l'ordinateur qui héberge le service. (Pour plus d’informations, consultez Utilisation des certificats.) Ensuite, ajoutez <serviceMetadata> à la configuration du service et définissez l’attribut HttpsGetEnabled sur true. Enfin, affectez l'URL du point de terminaison des métadonnées du service à l'attribut HttpsGetUrl, comme indiqué dans l'exemple suivant.
<behaviors>
<serviceBehaviors>
<behavior name="NewBehavior">
<serviceMetadata httpsGetEnabled="true"
httpsGetUrl="https://myComputerName/myEndpoint" />
</behavior>
</serviceBehaviors>
</behaviors>