Como já comentei antes, o WCF fornece uma série de formas de autenticação e autorização, e mais recentemente, também já dá suporte ao WIF, assunto qual abordarei no futuro. Uma vez que a segurança esteja habilitada, uma necessidade que se tem é justamente como auditar os processos de autenticação que são realizados, independentemente do modelo de credencial que esteja sendo fornecido pelo cliente.

O WCF fornece vários pontos de estensibilidade, mas utilizá-lo há dois problemas, onde o primeiro é a necessidade de escrever o código necessário para isso, e o segundo, e mais complicado, é que a maioria (talvez todos) os pontos para acoplar algum código customizado, sempre acontece depois que o processo de autenticação já tenha sido efetuado. Já quando você possuir um modelo de autenticação customizado, você pode interceptar a validação do usuário, e caso ele não seja válido, você cataloga isso em algum lugar. Mas e quando o modelo de autenticação é Windows ou qualquer outra forma que o WCF já entende?

Apesar de informações bem simplistas, o WCF já traz nativamente um behavior que podemos utilizar em nível de serviço para auditar a autenticação. Como tudo no WCF, este behavior pode ser configurado de forma imperativa ou declarativa, e nos fornece quatro propriedades para a sua configuração, sendo elas:

• AuditLogLocation: Todas as informações geradas pela auditoria são armazenadas no log do Windows. Esta opção permite especificar o local onde essas informações serão colocadas. Temos três possíveis opções, fornecidas pelo enumerador AuditLogLocation:
  • Default: Utiliza o log padrão do sistema operacional.
  • Application: Armazena as informações no event log Application.
  • Security: Armazena as informações no event log Security.
• SuppressAuditFailure: Propriedade do tipo boleana, que permite especificar se eventuais falhas que aconteçam no momento da gravação do log sejam enviadas para a aplicação. Se a aplicação não se preocupa com as falhas que possam acontecer durante este momento, então é importante que se defina esta campo para True, caso contrário, as exceções comprometerão o funcionamento dela. Mas definir isso como True, faz com que possíveis exceções que seriam disparadas não sejam propagadas para a aplicação, e você nunca saberá se há algum problema, e quando realmente precisar recorrer aos logs de auditoria para saber se alguém acessou em um determinado dia e hora, as informações não estarão lá.
• ServiceAuthorizationAuditLevel: Este nível de auditoria consiste em catalogar as informações de autorização que são realizadas em nível de serviço, utilizando a mesma política de segurança para todos os métodos.
• MessageAuthenticationAuditLevel: Neste nível, a auditoria monitora os eventos que são gerados durante uma mensagem específica, que por sua vez, executará uma única operação.

As propriedades ServiceAuthorizationAuditLevel e MessageAuthenticationAuditLevel recebem uma das opções expostas pelo enumerador AuditLevel: None, Success, Failure ou SuccessOrFailure. A ideia aqui é permitir ao desenvolvedor catalogar somente aqueles eventos importantes para ele, pois talvez ele esteja somente interessado nas falhas que ocorreram. É importante dizer também que isso influencia no tamanho do log, e se você especificou um limite máximo, dependendo do volume de requisições que chegam para este serviço, em pouco tempo podemos exceder esse tamanho, e a partir daí, exceções podem começar a acontecer. Eis aqui um dos motivos para a existência da propriedade SuppressAuditFailure.

O código abaixo exibe a utilização deste behavior utilizando o modelo declarativo, através de um arquivo de configuração (App.config ou Web.config):

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name=”Host.Servico” behaviorConfiguration=”srvBehaviorConfig”>
        <!– endpoints –>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name=”srvBehaviorConfig”>
          <serviceSecurityAudit
            auditLogLocation=”Application”
            messageAuthenticationAuditLevel=”SuccessOrFailure”
            serviceAuthorizationAuditLevel=”SuccessOrFailure”
            suppressAuditFailure=”false” />
          <!– configurações de segurança –>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Abaixo temos o resultado que foi colocado no Event Log:

———————————————————————————
Service authorization succeeded.
Service: http://localhost:8778/srv
Action: http://www.israelaece.com/IContrato/RecuperarDados
ClientIdentity: IsraelAece
AuthorizationContext: uuid-019ae4a4-2cb5-4414-9806-1a4e22a4bf79-2
ActivityId: <null>
ServiceAuthorizationManager: XmlAuthorizationManager
———————————————————————————