Como sabemos, aplicações Silverlight rodam no cliente, dentro do seu navegador, ou mais recentemente, também temos a possibilidade de desacoplar a aplicação do mesmo, dando a impressão ao usuário de que é uma aplicação que roda localmente. O fato da aplicação rodar "desconectada" do servidor, havia uma grande necessidade de expor funcionalidades e dados para ela, e o WCF eleito como a "ponte" entre os dois lados, para estabelecer a comunicação, permitindo com que as aplicações cheguem até a sua origem e executem alguma tarefa ou extraiam dados necessários para que elas possam trabalhar.

Desde as primeiras versões do Silverlight que temos APIs dentro dele para comunicação HTTP e a API do WCF (System.ServiceModel.dll), para abstrair toda a complexidade de consumir um serviço SOAP. Essas APIs recorrem aos recursos expostos pelo navegador, estando assim condicionadas as suas limitações. Apesar de algumas dessas limitações, como era o caso da propagação de erros do serviço para o cliente, gerenciamento de cookies e chamada concorrente para serviços, essas APIs funcionavam razoavelmente bem. Mas a questão é que os serviços tem evoluído cada vez mais, obrigando a Microsoft a melhorar o modelo de comunicação dentro do Silverlight.

O que tínhamos até a versão 2.0 é o que chamamos de Browser Http Stack. Com ela, conseguíamos efetuar comunicações com serviços, mas com algumas limitações, pois estávamos condicionados aos recursos que o navegador oferecia, afinal, ela é apenas um wrapper para ele. Além de não conseguir interpretar um erro SOAP corretamente, uma outra limitação é a possibilidade de executar serviços além dos tradicionais verbos POST e GET do protocolo HTTP. Como serviços REST estão cada vez mais populares, existe uma grande necessidade de suportar mais do que estes dois verbos.

Para resolver estes tipos de problemas, e tentar acomodar novas funcionalidades, a Microsoft incluiu na versão 3.0 do Silverlight, uma nova forma de comunicação, chamada de Client Http Stack. A palavra "Client" é porque agora a comunicação utiliza os recursos fornecidos pelo sistema operacional, burlando as limitações impostas pelo navegador. Além de resolver os problemas que vimos acima, ela permite interpretar todos os headers, melhor forma de manipular cookies, códigos de status das respostas, algumas melhorias na parte de autenticação, etc.

Uma das preocupações da Microsoft foi em manter a modelo de utilização das classes que você já utiliza para efetuar a comunicação com algum desses serviços, podendo alterar entre uma das stacks, sem precisar mudar algo no código que faz o consumo do serviço.

Por padrão o Silverlight continua utilizando o modelo tradicional (Browser Http Stack), e se você quiser utilizar o Client Http Stack, terá que explicitamente dizer isso à ele. Para isso, devemos utilizar o método estático RegisterPrefix da classe WebRequest (namespace System.Net). O primeiro parâmetro consiste na URI (http://www.site.com.br) ou apenas o prefixo (http ou https) para onde quer se comunicar. Já o segundo parâmetro indica qual dos modelos utilizar (Browser ou Client). Esse método retorna um valor boleano, indicando se o registro foi ou não realizado com sucesso. O código abaixo ilustra como podemos proceder para efetuarmos essa configuração:

WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);

Caso queira retornar a configuração padrão, então poderá utilizar a propriedade estática BrowserHttp, também exposta pela classe WebRequestCreator, assim como é exibida abaixo:

WebRequest.RegisterPrefix("http://", WebRequestCreator.BrowserHttp);

Como sabemos, podemos consumir serviços WCF em aplicações Silverlight. Isso nos permite colocar alguma tarefa em um serviço na aplicação que faz a hospedagem do serviço ou até mesmo em outros locais, fora do domínio qual ela se encontra. A ideia aqui é permitir a comunicação entre a aplicação Silverlight (que roda dentro do navegador) e serviços que estão hospedados além dessa máquina.

Mas e se precisarmos de algo mais simples, como por exemplo, a comunicação entre duas aplicações Silverlight que rodam dentro do navegador em uma mesma máquina? Utilizar o WCF aqui pode ser extremamente complicado, pois exigirá desenvolvermos uma série de funcionalidades para permitir esse interação, e ainda podemos ter um grande overhead, já que a comunicação não será local e dependerá de que a conexão esteja disponível com o servidor/serviço com qual queremos dialogar.

Para esse tipo de cenário o Silverlight fornece algo bem mais simples de se trabalhar, que é uma funcionalidade conhecida como "comunicação local". A ideia aqui é criar aplicações que geram informações, e aquelas que estiverem interessadas, podem capturá-las e tratar da forma que achar mais conveniente. Esse tipo de comunicação pode ser utilizada por plugins que rodam dentro da mesma página, em páginas diferentes, estando ou não dentro do mesmo domínio.

Através das imagens abaixo podemos analisar os cenários mais comuns. Na primeira imagem (1) temos uma única página ASPX hospedando duas aplicações Silverlight, e se precisarmos efetuar a comunicação entre elas, podemos utilizar o recurso que veremos aqui. Já na segunda imagem (2), temos duas página distintas dentro de um mesmo domínio, mas cada página hospeda uma aplicação Silverlight diferente, e da mesma forma, a comunicação também será possível. Na terceira (3) e última imagem, temos duas aplicações, mas cada uma delas está hospedada em um domínio diferente, mas isso também pode ser permitido, mas falaremos mais disso abaixo.

A implementação é relativamente simples. Para utilizarmos a comunicação local entre aplicações Silverlight, vamos recorrer aos tipos que estão disponível a partir do namespace System.Windows.Messaging. As principais classes que teremos aqui são: LocalMessageSender e LocalMenssageReceiver. Como podemos perceber, a primeira classe é responsável por enviar mensagens, enquanto a segunda se encarrega de receber tais mensagens.

Aqui é importante comentarmos sobre algumas "limitações": tudo o que podemos mandar de um lado à outro deve ser, obrigatoriamente, uma string. Qualquer coisa diferente disso, exigirá um trabalho extra, como serializar o objeto em algum formato Xml ou Json. Dependendo da quantidade de informação que você levar de um lado para outro, considere o uso do Json ao invés do Xml, que é bem menos verboso, e isso pode evitar você atingir o limite máximo do tamanho da string, que deve ser menor ou igual a 40KB. Uma outra alternativa aqui é serializar as informações em formato binário e utilizar Base64 para codificá-la.

