Este artigo foi traduzido por máquina.

Segurança do Silverlight

Protegendo seus aplicativos do Silverlight

Josh Twist

Minha função como um consultor com os serviços Microsoft, tenho regulares discussões com clientes e parceiros sobre segurança de aplicativos. Neste artigo, explorarei alguns dos temas que surgem nessas discussões. Em particular, falarei sobre a face de programadores novos desafios ao tentar proteger aplicativos do Silverlight e eu levará em consideração onde as equipes de desenvolvimento devem concentrar seus recursos.

Este artigo toca em muitos conceitos técnicos que você encontrará abordada em mais detalhes em outro local (incluindo esta revista). Por esse motivo, eu não explore esses tópicos em detalhes técnicos. Em vez disso, o objetivo deste artigo é “ conectar pontos ” e mostrar como você pode explorar esses conceitos para proteger seus aplicativos.

Ao planejar a segurança para um aplicativo, é útil pensar em três da: autenticação, autorização e auditoria.

Autenticação é o ato de confirmando que os usuários sejam quem afirmam ser. Geralmente fazemos isso com um nome de usuário e senha.

Autorização é o processo que confirma que um usuário, uma vez autenticado, na verdade, tem as permissões apropriadas para executar uma ação específica ou acessam um determinado recurso.

Auditoria é o ato de manter um registro de atividade que ações e as solicitações feitas em um sistema não podem ser negadas pelo usuário.

Me concentrarei nas duas primeiras, autenticação e autorização, no contexto de um aplicativo do Silverlight. Como esse é um RIA (Rich Internet Application), a maioria dos conceitos descritos neste artigo aplicar igualmente a Asynchronous JavaScript e AJAX (XML) ou outra RIA abordagens. Também explicarei como você pode impedir o acesso indesejado aos seus arquivos de aplicativo do Silverlight.

Topologia

O Silverlight é um cross-plug-in de navegador que usa muitos dos conceitos gráficos pioneira pelo Windows Presentation Foundation (WPF), permitindo que os desenvolvedores da Web criar experiências avançadas muito além do que é possível com apenas HTML e JavaScript.

Ao contrário do ASP.NET, o Silverlight é uma tecnologia de cliente, para que ele é executado em computadores ’ usuários. Portanto, desenvolvimento do Silverlight tem comprovadamente mais em comum com o Windows Forms ou WPF que com o ASP.NET. De várias maneiras, essa é uma das vantagens de maiores do Silverlight, como ele remove vários dos problemas causados pela natureza sem estado dos aplicativos da Web. No entanto, como todo o código da interface do usuário é executado em computadores cliente, você não pode confiá-lo mais.

Services (Serviços)

Ao contrário do Windows Forms, o Silverlight funciona dentro da caixa de proteção da navegador e tem um conjunto reduzido de recursos, para que ele fornece um grau maior de segurança (embora no Silverlight 4, os usuários podem identificar certos aplicativos como confiáveis e elevar privilégios ’ programas para permitir a interoperabilidade COM). Se assim, Silverlight não é possível conectar a um banco de dados diretamente, para que você deve criar uma camada de serviços que fornecem acesso a sua lógica de negócios e dados.

Normalmente, você hospedar esses serviços no servidor Web, como faria com formulários da Web do ASP.NET, por exemplo. Considerando que o código do Silverlight é executado no lado errado de limite de confiança entre seus servidores e o mundo real (consulte Figura 1), o foco do esforço da equipe deve estar sempre proteger os serviços.

Figura 1 O Silverlight é executado no lado errado do limite de confiança

Há pouco ponto na implementação de verificações de segurança rigorosas dentro do seu código do Silverlight propriamente dito. Afinal, seria fácil para um invasor acabar com o aplicativo do Silverlight completamente e chamar seus serviços diretamente, revisão lado qualquer segurança mede a implementado. Como alternativa, uma pessoa mal-intencionada pode usar um utilitário como o Silverlight Spy ou ferramentas de depuração para Windows para alterar o comportamento do seu aplicativo em tempo de execução.

