Auditando serviços WCF

by Israel Aece 3. March 2010 09:50

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
---------------------------------------------------------------------------------

Tags: , ,

WCF

MaxItemsInObjectGraph

by Israel Aece 11. February 2010 06:55

Há algum tempo, eu comentei aqui sobre os limites e cotas que o WCF possui, que se não se atentar em ajustar de acordo com a sua necessidade, exceções começam a ser disparadas se você excede os valores que lá estão.

Além daquelas configurações, ainda há uma outra configuração/cota que interfere na quantidade de informações que trafegam entre as partes, que é a MaxItemsInObjectGraph. Essa propriedade recebe um número inteiro (que por padrão é 65.536 (64KB)), que especifica a quantidade máxima de objetos que podem ser serializados ou deserializados pelo DataContractSerializer. Se tentar enviar e/ou receber uma quantidade de objetos maior que o valor especificado por essa cota, você pode se deparar com a seguinte exceção do tipo SerializationException, como é mostrado abaixo:

Unhandled Exception: System.ServiceModel.CommunicationException: There was an error while trying to serialize parameter http://tempuri.org/:clientes. The InnerException message was 'Maximum number of items that can be serialized or deserialized in an object graph is '200'. Change the object graph or increase the MaxItemsInObjectGraph quota. '.  Please see InnerException for more details. ---> Systm.Runtime.Serialization.SerializationException: Maximum number of items that can be serialized or deserialized in an object graph is '200'. Change the object graph or increase the MaxItemsInObjectGraph quota.

A configuração desta opção não está em nível de binding, ao contrário do que acontece com as outras cotas, pois ela está relacionada ao serializador que o serviço utiliza para uma operação em particular. É importante dizer que essa configuração deve estar sincronizada entre o cliente e serviço, caso contrário, o erro persistirá. Há diversas formas para configurarmos ela, e a primeira delas é através da propriedade MaxItemsInObjectGraph exposta pelo atributo ServiceBehaviorAttribute:

[ServiceBehavior(MaxItemsInObjectGraph = 1000)]
public class Servico : IContrato
{
    public Cliente[] Ping(Cliente[] clientes)
    {
        //...
    }
}

A outra forma de configuração é acessando diretamente as descrições do serviço, de forma imperativa, onde poderá customizar essa informação para uma operação específica. O código abaixo mostra como proceder para alterá-la do lado do serviço e do lado do cliente, respectivamente:

serviceHost
    .Description
    .Endpoints[0]
    .Contract
    .Operations[0]
    .Behaviors
    .Find<DataContractSerializerOperationBehavior>().MaxItemsInObjectGraph = 1000;

proxy
    .Endpoint
    .Contract
    .Operations[0]
    .Behaviors
    .Find<DataContractSerializerOperationBehavior>().MaxItemsInObjectGraph = 1000;

Além disso, ainda podemos optar por configurá-la através do respectivo arquivo de configuração da aplicação (cliente ou serviço). Para isso, utilizamos o elemento dataContractSerializer, que é um behavior que será aplicado no endpoint do serviço, como podemos reparar abaixo:

<configuration>
    <system.serviceModel>
        <behaviors>
            <endpointBehaviors>
                <behavior name="config">
                    <dataContractSerializer maxItemsInObjectGraph="1000" />
                </behavior>
            </endpointBehaviors>
        </behaviors>
        <client>
            <endpoint address=""
                      behaviorConfiguration="config"
                      binding="basicHttpBinding"
                      contract="IContrato" />
        </client>
    </system.serviceModel>
</configuration>

Tags:

WCF

Impacto de Timeouts no Proxy WCF

by Israel Aece 5. February 2010 08:32

Como comentei neste post, as exeções influenciam diretamente na vida útil do proxy de um serviço WCF. Da mesma forma, quando eventuais timeouts acontecem no serviço, isso também faz com que o proxy seja movido para um estado falho, mas não diretamente.

Isso acontece para aqueles bindings que suportam sessão, onde depois de um tempo de inatividade, a sessão que é mantida do lado do serviço para aquele cliente, será expirada, fazendo com que o canal de comunicação do serviço entre em um estado falho, não podendo mais receber requisições.