Se vamos gerar uma aplicação que gera informações, então temos que recorrer ao uso da classe LocalMessageSender. Em seu construtor ela recebe uma string que corresponde ao nome do destinatário das mensagens geradas por ela. Já o segundo parâmetro do construtor desta classe, recebe uma string contendo o domínio que receberá as mensagens. Você pode utilizar o membro estático chamado Global desta mesma classe, que corresponde à um "*", e instrui o Silverlight que qualquer domínio poderá receber as mensagens. Finalmente, essa mesma classe fornece o método chamado SendAsync, que permite o envio de uma string para aqueles que desejarem capturá-la.

Chega o momento de efetuar a configuração do destinatário. Agora entra em cena a classe LocalMessageReceiver, que recebe em seu construtor três parâmetros: uma string com o nome do destinatário, uma das opções do enumerador ReceiverNameScope e, finalmente, uma coleção de strings, que representa os domínios de quais a aplicação poderá receber mensagens. Essa classe fornece um evento chamado MessageReceived, que é disparado quando uma nova mensagem chega para a aplicação, e para capturá-la, tudo o que precisamos fazer é nos vincularmos a este evento e acessar a mensagem através da propriedade Message do argumento MessageReceivedEventArgs. Para finalizar, o método Listen é responsável por começar a monitorar as mensagens que chegam e entregá-las para o evento acima.

Depois de conhecer essas classes, podemos já fazer o uso delas nas nossas aplicações. Para exemplificar, teremos duas aplicações Silverlight, hospedadas em locais diferentes. A ideia será permitir a comunicação entre elas, e para manter a simplicidade do exemplo, tudo o que a aplicação fará ao receber a mensagem, será colocá-la em um TextBox. Abaixo temos a configuração de uma das aplicações, utilizando tudo o que vimos acima:

public partial class MainPage : UserControl
{
    private LocalMessageSender sender;
    private LocalMessageReceiver receiver;

    public MainPage(string aplicacaoLocal, string aplicacaoRemota)
    {
        InitializeComponent();

        this.sender = new LocalMessageSender(aplicacaoRemota, LocalMessageSender.Global);
        this.receiver = new LocalMessageReceiver(
            aplicacaoLocal, ReceiverNameScope.Global, LocalMessageReceiver.AnyDomain);

        this.receiver.MessageReceived += 
            new EventHandler<MessageReceivedEventArgs>(receiver_MessageReceived);
        this.receiver.Listen();
    }

    private void receiver_MessageReceived(object sender, MessageReceivedEventArgs e)
    {
        this.Mensagens.Text += string.Format("{0}{1}", e.Message, Environment.NewLine);
    }

    private void EnviaMensagem_Click(object sender, RoutedEventArgs e)
    {
        this.sender.SendAsync(this.Mensagem.Text);
    }
}

O código da outra aplicação será exatamente igual. O único detalhe ali é o construtor da classe MainPage, que recebe como parâmetros o nome local e o nome remoto. O nome remoto é utilizado no construtor da classe LocalMessageSender, pois quero enviar mensagens para este destino. Já o nome local é utilizado pelo LocalMessageReceiver, que é de onde estou interessado em receber mensagens. Mais detalhes sobre estes parâmetros na próxima seção do artigo.

Com isso em funcionamento, ao rodar as aplicações já podemos perceber o resultado. Através da imagem abaixo, vemos que o conteúdo do TextBox da aplicação 01 foi para a aplicação 02 e vice-versa.

Parametrizando as Aplicações

Acima pudemos perceber que a classe que corresponde ao controle do Silverlight (MainPage), foi parametrizada com as duas informações, que correspondem de onde a aplicação quer receber e para onde ela quer enviar informações. Esses nomes não precisam, necessariamente, corresponder a nome de aplicações. A ideia é ter um nome coerente com o tipo de informação que está sendo gerada.

Outro detalhe importante é com relação ao nome que você define para o recebedor das mensagens, pois podemos ter a mesma aplicação carregada em outra instância do navegador, e ao definir o mesmo nome, uma exceção do tipo ListenFailedException será disparada para informar que já existe um recebedor registrado com este mesmo nome.

Para evitar isso, utilizaremos a "ponte" que existe entre o Silverlight e o código HTML que o hospeda. Isso permitirá gerarmos um valor randômico via Javascript e definir na inicialização do plugin, que será encaminhada para aqueles parâmetros que vimos no construtor da classe MainPage. Para que isso funcione, temos que adicionar um novo elemento <param /> na tag object que hospeda a aplicação Silverlight (*.xap), e nomear este parâmetro como initParams. O código abaixo ilustra a adição deste novo parâmetro, com algumas informações suprimidas por questões de espaço.

<object data="data:application/x-silverlight-2," type="application/x-silverlight-2">
    <param name="source" value="ClientBin/Aplicacao01.xap"/>
    <param
        name="initParams"
        value="AplicacaoLocal=Aplicacao01,AplicacaoRemota=Aplicacao02" />
    <!-- Outros Parâmetros -->
</object>

A configuração refere-se à aplicação 01. Para a aplicação 02, esses parâmetros estão invertidos, já que terão papéis diferentes.

Com isso, o valor colocado ali será entregue em formato de um dicionário ao evento Startup da classe Application, que estará acessível através do arquivo App.xaml. É neste momento que extraímos os parâmetros deste dicionário e preenchemos o construtor da classe MainPage, assim como podemos notar através do código abaixo:

private void Application_Startup(object sender, StartupEventArgs e)
{
    this.RootVisual = 
        new MainPage(e.InitParams["AplicacaoLocal"], e.InitParams["AplicacaoRemota"]);
}

Conclusão: Neste artigo vimos a utilização de uma técnica interessante que nos permite a comuicação local (no mesmo computador) de aplicações Silverlight. Podemos utilizar esse recurso para cada vez mais criar aplicações independentes, e se mais tarde, precisarmos de interação entre elas, podemos recorrer à este recurso simples, mas que traz um grande poder as mesmas.

ComunicaoLocalSL.zip (144.66 kb)

Recentemente escrevi sobre o consumo de serviços WCF a partir do jQuery. Naquele artigo foi comentado como construir serviços WCF para ser acessados através do ambiente REST, e além disso, vimos também como proceder para o consumo deste serviço utilizando o jQuery como cliente.

Mas um detalhe que não foi abordado no artigo foi a questão da segurança, ou melhor, do processo de autenticação do cliente que consome o serviço. Por exemplo, imagine que temos um serviço que exige que o usuário se identifique, para que assim possamos determinar se ele terá ou não acesso ao serviço. Apesar do WCF fornecer várias alternativas para isso, quando estamos em um ambiente REST, alguns cuidados especiais são necessários, quais serão abordados no decorrer deste artigo.