Esta é uma realização importante — um serviço não pode ter certeza qual aplicativo está invocando-lo ou que o aplicativo não tenha sido modificado de alguma maneira. Portanto seus serviços deve garantir que:

• O chamador é autenticado corretamente
• O chamador está autorizado a executar a ação solicitada

Por esses motivos, a maioria neste artigo se concentra em como proteger serviços de forma que é compatível com o Silverlight. Especificamente, eu levará em consideração dois tipos diferentes de serviços hospedados pelo ASP.NET no Microsoft IIS. O primeiro tipo services criados usando o Windows Communication Foundation (WCF) oferece um modelo de programação unificado para criação de serviços. O segundo, serviços de dados do WCF (anteriormente conhecida como serviços de dados ADO.NET), se baseia no WCF para permitir que você rapidamente expõem dados usando verbos HTTP padrão, um método conhecido como REST (REPRESENTATIONAL State Transfer).

Naturalmente, se a segurança for uma preocupação, é sempre recomendável criptografar qualquer comunicação entre clientes e servidores. O uso de criptografia de HTTPS/SSL é recomendado e presume-se no decorrer deste artigo.

Atualmente, os dois métodos de autenticação mais comuns os desenvolvedores da Web usam na plataforma Microsoft são autenticação do Windows e autenticação de formulários.

Autenticação do Windows

Autenticação do Windows aproveita a autoridade de segurança local ou Active Directory para validar as credenciais do usuário. Esta é uma grande vantagem em vários cenários; isso significa que você pode gerenciar centralmente usuários com ferramentas já familiares para administradores de sistemas. Autenticação do Windows pode usar qualquer esquema suportada pelo IIS incluindo básica, digest, autenticação integrada (NTLM/Kerberos) e certificados.

O esquema integrado é a opção mais comum para uso com a autenticação do Windows, pois os usuários Don precisam fornecer seus nomes de usuário e senhas uma segunda vez. Depois que um usuário efetua logon no Windows, o navegador pode encaminhar as credenciais na forma de um token ou um handshake confirma a identidade da pessoa. Há algumas desvantagens ao uso de autenticação integrada, porque o cliente e o servidor precisam visibilidade de domínio do usuário. Como resultado, melhor ele se destina a cenários de intranet. Além disso, embora ele funciona com o Microsoft Internet Explorer automaticamente, outros navegadores, como o Mozilla Firefox, exigem configuração adicional.

Ambos os básico e a autenticação Digest normalmente exigem que os usuários novamente seus nomes de usuário e senhas quando eles iniciam uma sessão com o seu site. Mas como ambos fazem parte da especificação do HTTP, funcionam na maioria dos navegadores e até mesmo quando acessada de fora da organização.

Silverlight aproveita o navegador para comunicação, portanto, é fácil de implementar com qualquer um dos métodos de autenticação IIS acabamos de discutir a autenticação do Windows. Para obter uma descrição detalhada de como fazer isso, recomendo a leitura do guia passo a passo “ How to: Use basicHttpBinding com autenticação do Windows e TransportCredentialOnly no WCF from Windows Forms ” em MSDN.Microsoft.com/Library/cc949012. Este exemplo usa, na verdade, um cliente de teste do Windows Forms, mas se aplica a mesma abordagem para o Silverlight.

Autenticação de formulários

A autenticação de formulários é um mecanismo que fornece suporte simples para autenticação personalizada no ASP.NET. Como tal, é específico para HTTP, o que significa que também é fácil de usar no Silverlight.

O usuário insere uma combinação de nome de usuário e senha, que é enviada ao servidor para verificação. O servidor verifica as credenciais contra uma fonte de dados confiáveis (geralmente um banco de dados de usuários) e se estão corretas, retornará um cookie FormsAuthentication. O cliente apresenta, em seguida, esse cookie com as solicitações subseqüentes. O cookie é assinado e criptografado, isso somente o servidor poderá descriptografá-los — um usuário mal-intencionado não pode descriptografar nem violar a ele.

