Comportamentos de segurança no WCF
No Windows Communication Foundation (WCF), os comportamentos modificam o comportamento em tempo de execução no nível de serviço ou no nível de ponto de extremidade. (Para obter mais informações sobre comportamentos em geral, consulte Especificando o comportamento de tempo de execução do 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 programação ou por meio de configuração. Este tópico se concentra na configuração dos seguintes comportamentos relacionados às funções de segurança:
<serviceMetadata>, que também permite especificar um ponto de extremidade seguro que os clientes podem acessar para metadados.
Definindo credenciais com comportamentos
Use serviceCredentials ><e< clientCredentials> para definir valores de credenciais para um serviço ou cliente. A configuração de vinculaçã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, talvez seja necessário definir um valor de credencial usando um comportamento. (Para obter mais informações sobre os possíveis tipos de credenciais, consulte Selecionando um tipo de credencial.) Em alguns casos, como quando as credenciais do Windows são usadas para autenticar, 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 do 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 de 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 este 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 o X509FindType porque o certificado pode ser reemitido com o mesmo nome de entidade.
Para obter mais informações sobre como usar o elemento , consulte Como especificar valores de credenciais de cliente.
<certificado> do <elemento clientCertificate>
Use o <elemento de certificado> quando o serviço deve 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 de solicitação-resposta mais típico, o cliente inclui seu certificado na solicitação, que o serviço usa para proteger sua resposta de volta ao cliente. O padrão de comunicação duplex, no entanto, não tem solicitações e respostas. O serviço não pode inferir o certificado do cliente a partir da comunicação e, portanto, o serviço requer o certificado do cliente com antecedência para proteger as mensagens para o cliente. Você deve obter o certificado do cliente de forma 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 personalizar como os clientes são autenticados. Você pode definir o CertificateValidationMode atributo como None, ChainTrust, , PeerTrustPeerOrChainTrust, 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 mais seguro. Você também pode definir o valor como PeerOrChainTrust, que especifica que os certificados autoemitidos (confiança de mesmo nível) são aceitos, bem como os 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 comprados de uma autoridade confiável. Ao implantar um cliente, use o ChainTrust valor em vez disso. Você também pode definir o valor como Custom. Quando definido como o Custom valor, você também deve definir o CustomCertificateValidatorType atributo para um assembly e tipo usado para validar o certificado. Para criar seu próprio validador personalizado, você deve herdar da classe abstrata X509CertificateValidator .
<Elemento issuedTokenAuthentication>
O cenário de token emitido tem três estágios. Na primeira etapa, um cliente que tenta acessar um serviço é encaminhado para um serviço de token seguro (STS). Em seguida, o STS autentica o cliente e, subsequentemente, emite um token para o cliente, normalmente um token SAML (Security Assertions Markup Language). Em seguida, o cliente retorna ao serviço com o token. O serviço examina o token em busca de dados que permitam ao serviço 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 os knownCertificates>.< Insira uma <adição> 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 apenas 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 seguro) 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, adicionando um SamlAudienceRestrictionCondition ao 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 acontecer fazendo o seguinte:
Defina o
audienceUriModeatributo de <issuedTokenAuthentication> comoAlwaysouBearerKeyOnly.Especifique o conjunto de URIs válidos, adicionando os URIs a esta coleção. Para fazer isso, insira uma <adição> para cada URI
Para obter mais informações, veja 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.
Permitindo usuários anônimos do CardSpace
Definir o AllowUntrustedRsaIssuers<IssuedTokenAuthentication> atributo do elemento como true explicitamente permite que qualquer cliente apresente um token auto-emitido assinado com um par de chaves RSA arbitrário. O emissor não é confiável porque a chave não tem dados do emissor associados a ela. Um usuário do CardSpace pode criar um cartão auto-emitido que inclui declarações de identidade auto-fornecidas. Use esse recurso com cuidado. Para usar esse recurso, pense na chave pública RSA como uma senha mais segura que deve ser armazenada em um banco de dados junto com um 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ê estabeleceu 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 nos serviços nos casos em que a autenticação mútua é necessária. Você pode usar a seção para especificar certificados de serviço para cenários em que o cliente deve proteger mensagens para um serviço com o certificado do 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 de cliente.
<httpResumo>
Esse recurso deve ser habilitado com o Ative Directory no Windows e o 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 o 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, o ClientCredentials deve ser configurado com o endereço do emissor local e a vinculação a ser usada para se comunicar com esse emissor.
<emissorChannelBehaviors>
Use o <issuerChannelBehaviors> para adicionar comportamentos de cliente WCF usados ao se comunicar com um serviço de token de segurança. Defina comportamentos de cliente na seção endpointBehaviors>.< Para usar um comportamento definido, adicione um <add> elemento ao <issuerChannelBehaviors> elemento com dois atributos. Defina a issuerAddress URL do serviço de token de segurança e defina o behaviorConfiguration atributo como o nome do comportamento de 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 este 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 <add> elemento inclui um targetUri atributo que é usado para associar o certificado ao serviço.
O <elemento authentication> 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. Este é o modo mais seguro. Você também pode definir o valor como "PeerOrChainTrust", que especifica que certificados autoemitidos (peer trust) 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 comprados de uma autoridade confiável. Ao implantar um cliente, use o valor "ChainTrust". Você também pode definir o valor como "Personalizado" ou "Nenhum". Para usar o valor "Personalizado", você também deve definir o atributo como um assembly e tipo CustomCertificateValidatorType usado para validar o certificado. Para criar seu próprio validador personalizado, você deve herdar da classe abstrata X509CertificateValidator . Para obter mais informações, consulte Como criar um serviço que emprega um validador de certificado personalizado.
O <elemento authentication> inclui um RevocationMode atributo que especifica como os certificados são verificados quanto à revogação. O padrão é "online", o que indica que os certificados são automaticamente verificados para revogação. Para obter mais informações, consulte Trabalhando com certificados.
Autorização de Serviço
O <elemento serviceAuthorization> contém elementos que afetam a autorização, os provedores de função personalizados e a representação.
A PrincipalPermissionAttribute classe é aplicada a um método de serviço. O atributo especifica os grupos de usuários a serem 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. Você também pode especificar "UseAspNetRoles" para usar um provedor de função personalizado configurado sob o <system.web> elemento , conforme mostrado no código a seguir.
<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 principalPermissionMode atributo.
<behaviors>
<behavior name="ServiceBehaviour">
<serviceAuthorization principalPermissionMode ="UseAspNetRoles"
roleProviderName ="SqlProvider" />
</behavior>
<!-- Other configuration code not shown. -->
</behaviors>
Configurando auditorias de segurança
Use o <serviceSecurityAudit> para especificar o log gravado e quais tipos de eventos devem ser registrados. Para obter mais informações, consulte Auditoria.
<behaviors>
<serviceBehaviors>
<behavior name="NewBehavior">
<serviceSecurityAudit auditLogLocation="Application"
suppressAuditFailure="true"
serviceAuthorizationAuditLevel="Success"
messageAuthenticationAuditLevel="Success" />
</behavior>
</serviceBehaviors>
</behaviors>
Intercâmbio seguro de metadados
A exportação de metadados para clientes é conveniente para desenvolvedores de serviços e clientes, pois permite downloads de configuração e código de 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 sobre HTTP (HTTPS). Para fazer isso, você deve primeiro vincular um certificado X.509 adequado a uma porta específica no computador que está hospedando o serviço. (Para obter mais informações, consulte Trabalhando com certificados.) Em segundo lugar, adicione um serviceMetadata> à configuração do serviço e defina o HttpsGetEnabled atributo como true.< Por fim, defina o HttpsGetUrl atributo como a URL do ponto de extremidade de metadados do serviço, conforme mostrado no exemplo a seguir.
<behaviors>
<serviceBehaviors>
<behavior name="NewBehavior">
<serviceMetadata httpsGetEnabled="true"
httpsGetUrl="https://myComputerName/myEndpoint" />
</behavior>
</serviceBehaviors>
</behaviors>