O primeiro detalhe para nos atentarmos é como vamos configurar o serviço para que o mesmo possa exigir as credenciais. Para expor um serviço para ser consumido através do ambiente REST, utilizamos um binding exclusivo chamado de WebHttpBinding. Em sua configuração padrão, não há nenhum tipo de autenticação configurada, mas como qualquer binding, podemos recorrer à opção security para isso.

Temos apenas três opções relacionadas à segurança para este binding: None, Transport e TransportCredentialOnly. A primeira opção desabilita qualquer tipo de proteção e autenticação no respectivo serviço. Já a segunda opção, Transport, determina que será o protocolo que deverá garantir a segurança da mensagem (HTTPS) e, finalmente, o TransportCredentialOnly, que não fornecerá integridade e confidencialidade na mensagem que está sendo trafegada, e utilizará apenas o protocolo HTTP exclusivamente para autenticação do usuário.

Depois desta configuração que determina como a comunicação deverá ser protegida, temos uma espécie de "sub-configuração" dela que precisamos nos atentar. Esta sub-configuração determina como as credenciais serão passadas para o serviço. Entre as várias formas, temos o HTTP Basic, que faz com que as credenciais viagem do cliente para o serviço sem qualquer espécie de criptografia. Esse modelo, em sua configuração padrão, tem uma forte afinidade com o Windows/Active Directory, ou seja, para utilizar esse recurso, as credenciais informadas do lado do cliente deverão refletir uma conta válida no Windows/Active Directory, algo que não vamos nos preocupar neste momento. A configuração do serviço WCF deverá ficar da seguinte forma:

<system.serviceModel>
  <services>
    <service
      name="RESTComBasicAuthentication.Services.ServicoDeUsuarios"
      behaviorConfiguration="config">
      <endpoint
        address=""
        binding="webHttpBinding"
        contract="RESTComBasicAuthentication.Services.IUsuarios"
        behaviorConfiguration="edpConfig"
        bindingConfiguration="bc" />
    </service>
  </services>
  <bindings>
    <webHttpBinding>
      <binding name="bc">
        <security mode="TransportCredentialOnly">
          <transport clientCredentialType="Basic" />
        </security>
      </binding>
    </webHttpBinding>
  </bindings>
  <!-- Outras Configurações -->
</system.serviceModel>

Quando utilizamos o modelo Basic, ao tentar acessar um recurso protegido, o próprio browser é capaz de identificar e abrir uma janela com os campos para informarmos o username e password, só que não podemos nos esquecer de que esse serviço será consumido por algum cliente, e que o foco aqui é o uso do jQuery, e com isso, de alguma forma precisamos enviar o username e password do cliente para o serviço. Como já sabemos, o jQuery oferece uma função chamada $.ajax, que nos permite configurar e efetuar a chamada para um determinado serviço ou algum outro método. Internamente, este método recorre a um objeto popularmente conhecido, que é o XMLHttpRequest. Este objeto é o responsável por gerenciar toda a comunicação entre o cliente e o serviço.

De acordo com a especificação deste objeto, há um método chamado Open, que entre os parâmetros convencionais, como endereço até o serviço, o tipo da requisição (Json ou Xml), há também como informar mais duas informações relacionadas ao processo de autenticação: username e password. Através dos parâmetros username e password, definimos duas strings que representam cada uma dessas informações. Como o jQuery abstrai o acesso a este objeto, a função $.ajax também nos permite informar o usuário e senha, como já mencionado acima. Sabendo da existência destes parâmetros, podemos configurar a chamada para o serviço através do jQuery da seguinte forma:

function RecuperarUsuario() {
    $.ajax(
    {
        type: "POST",
        username: "UsuarioQueExisteNoWindows",
        password: "123456",
        url: "http://localhost/Services/ServicoDeUsuarios.svc/RecuperarUsuario",
        contentType: "application/json",
        data: '{ "nome": "Israel Aece", "email": "ia@israelaece.com" }',
        processData: true,
        success:
            function (resultado) {
                alert(resultado.RecuperarUsuarioResult.Nome);
                alert(resultado.RecuperarUsuarioResult.Email);
            },
    });
}

Se você monitorar a requisição para este serviço com alguma ferramenta, como é o caso do Fiddler, você verá que o username e password não serão enviados até que realmente seja necessário. O modelo de autenticação Basic é baseado no processo conhecido como "Desafio HTTP 401", que funciona da seguinte forma:

• O cliente solicita um recurso (página, serviço, etc.) que está protegido.
• Ao detectar que o cliente não está autenticado, o servidor exige que ele se autentique e informe as credenciais a partir do modelo Basic. Isso é informado a partir de um header chamado WWW-Authenticate: Basic.
• Neste momento, o servidor retorna uma resposta com o código 401 (Access Denied), que instrui o cliente (browser) a solicitar as credenciais de acesso.
• Uma vez informado, o browser recria a mesma requisição, mas agora envia nos headers da mesma o username e password codificados em Base64, sem qualquer espécie de criptografia. Na resposta, o header enviado é o Authorization: Basic [Username+Password Codificado].
• Quando este header acima estiver presente, o servidor (IIS) é capaz de validá-lo no Windows/Active Directory, e se for um usuário válido, permitirá o acesso, caso contrário retornará a mesma resposta com código 401, até que ele digite uma credencial válida.

Apesar das credenciais estarem em hard-code no exemplo acima, nada impede de criarmos uma tela onde o cliente pode digitar um usuário e senha, mas lembrando que este usuário deverá exisitir no Windows/Active Directory.

Customização

O principal ponto negativo da solução acima é a necessidade de termos os usuários cadastrados no Windows, algo que pode ser inviável em um ambiente que não é controlado, como é o caso da internet. Algo muito comum em aplicações deste tipo, é a validação do usuário em uma base de dados, ou até mesmo, utilizando a estrutura do Membership do ASP.NET. Para atingirmos esse objetivo, precisamos entender um pouco mais sobre o processo de autenticação e também alguns pontos de estensibilidade.

Quando configuramos o modelo Basic, o IIS é o responsável por coordenar todo o processo de acesso ao recurso, e se o usuário não estiver autenticado, o próprio IIS devolve a mensagem com o código 401 e o header específico para o mesmo (1), para que o browser proceda com a solicitação das credenciais (2), e depois de informadas, refaz a requisição embutindo o header com as credencias codificadas (3). A imagem abaixo ilustra esse processo:

No exemplo que vimos acima, o único recurso protegido pelo modelo Basic é apenas o arquivo ServicoDeUsuarios.svc. Agora, se desejamos customizar, temos que trazer todo o controle do processo de autenticação para a aplicação, ou seja, não iremos mais querer que o IIS coordene o processo, que como sabemos, ele recorre ao Windows para validar os usuários. Sendo assim, precisamos permitir o acesso anônimo ao arquivo *.svc.

Há algum tempo eu comentei sobre a possibilidade de efetuar a customização da autenticação do WCF através de usuário e senha, utilizando a classe UserNamePasswordValidator para essa validação. O problema é que o binding WebHttpBinding não suporta a customização deste validador, o que nos obrigaria à descer o nível até o pipeline do ASP.NET para implementar algo específico para o WCF.

Ao invés disso, podemos recorrer aos interceptadores (Interceptors). Os interceptadores não estão nativamente dentro do WCF, mas estão disponíveis ao instalar o WCF-REST Starter Kit. Este kit nada mais é que um conjunto de funcionalidades que podemos incorporar aos nossos projetos WCF baseados em REST, tornando algumas tarefas comuns em algo mais simples de se resolver/implementar, como vai ser o caso aqui.

Ao instalar este kit, teremos à nossa disposição alguns novos assemblies, e entre eles um chamado Microsoft.ServiceModel.Web.dll. Uma das classes fornecidas por ele é a classe abstrata RequestInterceptor. Essa classe fornece um método abstrato chamado ProcessRequest, que permite interceptar a requisição, antes mesmo dela começar a ser executada, fornecendo um parâmetro do tipo RequestContext, que representa o contexto da requisição atual, qual será utilizado para a interação com o cliente que está tentando acessar o recurso.

Com esta possibilidade, podemos criar um interceptador que extrai o header da requisição HTTP que representa a credencial informada pelo usuário (WWW-Authenticate), e a valida em algum repositório de sua escolha, como uma base de dados. A partir daqui é necessário conhecermos como funciona o processo do modelo HTTP Basic, para conseguirmos dialogar com o cliente, para que assim ele consiga coordenar o processo de autenticação do usuário.

Como havia dito acima, o username e password não são enviados até que sejam efetivamente exigidos. Nesta customização, ao identificarmos que o header não está presente na requisição, precisamos configurar a resposta para o cliente com o código 401, que representa acesso não autorizado, e informar na resposta o mesmo header, para continuar obrigando o usuário a informar o username e password.

Para saber se o cliente informou as credenciais, precisamos detectar a presença do header chamado Authorization. Se existir, então precisamos decodificá-lo, utilizando o método FromBase64String da classe Convert, que dado uma string, retorna um array de bytes representando as credenciais separadas por um ":". Depois disso, tudo o que precisamos fazer é separá-los, para que assim podermos efetuar a validação em algum repositório. O código abaixo ilustra esse processo:

string credentials = mp.Headers["Authorization"];

if (!string.IsNullOrWhiteSpace(credentials))
{
    string decodedCredentials =
        Encoding.Default.GetString(Convert.FromBase64String(credentials.Substring(6)));

    int separator = decodedCredentials.IndexOf(':');
    username = decodedCredentials.Substring(0, separator);
    password = decodedCredentials.Substring(separator + 1);
}

Caso o header não exista ou o usuário não existir na base de dados, então podemos criar o header para que o cliente seja - novamente - obrigado a informar as credenciais. Para isso, utilizamos as propriedades da mensagem, e configuramos a mensagem de retorno. A mensagem é representada no WCF pela classe Message. O código abaixo ilustra a criação, configuração e resposta ao cliente com esta mensagem recém criada:

private void GenerateAccessDeniedMessage(ref RequestContext requestContext)
{
    Message reply = Message.CreateMessage(MessageVersion.None, null, null, 
        new DataContractJsonSerializer(typeof(object)));

    HttpResponseMessageProperty hrp = new HttpResponseMessageProperty();
    hrp.StatusCode = HttpStatusCode.Unauthorized;
    hrp.Headers.Add("WWW-Authenticate", string.Format("Basic realm=\"{0}\"", this.Realm));
    reply.Properties[HttpResponseMessageProperty.Name] = hrp;

    requestContext.Reply(reply);
    requestContext = null;
}

Se o usuário for válido, então é necessário inicializar o contexto de segurança do WCF, que é representado pela classe ServiceSecurityContext, que utiliza uma instância da classe GenericPrincipal para identificar o usuário logado.

Finalmente, tudo isso não funciona por si só. Ainda precisamos acoplar a instância desta classe à execução. Para isso, devemos recorrer a customização da classe que cria o host, que é responsável por gerenciar a execução da classe que representa o serviço. A classe ServiceHostFactory fornece um método chamado CreateServiceHost, que como o próprio nome diz, permite retornar qualquer classe que herde direta ou indiretamente da classe ServiceHost. Dentro do assembly do WCF-Rest Starter Kit, temos uma versão específica de host, chamada de WebServiceHost2. A grande diferença deste host, é que ele expõe uma propriedade chamada Interceptors, que permite adicionarmos qualquer interceptador, desde que ele herde da classe RequestInterceptor, como já vimos acima. Depois que a factory customizada foi criada, devemos alterar o arquivo *.svc para que ela seja utilizada:

<%@ ServiceHost
    Language="C#"
    Debug="true"
    Factory="RESTComBasicAuthentication.CustomRestHostFactory"
    Service="RESTComBasicAuthentication.Services.ServicoDeUsuarios"
    CodeBehind="ServicoDeUsuarios.svc.cs" %>

Uma vez que acoplamos este interceptador, ele é quem gerenciará o processo de autenticação, ou seja, o cliente irá dialogar com este interceptador, mas para que isso funcione corretamente, é necessário que a autenticação Basic esteja desabilitada no IIS. Através da imagem abaixo, podemos reparar este novo comportamento:

Conclusão: Apesar de não temos nativamente no WCF uma forma de customizar a autenticação em serviços REST, podemos recorrer ao WCF-REST Starter Kit para conseguir efetuar essa customização, utilizando a infraestrutura oferecida pelo modelo HTTP Basic para enviar as credenciais. Apesar de tudo funcionar como deveria, é importante dizer que os dados continuam sendo trafegados sem qualquer proteção, e para evitar que alguém visualize o conteúdo, é importante que toda a comunicação seja protegida pelo HTTPS.

RESTComBasicAuthentication.zip (328.00 kb)