Exatamente como você chama autenticação de formulários varia dependendo de como implementar a tela de login. Por exemplo, se você usou um formulário da Web do ASP.NET que redireciona para seu aplicativo do Silverlight depois que as credenciais do usuário foram validadas, você provavelmente terá autenticação sem mais trabalho a fazer. O cookie já será tenha sido enviado para o navegador e seu aplicativo do Silverlight continuará a usar o cookie sempre fazendo uma solicitação para esse domínio.

Se, no entanto, você deseja implementar a tela de login em seu aplicativo do Silverlight, precisará criar um serviço que expõe os métodos de autenticação e envia o cookie apropriado. Felizmente, o ASP.NET já oferece o que precisa — o serviço de autenticação. Basta ativá-lo em seu aplicativo. Para obter orientações detalhadas, recomendo a leitura “ How to: Usar o serviço de autenticação ASP.NET efetuar logon por meio de aplicativos do Silverlight ” no MSDN.Microsoft.com/Library/dd560704(VS.96).

Outro recurso excelente da autenticação do ASP.NET é sua extensibilidade. Um provedor de associação descreve o mecanismo pelo qual o nome de usuário e senha são verificados. Felizmente, há um número de provedores de associação disponíveis como parte do ASP.NET, incluindo uma que pode usar bancos de dados do SQL Server e outra que usa o Active Directory. No entanto, se um provedor que atenda às suas necessidades não estiver disponível, é simples criar uma implementação personalizada.

Autorização em ASP.NET

Depois que os usuários são autenticados, é importante garantir que somente eles podem tentar invocar os serviços. Tanto comum os serviços WCF e serviços de dados do WCF são representados por um arquivo .svc em aplicativos ASP.NET. Neste exemplo, os serviços vai ser hospedado pelo ASP.NET no IIS, e demonstrarei como você pode usar pastas para proteger o acesso aos serviços.

Protegendo arquivos .svc dessa forma é um pouco confusa porque, por padrão, uma solicitação para um arquivo, na verdade, ignora a maioria das pipeline do ASP.NET, ignorando os módulos de autorização. Como resultado, para poder contar com muitos recursos do ASP.NET, você precisará ativar o modo de compatibilidade do ASP.NET. Em qualquer caso, os serviços de dados do WCF determinam que ele seja ativado. Um switch simples dentro do arquivo de configuração realiza a tarefa:

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
</system.serviceModel>
<system.web>
    <authorization>
        <deny users="?"/>
    </authorization>
</system.web>

Com compatibilidade com ASP.NET habilitada, é possível impedir o acesso a usuários não autenticados usando a seção authorization de um arquivo web.config, também mostrada no trecho de código anterior.

Ao usar autenticação de formulários, o desenvolvedor deve pense com cuidado sobre quais partes do site precisam estar acessíveis, mesmo para usuários não autenticados. Por exemplo, se todas as partes são restritas a somente usuários autenticados, como um usuário não autenticado registrará?

Geralmente é mais fácil criar uma estrutura de pastas que ofereça suporte às suas necessidades básicas de autorização. Neste exemplo, criei uma pasta de “ segura ” que contém os arquivos MyWcfService.svc e MyWcfDataService.svc e implantei um arquivo web.config. In Figura 2 você pode ver a estrutura de pasta e o trecho de código anterior mostra o conteúdo do arquivo web.config.

Figura 2 Pasta protegida, que contém o arquivo Web.config

Observe que a raiz do aplicativo deve ter acesso anônimo permitido, caso contrário, os usuários não poderão acessar a página de login.

Para sites usando a autenticação do Windows, as coisas podem ser um pouco mais simples nesse sentido, como a autenticação ocorre antes que o usuário obtém os recursos contidos no aplicativo, portanto, não há necessidade de uma página de logon específica. Usando essa abordagem, é realmente possível restringir o acesso aos serviços de forma mais detalhada, permitindo que apenas grupos específicos de usuários ou funções para acessar recursos. Para obter mais informações, consulte “ Autorizações ASP.NET ” (msdn.microsoft.com/library/wce3kxhd).