Neste momento, o proxy correspondente ainda continua aberto e íntegro, até que ele envie uma próxima requisição até o serviço que está falho, e que por sua vez, irá disparar uma exceção e retornará uma fault para o cliente, que ao recebê-la, irá mover o proxy para um estado falho e, consequentemente, nenhuma outra requisição poderá ser realizada a partir daquele proxy, a menos que você o reconstrua, podendo utilizar a mesma técnica mostrada no post anterior.

Tags: , ,

WCF

Impacto de Exceções no Proxy WCF

by Israel Aece 4. February 2010 11:17

Uma das preocupações que devemos ter em qualquer tipo de desenvolvimento é com o tratamento de erros. Eu já comentei neste artigo e vídeo as possibilidades que temos para fazer isso dentro do WCF, utilizando suas próprias características de interceptação, transformação (promoção) e propagação das exceções para faults.

Já sabemos que se conhecermos todos os eventuais problemas que podem acontecer, podemos já definí-los no contrato do serviço (através do atributo FaultContractAttribute), para que assim o cliente possa ser notificado do que realmente aconteceu. Só que ainda há uma questão que não foi tratada, que é justamente como fica o estado do proxy depois que a falha acontece no serviço?

A resposta para essa pergunta dependerá de qual tipo de exceção que está sendo disparada, e também de qual binding está sendo utilizado por aquele endpoint. Em grande parte dos cenários, vemos que o desenvolvedor utilizar a instância de um mesmo proxy para efetuar várias chamadas para o mesmo serviço, não importando se é ou não para uma mesma operação.

Envolver as chamadas para as operações dentro de um bloco try/catch, evita apenas que a aplicação cliente saiba se comportar quando um determinado erro ocorre. Mas dependendo do que aconteceu no serviço, você não conseguirá reutilizar a mesma instância do proxy. Depois da falha, qualquer tentativa de comunicacão não chegará mais até o serviço, resultando assim naquela famosa exceção do tipo CommunicationObjectFaultedException, com a seguinte mensagem:

System.ServiceModel.CommunicationObjectFaultedException: The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state

Digamos que você não está preocupado com as exceções que ocorrem dentro do seu serviço. Dentro de uma determinada operação, uma exceção CLR (ArgumentNullException, IndexOutOfRangeException, etc.) é disparada. No exemplo abaixo, estou efetuando o teste para saber se o parâmetro é ou não nulo, e sendo, uma exceção do tipo ArgumentNullException está sendo disparada:

public string Ping(string value)
{
    if (value == null)
        throw new ArgumentNullException("value");

    return value;
}

Como exceções não tratadas do lado do serviço são consideradas um risco, o canal de comunicação (proxy) não ficará mais disponível. Para os bindings que suportam sessão (NetTcpBinding, WSHttpBinding, etc.), isso quer dizer que se você tentar invocar uma segunda requisição, ele estará em um estado inválido (Faulted), o que obrigará a você recriar o proxy (instanciar novamente) para depois utilizá-lo. A solução para este caso, já foi comentada nos artigos que referencie acima, que é trabalhar explicitamente com a classe FaultException (ou até mesmo FaultException<T>):

public string Ping(string value)
{
    if (value == null)
        throw new FaultException("value");

    return value;
}

Desta forma, o canal de comunicação não será afetado, e seguramente você poderá utilizá-lo para efetuar novas requisições. Já aqueles bindings que não suportam sessão, como é o caso do BasicHttpBinding ou do WebHttpBinding (utilizado para REST/AJAX), não serão danificados, mesmo se você não estiver se preocupando com o uso da classe FaultException.

Como muitas vezes as operações recorrem a outras classes, e que muitas você não tem acesso à elas, então você dificilmente conseguirá mapear todas as exceções que podem acontecer. Para garantir que o proxy consiga se "restaurar" de um estado falho, você pode recorrer ao evento Faulted, exposto pela interface ICommunicationObject e também pela classe ClientBase<TChannel>. Este evento é disparado quando o proxy entre em estado falho, e assinando este evento, você poderia reconstruir o proxy no exato momento, como eu mostro no código abaixo:

ChannelFactory<IContrato> factory = 
    new ChannelFactory<IContrato>(new NetTcpBinding(), new EndpointAddress("net.tcp://localhost:3732/srv"));

IContrato proxy = factory.CreateChannel();
((ICommunicationObject)proxy).Faulted += (o, e) => proxy = factory.CreateChannel();

Tags: , ,

WCF

Usando LINQ To SQL com WCF

by Israel Aece 2. February 2010 21:16

Para aqueles que trabalham com LINQ To SQL e querem expor as entidades geradas pela ferramenta via WCF, terá que tomar alguns cuidados. Quando essas entidades não mantém um relacionamento, algo que é bem díficil, você consegue retorná-las a partir das operações que o serviço irá disponibilizar.

O problema começa a aparecer quando você deseja enviar para os clientes, entidades que possuem relacionamentos com outras entidades. Um exemplo clássico e que ilustra bem o cenário, é quando temos categorias e produtos, onde cada produto deverá pertencer à somente uma única categoria. Neste caso, temos uma relação direta entre elas. Mas o ponto que torna isso difícil é que o LINQ To SQL cria uma relação bidirecional entra elas. Isso quer dizer que a entidade Categoria terá uma propriedade chamada Produtos, que como o próprio nome diz, retorna a coleção dos produtos daquela categoria; além disso, a classe Produto expõe uma propriedade chamada Categoria, que retorna a instância de uma categoria em qual o produto está contido.

Quando falamos em orientação à objetos, isso é perfeitamente válido e comum. O problema ocorre quando você tenta serializar essa estrutura a partir do WCF. Como eu comentei neste outro post, o WCF tem um comportamento diferente quando há referências circulares, e não conseguirá fazer a serialização porque ele ficará em uma espécie de loop, pois com há referência bidirecional, ao serializar uma categoria, ela serializa os respectivos produtos, e para cada produto a sua respectiva categoria, e para esta categoria os seus produtos, e por aí vai. O serviço roda sem maiores problemas, mas você terá uma exceção quando quando o cliente tentar acessá-lo.

Analisando a imagem abaixo, podemos visualizar a estrutura das classes que compõem o exemplo, e logo ao lado, você pode reparar nas propriedades do arquivo (superfície) DBML, verá que existe uma propriedade chamada Serialization, que pode receber apenas dois valores: None e Unidirectional. O primeiro deles permite que as propriedades das entidades sejam serializadas de acordo com as regras impostas pelo serializador padrão do WCF, que graças a possibilidade de serializar qualquer propriedade, mesmo que elas não estejam decoradas com os atributos DataContractAttribute e DataMemberAttribute (POCO). A segunda opção, Unidirectional, faz com que ele somente consiga serializar o relacionamento em uma única direção para evitar as referências circulares. No nosso caso, teremos a entidade Categoria com a propriedade Produtos, mas a classe Produto não terá uma propriedade que define a sua categoria.

Alterando a opção de serialização para Unidirectional, a forma que você efetua a consulta também terá que mudar. Isso fará com que o LINQ To SQL não consiga trazer os dados (produtos) relacionados aquela categoria, algo que é transparente quando estamos utilizando o LINQ To SQL diretamente. Para conseguir fazer com que os dados relacionados também sejam carregados, temos que recorrer a classe DataLoadOptions, como é mostrado abaixo:

public Categoria[] RecuperarCategorias()
{
    using (DBContextDataContext ctx = new DBContextDataContext())
    {
        DataLoadOptions opts = new DataLoadOptions();
        opts.LoadWith<Categoria>(c => c.Produtos);
        ctx.LoadOptions = opts;

        return (fromin ctx.Categorias select c).ToArray();
    }
}

Mas como disse acima, isso funcionará mas você perderá a navegação bidirecional. Felizmente, podemos recorrer à propriedade boleana IsReference, que é exposta pelo atributo DataContractAttribute, definindo isso na classe Categoria. Isso permitirá a criação da navegação bidirecional, mas há um trabalho manual a ser feito para que isso funcione. Quando você muda a propriedade Serialization para None, nenhuma das propriedades é decorada com o atributo DataContractAttribute/DataMemberAttribute; já se definir essa propriedade para Unidirectional, as propriedades que são problemáticas, não estarão decoradas com o atributo DataMemberAttribute.