No próximo dia 19 de junho (sábado), acontecerá em São Paulo um evento chamado Codificando 2010, organizado pela comunidade Codificando.NET. Esse evento terá várias sessões focadas exclusivamente em desenvolvimento de aplicações utilizando a plataforma .NET, com especialistas de mercado. Para maiores detalhes sobre o evento em geral, consulte o site neste endereço.

Eu fui convidado pelo Alexandre Tarifa para falar sobre WCF - Windows Communication Foundation, que é a alternativa no ambiente Microsoft/.NET para construção de aplicações distribuídas e conectadas. É importante dizer que a palestra será de nível 100, abordando superficialmente algumas das principais funcionalidades e mudanças que aconteceram nesta nova versão da tecnologia, permitindo desmistificar os principais elementos que compõem a estrutura do WCF. Abaixo temos a descrição da palestra:

Título: Distribuindo Componentes com WCF
Palestrante: Israel Aece
Descritivo: O WCF é o pilar de comunicação da plataforma .NET, e que está presente desde a versão 3.0. Através dele podemos construir serviços que podem ser consumidos pela própria empresa ou por parceiros de negócios, para que seja possível criar aplicações inteligentes e conectadas. A finalidade desta palestra é mostrar um overview sobre o WCF, abordando superficialmente as funcionalidades incluídas na versão 4.0, com exemplos práticos de sua utilização.

No próximo dia 17 de abril acontecerá um evento chamado de Community Launch. Esse evento será espalhado por todo o Brasil, onde cada região criará o evento e abordará os principais produtos da Microsoft que estarão sendo lançados neste ano de 2010, a saber: Visual Studio 2010, Windows Server 2008 R2 e SQL Server 2008 R2.

Para quem é de Piracicaba e região, este evento acontecerá na Faculdade Salesiana Dom Bosco, à partir das 08:30 da manhã. Para maiores detalhes, consulte o site do evento. Entre as várias palestras, eu sou o responsável por falar sobre o WCF - Windows Communication Foundation. É importante dizer que a palestra será de nível 100, abordando superficialmente algumas das principais funcionalidades e mudanças que aconteceram nesta nova versão da tecnologia. Abaixo temos a descrição da palestra:

Título: Overview do WCF
Palestrante: Israel Aece
Descritivo: O WCF é o pilar de comunicação da plataforma .NET, e que está presente desde a versão 3.0. Através dele podemos construir serviços que podem ser consumidos pela própria empresa ou por parceiros de negócios, para que seja possível criar aplicações inteligentes e conectadas. A finalidade desta palestra é mostrar um overview sobre o WCF, abordando superficialmente as funcionalidades incluídas na versão 4.0, com exemplos práticos de sua utilização.

IMPORTANTE: Apesar do evento ser gratuito, para poder participar é necessário efetuar o cadastro aqui.

No artigo anterior, falamos um pouco sobre os problemas conhecidos quando lidamos com a autenticação e autorização em uma aplicação, e no final dele, falei superficialmente sobre os produtos que a Microsoft tem desenvolvido para tornar a utilização do modelo baseado em claims mais simples. A partir de agora, vamos analisar os elementos que compõem o sistema de identidade, analisando o fluxo e alguns conceitos que circundam este modelo, e que é independente de tecnologia.

Tudo o que veremos a seguir é conhecido como Identity MetaSystem, que consiste em uma infraestrutura que abstrai todas as operações necessárias para promover tudo o que é preciso para suportar identidades em cima da internet, fornecendo uma arquitetura interoperável, que permite as mais variadas plataformas implementar e dar suporte à este modelo. Existem três grandes elementos que fazem parte dele, e que são responsáveis pela propagação das identidades, a saber:

• Identity Providers: É o responsável pela validação e emissão de tokens, que são fornecidos para alguém, contendo um conjunto de claims.
• Relying Parties: A aplicação que recebe e usa esses tokens que são emitidos por algum Identity Provider.
• Subjects: É alguma coisa ou alguém que possui uma identidade digital (e suas claims), e que na maioria das vezes, representará um usuário.

Cada produto desenvolvido pela Microsoft tem como alvo um dos elementos acima, sendo o ADFS 2.0 uma espécie de identity provider; já o Cardspace permite o gerenciamento das identidades de um subject e, finalmente, o WIF ajuda na construção de aplicações que recebem esses tokens. Como dito anteriormente, todos esses elementos seguem padrões de mercado, e que são rigidamente gerenciados por órgãos independentes. Os protocolos que são utilizados para troca de informações foram desenhados para cruzar limites, que antes deles, eram invioláveis (plataforma e firewalls).

Outro elemento importante que faz parte deste modelo é o Security Token Service (STS). Como o próprio nome diz, trata-se de um serviço que está dentro de um identity provider, e que é responsável por emitir e empacotar as claims que são geradas para alguém, seguindo alguns padrões de mercado que analisaremos mais tarde, ainda neste artigo.

Há algumas técnicas que podem ser utilizadas para criar ambientes baseados em claims. Por exemplo, aplicações web e serviços SOAP (WCF) podem ser considerados relying parties, pois podem fazer uso de claims fornecidas por algum identity provider em nome de alguém. Já o navegador (browser) e aplicações Smart Client, são consideradas os subjects, já que são os responsáveis por gerenciar o fluxo do processo de autenticação, que direta ou indiretamente, irão direcionar o usuário para efetuar a sua autenticação no identity provider em que a aplicação confia.

Quando utilizamos este novo modelo, temos dois ambientes, onde cada um deles trabalha de forma ligeiramente diferente. Esses ambientes são conhecidos como ambiente passivo e ativo. A partir daqui, vamos analisar cada um desses ambientes, tentando abordar como esse modelo trata cada um deles, sem abordar as tecnologias que estão envolvidas. Para ilustrar melhor como cada um deles funciona, vamos analisar a imagem abaixo:

No ambiente passivo, o subject é o browser, enquanto a relying party é uma aplicação web. Quando um usuário requisita uma página que está protegida (1), a aplicação faz essa verificação e nota que o usuário não está autenticado. Com isso, a aplicação redireciona o usuário para o identity provider em que ela confia (2). Este, por sua vez, faz a autenticação do usuário. Aqui não importa o modelo de autenticação que é utilizado (Windows, UserNames, certificados, etc.). Depois de devidamente autenticado, o identity provider retorna o token correspondente aquele usuário (3), que a partir de agora, enviará esse token para todas as requisições subsequentes (4). Como a verificação da existência do token acontece em todas as requisições, uma vez que o usuário estiver autenticado, ele não será mais redirecionado para o identity provider.