Este exemplo implementa autorização um pouco, mas sozinha a autorização em nível de pasta é muito refinada depender da maioria dos cenários.

Autorização em serviços WCF

Usando o atributo PrincipalPermission é uma maneira fácil de demanda do que um chamador de um método do Microsoft .NET Framework estar dentro de uma função específica. Este código de exemplo demonstra como isso pode ser aplicado a um ServiceOperation no WCF onde o usuário de chamada deve ser parte da função “ OrderApprovers ”:

[PrincipalPermission(SecurityAction.Demand, Role = "OrderApprovers")]
public void ApproveOrder(int orderId)
{
  OrderManag-er.ApproveOrder(orderId);
}

Isso é facilmente implementado em aplicativos que usam a autenticação do Windows para aproveitar o recurso existente para criar grupos do Active Directory para organizar usuários. Com os aplicativos usando autenticação de formulários, é possível utilizar outro ótimo baseado em provedor de recurso do ASP.NET: RoleProviders. Novamente, existem vários desses disponíveis, mas se nenhuma for adequada, você pode implementar seu próprio.

Obviamente, até mesmo por método autorização é raramente suficiente atender a toda a sua segurança precisa, e você poderá sempre voltar a escrever código de procedimento dentro de seus serviços conforme mostrado no Figura 3.

Figura 3 Usando código de procedimento para implementar autorização específica

Public void CancelOrder(int orderId)
{
  // retrieve order using Entity Framework ObjectContext
  OrdersEntities entities = new OrdersEntities();
  Order orderForProcessing = entities.Orders.Where(o => o.Id == 
    orderId).First();

  if (orderForProcessing.CreatedBy != 
    Thread.CurrentPrincipal.Identity.Name)
  {
    throw new SecurityException(
      "Orders can only be canceled by the user who created them");
  }

  OrderManager.CancelOrder(orderForProcessing);
}

O WCF é uma plataforma altamente extensível e como ocorre com todas as coisas no WCF, há várias abordagens para implementar a autorização em seus serviços. Dominick Baier e Christian Weyer discutidas várias possibilidades detalhadamente na edição de outubro de 2008 da MSDN Magazine. O artigo, “ autorização no WCF-Based Services ” (MSDN.Microsoft.com/magazine/cc948343), até mesmo iniciativas em segurança baseada em declarações, uma forma estruturada de organizar a autorização em seu aplicativo.

Autorização em serviços de dados do WCF

Serviços de dados do WCF, como o nome sugere, se baseia no WCF para fornecer acesso baseado em REST a uma fonte de dados — talvez com mais freqüência uma fonte de dados LINQ para SQL ou LINQ para Estrutura de Entidade. Em resumo, isso permite que você fornecer acesso a seus dados usando uma URL que mapeia para os conjuntos de entidade expostos pela sua fonte de dados (um conjunto de entidade geralmente mapeia para uma tabela em seu banco de dados). Permissões para esses conjuntos de entidades podem ser configuradas dentro do arquivo de code-behind de serviços. Figura 4 mostra o conteúdo do arquivo MyWcfDataService.svc.cs.

Figura 4 Um arquivo de code-behind de serviços de dados do WCF com a configuração da entidade definir regras de acesso

Public class MyWcfDataService : DataService<SalesEntities>
{
  // This method is called only once to initialize service-wide policies.
  Public static void InitializeService(IDataServiceConfiguration config)
  {
    config.SetEntitySetAccessRule("Orders", EntitySetRights.AllRead);
    config.SetEntitySetAccessRule("Products", EntitySetRights.AllRead | 
      EntitySetRights.WriteAppend | EntitySetRights.WriteDelete);
  }}

Aqui, eu já receber permissões de leitura sobre o conjunto de entidade Orders e configurado a entidade de produtos definida para permitir leitura completa, a inserção de novos registros e registra a exclusão de existentes.

