Comportamentos de segurança no WCF
No WCF (Windows Communication Foundation), os comportamentos modificam o comportamento do tempo de execução no nível do serviço ou no nível do ponto de extremidade. (Para obter mais informações sobre comportamentos em geral, consulte Especificando comportamento de tempo de execução de serviço.) Os comportamentos de segurança permitem o controle sobre credenciais, autenticação, autorização e logs de auditoria. Você pode usar comportamentos por meio da programação ou por meio da configuração.
Este artigo se concentra em configurar os seguintes comportamentos relacionados às funções de segurança:
- <serviceCredentials>
- <clientCredentials>
- <serviceAuthorization>
- <serviceSecurityAudit>
- <serviceMetadata>, que também permite especificar um ponto de extremidade seguro que os clientes possam acessar para metadados
Definir credenciais com comportamentos
Use as <serviceCredentials> e <clientCredentials> para definir valores de credenciais para um serviço ou cliente. A configuração de associação subjacente determina se uma credencial deve ser definida. Por exemplo, se o modo de segurança estiver definido como None
, clientes e serviços não se autenticam e não exigem credenciais de nenhum tipo.
Por outro lado, a associação de serviço pode exigir um tipo de credencial de cliente. Nesse caso, pode ser necessário definir um valor de credencial usando um comportamento. (Para obter mais informações sobre os possíveis tipos de credenciais, consulte Selecionar um tipo de credencial.) Em alguns casos, quando as credenciais do Windows são usadas para autenticação, o ambiente estabelece automaticamente o valor real da credencial e você não precisa definir explicitamente o valor da credencial (a menos que queira especificar um conjunto diferente de credenciais).
Todas as credenciais de serviço são encontradas como elementos filho de <serviceBehaviors>. O exemplo a seguir mostra um certificado usado como uma credencial de serviço.
<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>
Credenciais do Serviço
O <serviceCredentials> contém quatro elementos filho. Os elementos e seus usos são discutidos nas seções a seguir.
Elemento<serviceCertificate>
Use esse elemento para especificar um certificado X.509 que é usado para autenticar o serviço para clientes usando o modo de segurança de mensagem. Se você estiver usando um certificado que é renovado periodicamente, sua impressão digital é alterada. Nesse caso, use o nome da entidade como X509FindType
porque o certificado pode ser relançado com o mesmo nome da entidade.
Para obter mais informações sobre como usar o elemento, consulte Como especificar valores da credencial de cliente.
<certificado> do elemento <clientCertificate>
Use o elemento do <certificado> quando o serviço precisar ter o certificado do cliente com antecedência para se comunicar com segurança com o cliente. Isso ocorre ao usar o padrão de comunicação duplex. No padrão mais comum de solicitação-resposta, o cliente inclui seu certificado na solicitação, que o serviço usa para proteger sua resposta de volta ao cliente. No entanto, o padrão de comunicação duplex não tem solicitações e respostas. O serviço não pode inferir o certificado do cliente da comunicação e, portanto, o serviço exige o certificado do cliente com antecedência para proteger as mensagens do cliente. Você deve obter o certificado do cliente fora de banda e especificar o certificado usando esse elemento. Para obter mais informações sobre serviços duplex, consulte Como criar um contrato duplex.
<autenticação> do elemento <clientCertificate>
O elemento de <autenticação> permite que personalizar como os clientes são autenticados. Você pode definir o atributo CertificateValidationMode
como None
, ChainTrust
, PeerOrChainTrust
, PeerTrust
ou Custom
. Por padrão, o nível é definido como ChainTrust
, que especifica que cada certificado deve ser encontrado em uma hierarquia de certificados que termina em uma autoridade raiz na parte superior da cadeia. Este é o modo de maior segurança. Você também pode definir o valor como PeerOrChainTrust
, que especifica que certificados autoemitidos (confiança de par) são aceitos, bem como certificados que estão em uma cadeia confiável. Esse valor é usado ao desenvolver e depurar clientes e serviços porque os certificados autoemitidos não precisam ser adquiridos de uma autoridade confiável. Ao implantar um cliente, use o valor ChainTrust
em seu lugar. Também é possível definir o valor como Custom
. Para usar o valor Custom
, você também precisa definir o atributo CustomCertificateValidatorType
para um assembly e um tipo usados para validar o certificado. Para criar um validador personalizado, você deve herdar da classe abstrata X509CertificateValidator.
Elemento <issuedTokenAuthentication>
O cenário de token emitido tem três fases. Na primeira fase, um cliente que tenta acessar um serviço é encaminhado para um serviço de token seguro. Em seguida, o STS autentica o cliente e, posteriormente, emite um token ao cliente, normalmente um token SAML (Security Assertions Markup Language). Então, o cliente retorna ao serviço com o token. O serviço examina o token para obter dados que permitem autenticar o token e, portanto, o cliente. Para autenticar o token, o certificado que o serviço de token seguro usa deve ser conhecido pelo serviço. O elemento <issuedTokenAuthentication> é o repositório para quaisquer certificados de serviço de token seguro. Para adicionar certificados, use o <knownCertificates>. Insira um <suplemento> para cada certificado, conforme mostrado no exemplo a seguir.
<issuedTokenAuthentication>
<knownCertificates>
<add findValue="www.contoso.com"
storeLocation="LocalMachine" storeName="My"
X509FindType="FindBySubjectName" />
</knownCertificates>
</issuedTokenAuthentication>
Por padrão, os certificados devem ser obtidos de um serviço de token seguro. Esses certificados "conhecidos" garantem que somente clientes legítimos possam acessar um serviço.
Você deve usar a <coleção allowedAudienceUris> em um aplicativo federado que utiliza um STS (serviço de token de segurança) que emite SamlSecurityToken
tokens de segurança. Quando o STS emite o token de segurança, ele pode especificar o URI dos serviços Web para os quais o token de segurança se destina a adicionar um SamlAudienceRestrictionCondition
token de segurança. Isso permite que o SamlSecurityTokenAuthenticator
serviço Web do destinatário verifique se o token de segurança emitido se destina a esse serviço Web especificando que essa verificação deve ser feita da seguinte forma:
Defina o atributo
audienceUriMode
de <issuedTokenAuthentication> comoAlways
ouBearerKeyOnly
.Especifique o conjunto de URIs válidos adicionando as URIs a essa coleção. Para isso, insira um <suplemento> para cada URI
Para obter mais informações, consulte SamlSecurityTokenAuthenticator.
Para obter mais informações sobre como usar esse elemento de configuração, consulte Como configurar credenciais em um serviço de federação.
Permitir usuários anônimos do CardSpace
Definir o atributo AllowUntrustedRsaIssuers
do <IssuedTokenAuthentication>
elemento para true
permitir explicitamente que um cliente apresente um token autoemitido assinado com um par de chaves RSA arbitrário. O emissor não é confiável, porque a chave não tem dados de emissor associados. Um usuário do CardSpace pode criar um cartão autoemitido que inclui declarações de identidade fornecidas por eles próprios. Use essa funcionalidade com cautela. Para essa funcionalidade, pense na chave pública RSA como uma senha mais segura que deve ser armazenada em um banco de dados junto com o nome de usuário. Antes de permitir que um cliente acesse o serviço, verifique a chave pública RSA apresentada pelo cliente comparando-a com a chave pública armazenada para o nome de usuário apresentado. Isso pressupõe que você tenha estabelecido um processo de registro pelo qual os usuários podem registrar seus nomes de usuário e associá-los às chaves públicas RSA autoemitidas.
Credenciais do cliente
As credenciais do cliente são usadas para autenticar o cliente em serviços nos casos em que é necessária a autenticação mútua. Você pode usar a seção para especificar certificados de serviço para cenários em que o cliente deve proteger as mensagens para um serviço com o certificado de serviço.
Você também pode configurar um cliente como parte de um cenário de federação para usar tokens emitidos de um serviço de token seguro ou de um emissor local de tokens. Para obter mais informações sobre cenários federados, consulte Federação e Tokens Emitidos. Todas as credenciais do cliente são encontradas no <endpointBehaviors>, conforme mostrado no código a seguir.
<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>
Elemento <clientCertificate>
Defina o certificado usado para autenticar o cliente com esse elemento. Para obter mais informações, consulte Como especificar valores de credenciais do cliente.
<httpDigest>
Esse recurso deve ser habilitado com o Active Directory no Windows e no IIS (Serviços de Informações da Internet). Para obter mais informações, consulte Autenticação Digest no IIS 6.0.
Elemento <issuedToken>
O <issuedToken> contém os elementos usados para configurar um emissor local de tokens ou comportamentos usados com um serviço de token de segurança. Para obter instruções sobre como configurar um cliente para usar um emissor local, consulte Como configurar um emissor local.
<localIssuerAddress>
Especifica um endereço de serviço de token de segurança padrão. Isso é usado quando WSFederationHttpBinding não fornece uma URL para o serviço de token de segurança ou quando o endereço do emissor de uma associação federada é http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous
ou null
. Nesses casos, ClientCredentials deve ser configurado com o endereço do emissor local e a associação a ser usada para se comunicar com esse emissor.
<issuerChannelBehaviors>
Use <issuerChannelBehaviors> para adicionar comportamentos de cliente de WCF usados ao se comunicar com um serviço de token de segurança. Defina os comportamentos do cliente na seção <endpointBehaviors>. Para usar um comportamento definido, adicione um <add>
elemento ao elemento <issuerChannelBehaviors>
com dois atributos. Defina issuerAddress
para a URL do serviço de token de segurança e configure o atributo behaviorConfiguration
para o nome do comportamento do ponto de extremidade definido, conforme mostrado no exemplo a seguir.
<clientCredentials>
<issuedToken>
<issuerChannelBehaviors>
<add issuerAddress="http://www.contoso.com"
behaviorConfiguration="clientBehavior1" />
</issuerChannelBehaviors>
</issuedToken>
</clientCredentials>
Elemento<serviceCertificate>
Use esse elemento para controlar a autenticação de certificados de serviço.
O elemento <defaultCertificate> pode armazenar um único certificado usado quando o serviço não especifica nenhum certificado.
Use <scopedCertificates> e <adicione> para definir certificados de serviço associados a serviços específicos. O elemento <add>
inclui um atributo targetUri
usado para associar o certificado ao serviço.
O elemento <autenticação> especifica o nível de confiança usado para autenticar certificados. Por padrão, o nível é definido como “ChainTrust”, que especifica que cada certificado deve ser encontrado em uma hierarquia de certificados que termina em uma autoridade de certificação confiável na parte superior da cadeia. Esse é o modo mais seguro. Você também pode definir o valor como "PeerOrChainTrust", que especifica que certificados autoemitidos (confiança de par) são aceitos, bem como certificados que estão em uma cadeia confiável. Esse valor é usado ao desenvolver e depurar clientes e serviços porque os certificados autoemitidos não precisam ser adquiridos de uma autoridade confiável. Ao implantar um cliente, use o valor “ChainTrust” em seu lugar. Você também pode definir o valor como "Personalizado" ou "Nenhum". Para usar o valor "Personalizado", você também deve definir o atributo CustomCertificateValidatorType
como um assembly e o tipo usados para validar o certificado. Para criar um validador personalizado, você deve herdar da classe abstrata X509CertificateValidator. Para obter mais informações, consulte Como criar um serviço que utiliza um validador de certificado personalizado.
O elemento < autenticação> inclui um atributo RevocationMode
que especifica como os certificados são verificados quanto à revogação. O padrão é "online", o que indica que os certificados são verificados automaticamente quanto à revogação. Para saber mais, consulte Como trabalhar com certificados.
ServiceAuthorization
O elemento <serviceAuthorization> contém elementos que afetam a autorização, os provedores de função personalizada e a representação.
A classe PrincipalPermissionAttribute é aplicada a um método de serviço. O atributo especifica os grupos de usuários que serão usados ao autorizar o uso de um método protegido. O valor padrão é "UseWindowsGroups" e especifica que os grupos do Windows, como "Administradores" ou "Usuários" são pesquisados por uma identidade tentando acessar um recurso. Também é possível especificar "UseAspNetRoles para usar um provedor de função personalizada configurado no elemento <system.web
>, conforme mostrado no código seguinte.
<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>
O código a seguir mostra o roleProviderName
usado com o atributo principalPermissionMode
:
<behaviors>
<behavior name="ServiceBehaviour">
<serviceAuthorization principalPermissionMode ="UseAspNetRoles"
roleProviderName ="SqlProvider" />
</behavior>
<!-- Other configuration code not shown. -->
</behaviors>
Configurar auditorias de segurança
Use o <serviceSecurityAudit> para especificar o log gravado e os tipos de eventos para fazer registro. Para obter mais informações, consulte Auditoria.
<behaviors>
<serviceBehaviors>
<behavior name="NewBehavior">
<serviceSecurityAudit auditLogLocation="Application"
suppressAuditFailure="true"
serviceAuthorizationAuditLevel="Success"
messageAuthenticationAuditLevel="Success" />
</behavior>
</serviceBehaviors>
</behaviors>
Troca segura de metadados
É conveniente exportar metadados para clientes de desenvolvedores de serviço e cliente, pois permite downloads de configuração e código do cliente. Para reduzir a exposição de um serviço a usuários mal-intencionados, é possível proteger a transferência usando o mecanismo SSL por HTTP (HTTPS). Para isso, primeiro você deve associar um certificado X.509 adequado a uma porta específica no computador que está hospedando o serviço. (Para obter mais informações, consulte Como trabalhar com certificados.) Em segundo lugar, adicione um <serviceMetadata> à configuração de serviço e defina o atributo HttpsGetEnabled
como true
. Por fim, defina o atributo HttpsGetUrl
como a URL do ponto de extremidade de metadados de serviço, conforme mostrado no exemplo a seguir.
<behaviors>
<serviceBehaviors>
<behavior name="NewBehavior">
<serviceMetadata httpsGetEnabled="true"
httpsGetUrl="https://myComputerName/myEndpoint" />
</behavior>
</serviceBehaviors>
</behaviors>