Já no ambiente ativo, o fluxo muda um pouco. Neste cenário, o subject é uma aplicação Smart Client, enquanto a relying party é um serviço SOAP (WCF). O primeiro passo passa a ser a autenticação no respectivo identity provider (1), que uma vez autenticado, um token é emitido para aquele usuário (2). Com isso, todas as requisições irão embutir em seus respectivos headers, o token deste usuário (3). Como a relying party também conhece e confia naquele mesmo identity provider, então o acesso às operações do serviço será garantido.

É importante dizer que no ambiente ativo, o processo acaba sendo mais rápido quando comparado com o ambiente passivo, pois o cliente não precisa visitar o serviço para saber qual é o identity provider que o mesmo utiliza. Isso já aconteceu durante a referência do serviço na aplicação Smart Client, que traz, além da descrição do serviço em si, informações inerentes ao identity provider em que o serviço confia.

Identity Federation

O que vimos acima consiste nos cenários onde todos os participantes estão dentro de um mesmo domínio. Mas um dos principais cenários que este modelo atende, é justamente quando temos os participantes do sistema separados, em domínios diferentes. Da mesma forma que vimos anteriormente, a aplicação ou serviço também poderá aceitar claims que são emitidas por outros identity providers, que estão além do seu domínio, mas que indiretamente há uma relação de confiança estabelecida entre eles. A possibilidade de integração entre os dois domínios também é conhecida como Identity Federation.

Utilizar esta técnica, facilitará muito a possibilidade de SSO (Single Sign-On), que é a possibilidade de se autenticar uma única vez, e reutilizar aquela mesma credencial por todas as aplicações e serviços (relying parties) que aquele usuário utiliza, mesmo que essas aplicações estejam hospedadas nos servidores dos parceiros da nossa empresa. Outro grande ponto positivo desta opção, é que se o usuário não fizer mais parte da minha empresa, tudo o que eu preciso fazer, é remover/desabilitar a sua respectiva conta no meu domínio e, consequentemente, ele não terá mais acesso aos parceiros, já que os parceiros somente confiam em usuários que possuem os tokens emitidos por mim.

Da mesma forma que vimos acima, "cenários federados" também suportam os ambientes passivo e ativo, com mudanças simples no fluxo das informações. E para clarear como o fluxo ocorrerá, vamos utilizar imagens para ilustrar, começando com o ambiente passivo:

Note que o usuário, que está no domínio 1, tenta acessar uma aplicação web que está hospedada no domínio 2 (1). A aplicação detecta que o usuário ainda não está autenticado, e o redireciona para o identity provider do domínio onde a aplicação está hospedada, que é o orgão que ela confia. Como parte deste redirecionamento, o identity provider do domínio 2 conhece o identity provider do usuário, que está no domínio 1. Isso fará com que o usuário seja novamente redirecionado para o identity provider que o conhece, que é aquele que está debaixo do domínio 1 (2). Ao validar o usuário, o token que o representa dentro da empresa é emitido (3). Depois disso, o token gerado no domínio 1, é encaminhado para o identity provider do domínio 2 (4), que o validará e fará eventuais transformações, criando ou mapeando as claims para claims que a aplicação espera. Isso fará com que um novo token seja emitido (5), e que será utilizado pelo usuário para enviar para as requisições subsequentes (6).

Da mesma forma, o ambiente ativo segue o mesmo fluxo do ambiente passivo, apenas evitando o handshake necessário no ambiente passivo, que é necessário para descobrir qual é o identity provider responsável pela autenticação. Assim como comentado acima, todas as informações necessárias já foram fornecidas durante a referência do serviço, e as requisições (5) já enviarão o token embutido em seus headers.

Observação: Acima vimos os ambientes passivo e ativo sem mencionar os detalhes de implementação de cada um deles. Isso será alvo de futuros artigos, que irão detalhar cada um dos ambientes, mostrando como proceder para configurar cada um deles.

Os Padrões

Uma das principais características que este modelo autenticação e autorização deve ter, é a interoperabilidade entre as partes envolvidas. Como a ideia permitir uma espécie de layer na internet para gerenciar toda a segurança, inclusive entre domínios, uma das principais exigências é a garantia de que toda e qualquer plataforma pudesse tirar proveito disso.

Atualmente já há várias especificações que regem grande parte das comunicações distribuídas entre plataformas, e que são conhecidas como padrões WS-*. Os padrões que compõem as especificações WS-* já estão há bastante tempo no mercado, e são gerenciados por órgãos independentes. Há padrões para grande parte das necessidades que temos hoje em dia nos sistemas distribuídos, tais como: transações, mensagens confiáveis e segurança. Como esses padrões já estão quase todos finalizados, então porque não utilizá-los? É justamente isso que ocorreu, ou seja, grande parte de toda a comunicação que é efetuada entre as partes deste modelo de autenticação, são realizadas seguindo esses padrões, mas felizmente são transparentes para o usuário final, e abstraídas através dos produtos criados pela Microsoft. Abaixo temos esses padrões elencados, com uma breve descrição de cada um deles:

• WSDL: Descreve quais funcionalidades (operações) são expostas pelo serviço.
• WS-Policy: O WSDL não descreve nada sobre os requerimentos de segurança necessários para invocar o serviço. O WS-Policy aborda este caso, fornecendo uma forma genérica de descrever os requerimentos de segurança relacionados ao respectivo serviço.
• WS-Security: Basicamente, este padrão especifica como aplicar a criptografia nas mensagens SOAP, fazendo com que as informações trafeguem de forma protegida, garantindo a confidencialidade e integridade. A forma de segurança aplicada aqui está condicionada ao formato de autenticação que você utilizará entre o subject e o identity provider. Como a interoperabilidade é um dos aspectos mais importantes, o WS-Security efetua a criptografia das mensagens através de token profiles, que descreve como mapear as tecnologias de autenticação que temos atualmente (Kerberos, UserNames, certificados, etc.), para um modelo genérico.
• WS-SecurityPolicy: Fornece um padrão para representar as capacidades e requerimentos dos serviços através de políticas.
• WS-Trust: Este padrão fornece extensões para o padrão WS-Security, definindo operações específicas de emissão, renovação e validação de tokens.
• WS-Federation: Organiza em uma linguagem de mais alto nível os padrões WS-Trust e WS-Security, definindo mecanismos para permitir que a autenticação e autorização sejam feitas entre domínios.
• WS-MetadataExchange: Permite uma forma de extrair, não somente os dados que descrevem as operações do serviço, mas também todas as funcionalidades (de infraestrutura) expostas por aquele serviço.