No entanto, porque os serviços WCF dados processa automaticamente acesso aos dados com base nessa configuração, você Don precisa acesso direto ao código, portanto Don há nenhum lugar óbvio para implementar qualquer lógica de autorização específico. Os serviços do WCF dados oferecem suporte a interceptadores que permitem aos desenvolvedores implementar lógica entre o cliente e a fonte de dados. Por exemplo, é possível especificar um interceptador de consulta que filtra os resultados para um conjunto específico de entidade. Exemplo da Figura 5 mostra dois interceptadores consulta adicionadas à classe MyWcfDataService.

Figura 5 Consulta interceptores nos serviços de dados do WCF

[QueryInterceptor("Products")]
Public Expression<Func<Product, bool>> OnQueryProducts()
{
  String userName =ServiceSecurityContext.Current.PrimaryIdentity.Name;
  return product => product.CreatedBy == userName;
}

[QueryInterceptor("Orders")]
Public Expression<Func<Comments, bool>> OnQueryOrders()
{
  bool userInPrivateOrdersRole = 
    Thread.CurrentPrincipal.IsInRole("PrivateOrders");
  return order => !order.Private|| userInPowerUserRole;
}

A primeira é aplicada aos produtos entidade definida e garante que os usuários podem recuperar apenas os produtos criados por eles. O segundo garante que somente os usuários na função PrivateOrders podem ler ordens sinalizado particular.

Da mesma forma, é possível especificar interceptadores de alteração que são executados antes de uma entidade é inserida, modificada ou excluída como demonstrado aqui:

[ChangeInterceptor("Products")]
public void OnChangeProducts(Product product, UpdateOperations operations
{
  if (product.CreatedBy != Thread.CurrentPrincipal.Identity.Name)
  {
    throw new DataServiceException(
      "Only products created by a user can be deleted by that user");
  }
}

Na visualização inicial, o interceptador de alteração OnChangeProducts neste exemplo de código aparecerá para expor uma vulnerabilidade de segurança, porque a implementação se baseia em dados passados de uma fonte externa — especificamente o parâmetro “ produtos ”. Mas ao excluir uma entidade em serviços de dados do WCF, uma chave de entidade é passada do cliente ao servidor. Que significa que a entidade, nesse caso, o produto, tem de ser procurados novamente no banco de dados do e, portanto, pode ser confiável.

No entanto, em caso de uma atualização para uma entidade existente (por exemplo, quando o parâmetro de operações UpdateOperations.Change for igual a), o parâmetro de produto é a entidade de-serialized enviada pelo cliente, portanto não pode ser confiável. O aplicativo cliente pode ter sido modificado para especificar a propriedade CreatedBy deste produto específico para uma identidade mal intencionado do próprio usuário, assim, elevar privilégios do usurper. Que pode permitir a modificação de um produto por um indivíduo que não deve ser capaz de fazer isso. Para evitar isso, recomendo que você re-fetch entidade original da fonte de dados confiáveis com base na chave de entidade sozinho, como mostra a Figura 6.

Figura 6 Um interceptador alterar evitando Unauthorized INSERT, Update e DELETE operações

[ChangeInterceptor("Products")]
Public void OnChangeProducts(Product product, UpdateOperations operations)
{
  if (operations == UpdateOperations.Add)
  {
    product.CreatedBy = Thread.CurrentPrincipal.Identity.Name;
  }
  else if (operations == UpdateOperations.Change)
  {
    Product sourceProduct = this.CurrentDataSource.Products.Where(p =>
      p.Id == product.Id).First();
    if (sourceProduct.CreatedBy != Thread.CurrentPrincipal.Identity.Name)
    {
      throw new DataServiceException(
        "Only records created by a user can be modified by that user");
    }
  }
  else if (operations == UpdateOperations.Delete &&
    product.CreatedBy != Thread.CurrentPrincipal.Identity.Name)
  {
    Throw new DataServiceException(
      "Only records created by a user can be deleted by that user");
  }
}

Como essa implementação baseia-se muito sobre a propriedade CreatedBy da entidade Product é extremamente importante que isso é imposto de forma confiável a partir do momento em que os dados são criados. Figura 6 também mostra como isso pode ser feito substituindo qualquer valor passado pelo cliente para uma operação de adicionar.

Observe que como o exemplo significa no momento, manipulação de operações do tipo UpdateOperations.Change não é um problema. In Figura 4, o serviço foi configurado para permitir somente AllRead, WriteAppend (Inserir) e WriteDelete ações ocorram nos conjuntos de entidades de produtos. Portanto, o ChangeInterceptor nunca poderia ser chamado para uma operação de alteração, como o serviço deve rejeitar imediatamente qualquer solicitação para modificar uma entidade Product neste ponto de extremidade. Para habilitar as atualizações, a chamada para SetEntitySetAccessRule no Figura 4 teria de incluir WriteMerge, WriteReplace ou ambos.

Autenticação entre domínios

O plug-in do Silverlight pode fazer solicitações HTTP entre domínios. Uma chamada entre domínios é uma solicitação HTTP feita em um domínio diferente do qual o aplicativo do Silverlight foi baixado. A capacidade de fazer essas chamadas tradicionalmente tem sido exibida como uma vulnerabilidade de segurança. Isso permitiria que um desenvolvedor mal-intencionado fazer solicitações para outro site (por exemplo, o site do banco on-line) e automaticamente encaminhar os cookies associados a esse domínio. Potencialmente, isso poderia permitem acesso do invasor outra sessão de logon dentro do mesmo processo do navegador.

Para esse motivo, sites têm que optar permitindo chamadas entre domínios através da implantação de um arquivo de política entre domínios. Este é um arquivo XML que descreve os tipos de chamadas entre domínios são permitidos — por exemplo, a partir de qual domínio a quais URLs. Para obter mais informações, consulte “ fazendo um serviço disponível em domínio limites ” (msdn.microsoft.com/library/cc197955(VS.95)).

Você sempre deve ter cuidado ao decidir para expor qualquer informação confidencial a chamadas entre domínios. Mas se você decidir que esse é um cenário que você precisa oferecer suporte juntamente com autenticação, é importante observar que a autenticação baseada em cookie métodos — como a autenticação de formulários descrita anteriormente — não são mais adequados. Em vez disso, você poderia considerar aproveitando mensagem credenciais, onde o nome de usuário e senha são passadas para o servidor e validados com cada chamada. O WCF oferece suporte a isso por meio do modo de segurança TransportWithMessageCredential. Para obter mais informações, consulte “ How to: Usar credenciais de mensagem para proteger um serviço para aplicativos do Silverlight ” (MSDN.Microsoft.com/Library/dd833059(VS.95)).

Obviamente, essa abordagem remove ASP.NET o processo de autenticação, portanto, é difícil aproveitar ao lado do ASP.NET authorization, discutido anteriormente.

Protegendo os arquivos XAP do Silverlight

Preocupado com o Silverlight segurança freqüentemente pedir, “ como posso proteger meus arquivos XAP? ” de pessoas Às vezes, a motivação por trás dessa consulta é proteger a propriedade intelectual contida dentro do código. Nesse caso, você precisará examinar ofuscação para torná-lo mais difícil para pessoas a compreender o seu código.

Outra motivação comum é para impedir que usuários mal-intencionados interrogar o código e compreender como funciona o aplicativo do Silverlight — oferecendo-lhes a possibilidade de violar os seus serviços.

Eu geralmente responder a isso com dois pontos. Em primeiro lugar, embora seja possível restringir o download do seu aplicativo do Silverlight (arquivo .xap) para que somente usuários autenticados e autorizados, não há nenhum motivo confiar desses usuários para ser mal-intencionados qualquer menos que um usuário não autenticado. Depois que o aplicativo tiver sido baixado para o cliente, não há absolutamente nada para interromper os usuários de interrogar o código em uma tentativa para elevar seus próprios privilégios ou encaminhar as bibliotecas para outra pessoa. Perturbador pode tornar esse processo um pouco mais difícil, mas não é bom o suficiente tornar seu aplicativo seguro.

Em segundo lugar, é extremamente importante lembrar que qualquer pessoa que pode chamar legitimamente serviços por meio de seu aplicativo do Silverlight também pode chamar os serviços diretamente, usando um navegador da Internet e alguns JavaScript, por exemplo. Não há nada a fazer para impedir isso acontecendo, portanto, é fundamental que você concentre seus esforços de segurança no shoring os seus serviços. Esse direito de fazer e não importa do código do seu aplicativo do Silverlight pode armazenar um usuário mal-intencionado. No entanto, algumas pessoas ainda deseja garantir que somente usuários autenticados podem acessar seus arquivos .xap. Isso é possível, mas como é fácil depende da versão do IIS que você está usando e seu método de autenticação escolhido.

Se você estiver usando autenticação do Windows, em seguida, você pode proteger facilmente seus arquivos .xap usando segurança de diretório do IIS. Se, no entanto, você estiver usando autenticação de formulários, as coisas ficam um pouco mais complicadas. Nesse caso, cabe a FormsAuthenticationModule para interceptar e verificar o cookie que acompanha qualquer solicitação e permitir ou negar acesso ao recurso solicitado.

Como o FormsAuthenticationModule é um módulo do ASP.NET, a solicitação deve passar pelo pipeline do ASP.NET para esta inspeção ocorra. No IIS6 (Windows Server 2003) e versões anteriores, as solicitações de arquivos .xap não, será por padrão, ser roteado por meio do ASP.NET.

O IIS7 (Windows Server 2008), no entanto, introduzido o pipeline integrado, que permite que todas as solicitações para ser direcionado por meio do pipeline do ASP.NET. Se você pode implantar no IIS7 e usar um pool de aplicativos em execução no modo de pipeline integrado, proteger seus arquivos .xap, em seguida, não é mais difícil de proteger seus arquivos .svc conforme descrito anteriormente na seção Autorizações ASP.NET. Mas se você tiver implantar para IIS6 ou anterior, você provavelmente tem algum trabalho adicional para fazer.

Uma abordagem popular envolve o fluxo contínuo de bytes que compõem o seu arquivo .xap por meio de outra extensão o lida com o pipeline do ASP.NET. A maneira comum de fazer isso é por meio de uma implementação IHttpHandler (em um arquivo .ashx). Para obter mais informações, consulte “ Introdução para manipuladores HTTP ” (MSDN.Microsoft.com/Library/ms227675(VS.80)).

Outra abordagem é alterar a configuração do IIS para que arquivos .xap são roteados pelo pipeline do ASP.NET. No entanto, porque isso requer uma alteração na configuração do IIS não trivial, a primeira abordagem é mais comum.

Outro problema considerar com autenticação de formulários é a tela de login. Se, como proposto neste artigo, você optar por um formulário da Web do ASP.NET, existem sem problemas. Mas se você preferir a tela de login para ser criados no Silverlight, você terá que dividir o aplicativo em partes. Uma parte (o módulo de login) deve estar disponível para usuários não autenticados e outra (o aplicativo protegido) deve estar disponível para apenas usuários autenticados.

Você poderá adotar duas abordagens:

1. Ter dois aplicativos do Silverlight separados. A primeira seria contain a caixa de diálogo de logon e estar em uma área sem segurança do site. No login bem-sucedido, isso seria redirecionar a uma página especificando um arquivo .xap em uma área segura do seu site.
2. Divida seu aplicativo em dois ou mais módulos. O .xap inicial, localizado em uma área sem segurança do seu site, realizaria o processo de autenticação. Se tiver êxito, esse arquivo .xap seria solicitar um subseqüente a partir de uma área segura que poderia ser carregado dinamicamente no aplicativo do Silverlight. Eu recentemente blogged sobre como você pode fazer este (thejoyofcode.com/How_to_download_and_crack_a_Xap_in_Silverlight.aspx).

Josh Twist é consultor principal com a equipe de consultoria de desenvolvimento de aplicativos Microsoft no Reino Unido e podem ser encontradas blogs em thejoyofcode.com.

Graças aos seguintes especialistas técnicos para revisar este artigo: Zulfiqar Ahmed, Chris Barker e Simon Ince