Sendo assim, o exemplo final fica como é mostrado abaixo, conseguindo ter no cliente, a navegação bidirecional. Obviamente que alguns membros foram omitidos por questões de espaço.

[Table(Name = "dbo.Categoria")]
[DataContract(IsReference = true)]
public partial class Categoria
{
    [DataMember]
    [Column(...)]
    public int CategoriaId

    [DataMember]
    [Column(...)]
    public string Nome

    [DataMember]
    [Association(...)]
    public EntitySet<Produto> Produtos
}

[Table(Name = "dbo.Produto")]
public partial class Produto
{
    [Column(...)]
    public int ProdutoId

    [Column(...)]
    public int CategoriaId

    [Column(...)]
    public string Nome

    [Association(...)]
    public Categoria Categoria
}

Tags: , ,

Data | WCF

Gerenciamento de Channels

by Israel Aece 1. February 2010 12:38

Algum tempo atrás eu falei sobre os internals de um proxy WCF. Como eu havia dito, existe um grande overhead quando criamos um novo proxy, que está condicionado as complexidades que podem ou não estarem habilitadas (segurança, transações, mensagens confiáveis, etc.).

Como disse naquele mesmo post, o ponto mais custoso da criação, que é a factory (ChannelFactory<TChannel>), está sendo reutilizada, em nível de AppDomain, ou seja, mesmo que você não mantenha a instância do proxy gerado (ClientBase<TChannel>) pela IDE do Visual Studio ou pelo utilitário svcutil.exe, o runtime do WCF irá reciclar a factory, e em seguida, a colocará em um cache.

Quando estabelecemos a comunicação entre o cliente e o serviço, utilizamos um canal de comunicação, referido também como channel. Estes são utilizados por nós, na maioria das vezes implicitamente, para efetuar as requisições para o respectivo serviço. Na verdade, é a factory que fornece um método chamado CreateChannel, que retorna a instância de um TransparentProxy. Este tipo nos permite efetuar uma conversão para o contrato exposto pelo documento WSDL, e assim invocar as operações como se elas fossem simples métodos locais. Se você abrir a classe que é gerada quando você faz a referência à um serviço, verá que dentro das operações sempre há uma chamada para a propriedade Channel, que por sua vez, irá até o método CreateChannel.

Como a parte custosa já está sendo reutilizada de forma performática pelo WCF, as vezes surge a dúvida se devemos ou não manter um outro cache, mas este para armazenar as instâncias dos channels que são retornados pelo método CreateChannel, mas que a classe ClientBase<TChannel> não se preocupa com isso. O objeto retornado por esse método implementa a interface ICommunicationObject, que fornece entre vários membros, um método autoexplicativo chamado Close, que é responsável por encerrar mover o estado do proxy corrente para Closed e também descartar os recursos que ele utiliza.

Assim como todo recurso caro, é importante você sempre descartá-lo quando não precisar mais dele. Isso também é o caso dos channels. Mas é importante você analisar cuidadosamente o cenário. Se você faz chamadas subsequentes, não convém a todo momento invocar o método CreateChannel para criar um novo canal; reutilize-o durante essas chamadas, e somente feche-o quando realmente não precisar mais dele, dentro daquele escopo.

Da mesma forma, antes de descartá-lo completamente, analise se você não pode manter um cache para estes channels. Fazer pooling de channels é uma boa alternativa para diminuir ainda mais os custos de criação deles. Você pode manter os channels desde que:

  • Não há um contexto de segurança exclusivo para cada usuário (SCT).
  • O mesmo channel não é utilizado por múltiplas threads ao mesmo tempo.
  • Não há manutenção de estado.

Na primeira situação o problema acontece porque as credenciais são definidas durante a criação da factory, e não podem mais serem alteradas. Já o segundo cenário, acontece porque os channels são thread-safe, ou seja, eles não dão suporte ao envio de mensagem de forma concorrente. Se em uma thread A você está utilizando o channel C1 para mandar uma mensagem grande, a thread B que utilizará o mesmo channel C1, somente conseguirá enviar a mensagem depois que a thread A finalizar. A última das situações implica quando você mantém uma sessão entre o cliente e o serviço, pois ela está fortemente ligada ao channel correspondente.