Além dos padrões acima, ainda temos o SAML (Security Assertion Markup Language). Enquanto o padrão WS-Security define como inserir as informações dentro do envelope SOAP, o SAML ajuda a definir o que essas informações são. O SAML é uma especificação, também baseada em XML, que permite alguém emitir afirmações a respeito de outro alguém ou para alguma coisa, independentemente da identidade que está sendo utilizada. Entre essas afirmações que fazemos sobre algo, elas também podem descrever os atributos deste alguém, que são também conhecidos como claims.

Como disse acima, o padrão WS-Trust fornece um contrato com quatro operações: Issue, Validate, Renew e Cancel. Cada uma dessas operações autoexplicativas, manipulam tokens que são gerados por um STS para seus subjects. Em todos os ambientes que vimos acima (passivo e ativo), em algum momento há um diálogo entre o subject e o STS do identity provider. Nestes casos, o diálogo é realizado para a emissão (Issue) de um token, que depois de emitido será utilizado para enviar para a aplicação (relying party) que está requerendo. Cada uma das operações expostas troca mensagens conhecidas como RST (Request Security Token) e RSTR (Request Security Token Response), especificadas pelo WS-Trust, que entre várias informações, incluem o tipo de token a ser emitido (que nada mais é que a versão do SAML que está sendo utilizada) e as claims que estão sendo solicitadas pela relying party.

Conclusão: No decorrer neste artigo, analisamos os ambientes possíveis que temos quando trabalhamos com este modelo de autenticação, incluindo o cenário federado. Além disso, analisamos como o fluxo das mensagens acontece nestes ambientes, detalhando em alto nível, os passos necessários para atingir o objetivo. Em futuros artigos, vamos explorar detalhadamente como implementar esse modelo em cada um cenários, analisando como configurar e manter um sistema que faz uso destes elementos.

Grande parte das aplicações que desenvolvemos nos dias de hoje, exigem um alto nível de segurança, o que nos obriga a desenhar um sistema consistente e evolutivo, que permite de forma simples, manipulá-lo de acordo com as necessidades que surgem durante a vida do mesmo. Isso faz com que todos os desenvolvedores, além de se preocuparem com as regras de negócio, ainda precisam saber como lidar com dois aspectos importantes de toda aplicação: autenticação e autorização.

A autenticação consiste em saber quem o usuário é identificá-lo dentro do sistema; já a autorização, determina quais privilégios esse usuário tem dentro do sistema, e para isso, obrigatoriamente deverá ocorrer depois da autenticação, já que primeiro preciso saber quem ele é para depois conseguir encontrar os direitos que ele possui dentro do sistema.

Isso não seria uma tarefa difícil se não houvesse vários mecanismos diferentes, e que permitem configurar e gerenciar tanto a autenticação quanto a autorização. Cada um destes mecanismos tem como alvo um cenário distinto, e é complicado achar uma solução que atenda à todos os cenários em que a aplicação está exposta, tornando extremamente complicado gerenciar esses aspectos em um ambiente mais amplo, e que muitas vezes acarreta em duplicação de código e possíveis vulnerabilidades.

Além disso, é importante dizer que para cada forma de autenticação e autorização que utilizamos, temos que entender o mínimo sobre como ela funciona. Como disse antes, há varias opções que temos atualmente, como por exemplo: Kerberos, Forms Authentication, Url Authorization, certificados, etc. Cada uma delas tem suas peculiaridades, e exige de nós um entendimento mínimo para saber qual desses modelos se encaixa melhor com a nossa necessidade.

Em uma análise rápida, o Kerberos é a melhor opção se queremos autenticar um usuário que consome uma aplicação ASP.NET dentro da empresa, mas não traz nenhuma informação extra além de seu token. Esse modelo é fácil de implementar até que alguém, fora da empresa, também precise acessar essa mesma aplicação. Como esse modelo exige que o usuário esteja devidamente cadastrado no Active Directory da respectiva empresa, pessoas que estão além dela, não conseguirão acessá-la, e como sabemos, manter contas para usuários "voláteis", não é uma tarefa viável. Para entender a complexidade em que vivemos atualmente, veja a imagem abaixo:

Note que dentro do quadrado verde temos uma empresa qualquer, que por sua vez, possui vários funcionários. Cada funcionário, toda manhã, efetua o login no Windows, que vai até o controlador de domínio (Active Directory), valida o usuário, e caso seja válido, permite o acesso ao sistema operacional. Felizmente, na empresa que temos como exemplo acima, os desenvolvedores se preocuparam em reutilizar as credenciais do Windows para as aplicações que rodam dentro dela, onde uma delas é uma aplicação Windows (chamada de App) e que consome um serviço WCF, e a própria intranet, hospedada no IIS, e que também utiliza autenticação integrada ao Windows.

Agora repare que este mesmo usuário também acessa outras aplicações, que estão fora do domínio da empresa em que ele trabalha. O acesso a loja para comprar presentes, possui seu próprio sistema de autenticação e autorização, obrigando este usuário a criar uma conta ali. Já quando ele tenta acessar o site do banco, um certificado é exigido para que ele proceda com o login. E, como se não bastasse, a empresa em que ele trabalha mantém relações comerciais com outros parceiros, e cada um desses parceiros possui um sistema próprio de pedidos, e como já era de se esperar, cada um possui seu próprio esquema de autenticação e autorização.

Mas note que no caso do parceiro 1, a aplicação somente permite acesso para aqueles usuários que estão cadastrados dentro do AD da respectiva empresa, sendo assim, como acessá-la? Na maioria das vezes, o parceiro 1 cria uma aplicação simples, baseada em internet, e permite o acesso aos parceiros. Mas o que vai acontecer é que o parceiro 1 precisará, novamente, de uma nova forma para controlar os usuários que irão acessar tal aplicação, e muito provavalmente, irá recorrer à uma base de dados customizada para isso (se a aplicação for ASP.NET, podemos recorrer ao Membership). Mas essa solução dá início a outro problema, que ocorrerá no momento em que este usuário não fizer mais parte da minha empresa, pois terei que lembrar à quais parceiros ele tinha acesso, para assim removê-lo, já que ele não poderá continuar acessando, e isso ainda obrigará ao parceiro, criar uma interface (tela) para a administração de usuários.

Deixar para cada um implementar, de forma arbitrária, o modelo de autenticação e autorização, dá margem para que os desenvolvedores façam isso de qualquer modo, não se preocupando com pontos importantes, como por exemplo, o armazenamento das senhas de forma segura (hash), tráfego das credenciais através de um protocolo que não permita ninguém interceptar, evitar ataques de brutal-force, DoS, etc. Além destes problemas de infaestrutura, ainda temos as políticas de senhas, já que muitas aplicações não asseguram que a senha escolhida pelo usuário seja uma senha segura; a reutilização de senhas é um problema grave, pois para evitar o esquecimento, muitas pessoas utilizam a mesma senha para todas as aplicações que elas utilizam, e uma vez que isso cai em mãos erradas, o estrago pode ser irreparável. A reutilização é fácil até que você encontre aplicações com políticas de senha diferentes, pois o que pode ser uma senha válida para uma aplicação, não é para outra, obrigando a você escolher outra senha que se enquadre com as políticas desta aplicação, voltando assim, ao inferno das senhas diferentes.

Outro grande desejo que existe e que é difícil de implementar, é a capacidade de termos SSO (Single Sign-On) entre as aplicações, ou seja, a capacidade que damos ao usuário de se autenticar uma única vez, e assim poder acessar todas aquelas aplicações que confiam naquele autenticador. Algo mais ou menos como o que acontece com o Windows Live Id, onde você se autentica uma única vez, e tem acesso à todos os sites da Microsoft que são protegidos por ele.

Qual seria então o modelo ideal para resolver grande parte dos problemas que vimos acima? O modelo ideal seria a possibilidade de centralizar a autenticação em um único local, que determinará como ela deverá ser realizada e protegida. A centralização evitará com que toda a aplicação se preocupe com a lógica de autenticação, já que não competirá mais a ela esse papel. Os desenvolvedores podem se concentrar apenas no desenvolvimento da aplicação em si, com as regras de negócios, interfaces (telas), serviços, etc. Com a autenticação "externalizada", não precisamos mais misturar códigos de infraestrutura com códigos de regras de negócios, tornando a aplicação muito mais limpa, e, além disso, outro grande benefício com a refatoração é a facilidade que teremos em dividir o que compete ao desenvolvedor e o que compete ao administrador da rede.

O modelo que visa esse cenário é conhecido como Claims-Based Identity Model, ou seja, modelo de identidade baseado em claims, que traduzindo significa "afirmações". Nesse modelo, as aplicações que desenvolveremos não serão mais responsáveis por autenticar e muito menos por armazenar suas senhas. Para fazer uma analogia ao mundo real de como esse modelo trabalha, podemos recorrer ao exemplo da compra de algum produto através do cartão de crédito. Quando você vai pagar por esse produto, você fala que vai pagar com o cartão de crédito, mas a loja não confia em você, quando você diz: “Olha, eu tenho R$ 2.000,00 de crédito, pode me vender!”. Na verdade, o que a loja faz é "validar" aquele cartão que você apresentou, junto aquele que o emitiu, que é a operadora. É ela quem dirá se aquele cartão é ou não válido e dizer até o quanto você poderá gastar. A loja utilizará essas informações para proceder ou não com a venda.

Neste cenário descrito acima, note que a loja nada sabe sobre o cliente, mas confia em alguém que o avaliza. A partir daí, a loja geralmente faz o cadastro do cliente, colhendo o seu e-mail, endereço, etc., para mais tarde conseguir enviar um catálogo dos novos produtos. Da próxima vez que você vai comprar novamente a validação é realizada na operadora do cartão, mas seus dados cadastrais já estão catalogados, podendo ser apenas atualizados.

Outro ponto importante deste cenário, é que a autorização ainda deve ser realizada pela aplicação, ou seja, ela ainda é responsável por determinar o que usuário pode ou não acessar. Mas atualmente, os direitos de acessos que concedemos à determinadas funcionalidades dentro da aplicação, geralmente são determinadas por grupos, ou seja, se o usuário fizer parte do grupo Administradores, então ele pode ter acesso às contas corrente dos clientes. Mas no cenário descrito acima, ele vai além disso, já que a autorização é concedida baseando-se no limite do cartão de crédito.

Isso é mais um dos benefícios das aplicações baseadas em claims. As afirmações emitidas por alguém contra outro alguém, pode ser qualquer tipo de informação, e você refina o acesso através delas. Muitas vezes a autorização vai muito além dos grupos (simples strings) que o usuário pertence, pois há situações em que podemos negar ou conceder acesso de acordo com a data de nascimento, ou seja, se ele tiver mais do que 21 anos, então poderá acessar o conteúdo.

Para fazer com que tudo isso funcione, a Microsoft tem trabalhado em três produtos que, juntos ou separadamente, fornecerão grande parte do que precisamos para atingir o nosso objetivo, que é a centralização e o gerenciamento do processo de autenticação. Cada um desses produtos, implementam padrões de mercado, e por isso podem ser utilizados separadamente, ou melhor, podemos ter uma dessas ferramentas Microsoft falando com outras desenvolvidas pela IBM utilizando Java, pois todas falam o mesmo "idioma". A Microsoft criou a solução completa, composta de três produtos que estão listados abaixo, com suas respectivas descrições:

• WIF - Windows Identity Foundation: Trata-se de um framework para a construção de aplicações baseadas em claims, e que abstrai toda a complexidade do processo de autenticação que é realizado seguindo uma série de padrões de mercado (WS-*). Além disso, a sua API traz uma série de tipos que habilitam a extensibilidade, podendo mais tarde, criar novas opções de autenticação.
• ADFS 2.0 - Active Directory Federation Services 2.0: Uma ferramenta que ajuda os administradores de rede, a gerenciar o ambiente de autenticação que será fornecido por aquelas aplicações que queiram fazer uso do modelo baseado em claims. Essa ferramenta implementa os mesmos protocolos do WIF, permitindo assim que eles interajam.
• Windows Cardspace 2.0: Uma ferramenta que é instalada nos clientes, como uma espécie de carteira virtual, que cataloga os cartões que podem ser enviados para as aplicações baseadas em claims. Trata-se de uma interface amigável que permite ao usuário final uma visualização simples do que ele tem e do que será efetivamente enviado à aplicação, podendo ele decidir se deve ou não proceder.

Conclusão: Com as informações acima, pudemos entender um pouco mais dos cenários de complexidade que possuímos e dos problemas que temos atualmente. Cada cenário exige um modelo diferente, mas que não atende a 100% dos casos. A finalidade deste artigo introdutório foi apresentar os desafios que temos, e quais soluções estão sendo oferecidas pela Microsoft, para poder tornar essa tarefa extremamente importante, em algo bem mais simples e reutilizável do que temos hoje em dia. A partir de uma série de artigos, vamos explorar cada uma das ferramentas e elementos que compõem este novo modelo de autenticação.

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.