Tags: ,

WCF

UseRequestHeadersForMetadataAddressBehavior

by Israel Aece 18. January 2010 21:03

Há algum tempo, eu comentei aqui sobre um problema que é comum no WCF, quando publicamos um serviço no IIS, que o endereço público (do domínio) não aparece, mantendo o nome da máquina como endereço para o serviço.

A partir da versão 4.0 do WCF, a Microsoft adicionou um novo behavior de serviço chamado UseRequestHeadersForMetadataAddressBehavior. Ao utilizá-lo, o WCF irá automaticamente gerar os endereços (do documento WSDL e das URIs do seu interior) baseando-se no header da requisição. Abaixo vemos como podemos proceder para habilitar esse recurso, e em seguida, as imagens com o antes e depois desta funcionalidade configurada.

<system.serviceModel>
  <behaviors>
    <serviceBehaviors>
      <behavior>
        <useRequestHeadersForMetadataAddress />
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Além da configuração declarativa como vemos acima, podemos optar também pela forma imperativa. E ainda, este behavior também está disponível para o WCF 3.5 + SP1, a partir deste endereço.

Tags: ,

WCF

Tecnologias que circundam o WCF

by Israel Aece 14. January 2010 06:12

Em 2006 a Microsoft lançou a versão 3.0 do .NET Framework, que nada mais era do que "grandes blocos" que foram adicionados ao 2.0. Entre esses grandes blocos, temos o WCF. Como todo mundo sabe, ele é o novo pilar para comunicação dentro da plataforma .NET. A estrutura deste framework, facilitou a entrada de novos produtos, também criados pela Microsoft, para atender cenários específicos.

Isso acaba facilitando bastante, já que grande parte da complexidade do WCF acaba sendo abstraída do desenvolvedor. Depois do .NET Framework 3.0, veio a versão 3.5, que incorporou novas funcionalidades, e mais tarde, no PDC 2009, a Microsoft publicou novos serviços, construídos em cima do WCF. Atualmente temos os seguintes tipos de serviços disponíveis:

  • Serviços SOAP: É o WCF em si. Possibilita a construção de serviços baseando-se em padrões de mercado, que tentam manter a interoperabilidade entre várias plataformas ou com outras tecnologias, como COM+, MSMQ, .NET Remoting, etc. Esses padrões regem transações, segurança, entre outras funcionalidades. A idéia aqui é permitir a construção de serviços orientado à operações que você precisa expor ao mundo, através dos mais diversos protocolos.
  • Serviços WebHttp: A partir da versão 3.5, a Microsoft trouxe a capacidade de construir serviços REST dentro do WCF. Usando métodos como POST, GET, PUT, etc., em conjunto URLs (onde você pode formatar do jeito que desejar), temos a flexibilidade de expor operações para serem consumidas diretamente, sem envolver essas requisições em envolopes SOAP, facilitando assim o consumo por aplicações AJAX, por exemplo.
  • Serviços para Dados: Semelhante a anterior, mas a idéia é expor via REST as informações contidas em um banco de dados. Inicialmente levava o nome de ADO.NET Data Services, mas depois do PDC foi renomeado para WCF Data Services.
  • Serviços de Workflow: Basicamente, a ideia é permitir que um workflow (construído pelo Windows Workflow Foundation (WF)) possa ser consumido e coordenado por serviços WCF. Situações onde você tem operações que possuem uma longa duração, a necessidade de manter o estado entre chamadas, esse tipo de serviço poderá ajudar.
  • Serviços RIA: WCF RIA Services estará disponível juntamente com o Silverlight 4.0, e simplificará a forma como você escreverá uma aplicação N-tier, onde o cliente será o próprio Silverlight.

Tags:

CSD | WCF

Powered by BlogEngine.NET 1.5.0.0
Theme by Mads Kristensen

Sobre

Meu nome é Israel Aece e sou especialista em tecnologias de desenvolvimento Microsoft, atuando como desenvolvedor de aplicações para o mercado financeiro utilizando a plataforma .NET. [ Mais ]

Twitter

Host