Novidades!

Olá pessoal, há quanto tempo!! :)…. Estive ontem no Visual Studio Summit 2015 e continuo achando este o melhor evento da Microsoft para desenvolvedores. Este ano esteve especialmente bom já que temos muitas tecnologias e plataformas a caminho, tais como o Visual Studio 2015, o ASP.NET 5 e o C# 6.0. Foi bom poder conversar como os early-adopters e colher opiniões sobre o que temos de bom em cada novidade destas. Sem entrar muito em detalhes, é suficiente dizer que fiquei positivamente impressionado, fazia tempo que não via a Microsoft engajada em disponibilizar tantos recursos para os desenvolvedores. E é perceptível também o esforço em começar a integrar os produtos Microsoft com as outras plataformas, como o Visual Studio Code para Mac e Linux e nos novos recursos de integração do Visual Studio 2015 RC com o melhor do mundo open source, tais como Node.js NPM, Grunt e Bower. Para quem ainda não baixou o Visual Studio 2015 RC, recomendo fazer isto logo, vale a pena no mínimo para se preparar para estas mudanças.

Na White Fox, continuamos firmes na nossa transição de desenvolvimento MVC clássico para um modelo baseado em MVC REST APIs e uma interface rica baseada em AngularJS. Praticamente todos os nossos sistemas já possuem telas desenvolvidas com esta tecnologia e novos sistemas estão sendo feitos exclusivamente neste formato. É cada vez mais comum também expormos estas APIs para interfaces desenvolvidas para dispositivos móveis, o que faz com que nossas APIs tenham que ser desenvolvidas com um agnosticismo completo com relação às interfaces que a vão utilizar. Se por um lado isto é uma boa prática, por outro significa migrar centenas de telas de legado para este novo formato, o que muitas vezes é bem custoso.

Na parte de ORM, continuamos sem um norte claro. A maior parte de nossos sistemas continua usando a versão antiga do nHibernate com o Castle ActiveRecord. Porém a idade está começando a pesar nesta plataforma, começando a tornar difícil algumas evoluções que precisamos fazer. Fizemos algumas tentativas de migração para o Entity Framework com relativo sucesso usando o Entity Framework 6. Porém, como nossos sistemas são muito complexos (centenas de entidades), o esforço de mapeamento é considerável, e temos bugs sérios no designer do EF6 com relação a defaults de banco de dados, o que torna a atividade ainda mais complicada. E, para detonar de vez este cenário, o EF7 vai remover o modelo “database-first”, o que inviabiliza o que fizemos até agora.

Esta questão do EF7 me intriga. Conversando ontem com outros desenvolvedores, percebi que muitos têm problemas similares. O uso do EF com sucesso acontece quando o sistema é novo e tem um único “dono” para banco de dados. Porém isto não é comum na nossa realidade (e, pelo que vi, de muitas outras), pois o banco é compartilhado entre vários sistemas legados e não há um único responsável pela evolução do mesmo. Neste aspecto, até a proposta da Microsoft para substituir o modelo database-first pelo code-first com migrations não resolve, pois temos alterações que não viriam do EF. Parece que não teremos alternativa a não ser codificar os objetos na mão (e voltamos 10 anos no tempo!!). Pelo menos o uso do Power Tools para o EF deve ajudar um pouco. E estamos de olho em ferramentas de terceiros, como as da DEVART, que também podem ser uma alternativa. Mantenho vocês informados da nossa evolução.

Outro tópico muito interessante ontem foi o relativa à Microservices. Percebi que outras pessoas estão com o mesmo problema que o nosso, que é manter a agilidade em sistemas de grande porte, onde o processo de deploy é amarrado por inúmeros problemas: demoras em homologação, sistema monolítico etc. Microservices podem ser uma solução para isto, a ideia é decompor o sistema em componentes de serviço e com isto podermos substituir um ou outro sem afetar a aplicação como um todo. Em teoria, a ideia é boa, mas, na prática, ainda não temos uma plataforma definida para implementarmos isto. As implementações de Microservices normalmente fazem uso de filas de mensagens, o que gera problemas para sistemas que exigem uma resposta síncrona. Além disto ainda temos que escolher uma boa plataforma para implementar este barramento de serviços/mensageria. O Microsoft Azure tem uma implementação interessante, porém ele não é uma opção para sistemas internos. Estamos analisando possibilidades como o Service Broker do próprio SQL Server ou soluções open source como o RabbitMQ, vamos ver como fica isto nos próximos meses.

Até a próxima!

, , , ,

2 Comments

Imagina na Copa!

Olá pessoal! Acharam que eu tinha abandonado este blog em definitivo?! Negativo, ainda estou firm e forte por aqui! :-)… Só que vou parar de prometer voltar a escrever em um ritmo normal, já que cada vez que faço isto, acontece algo que me impede totalmente… No último post, falei sobre o aplicativo do Sistema Poliedro que estávamos trabalhando e que posteriormente foi denominado P4Ed (ou simplesmente P+). Então, de lá para cá ficamos (e continuamos!) completamente envolvidos com ele, muitas novas funcionalidades, várias versões, centenas de APIs… A compensação é que vemos o resultado, utilizado por milhares de alunos todos os dias, e nos sentimos orgulhosos de termos contribuído. Os aplicativos são um sucesso e nem tudo ainda foi disponibilizado, as próximas versões irão conter ainda mais funcionalidades e características e farão o P+ ser cada vez mais uma referência absoluta de mercado.

O trabalho neste projeto nos fez confrontar vários “dogmas” internos da White Fox. Como visto em posts anteriores, um dos grandes diferenciais da White Fox é o uso de um framework que permite grande produtividade no desenvolvimento de sistemas e, em especial, de interfaces. Porém, nestes 4 anos de empresa, duas coisas aconteceram: como mencionamos no post anterior, o trabalho do P+ nos fez focar na entrega de produtos SEM interface; nós fomos encarregados de desenvolver APIs e regras de negócio de servidor enquanto que empresas parceiras trabalham em paralelo na confecção de interface. Embora isto nos permitiu desenvolver o P+ em tempo recorde, ele fez com que grande parte do nosso framework fosse totalmente descartada. Daí tivemos que nos reinventar pra conseguir, tendo uma API como produto final, ter a mesma produtividade que estávamos acostumados.

O segundo fato importante destes 4 anos foi uma mudança significativa na característica das interfaces. A web continua importante, mas temos também agora, em pé de igualdade, interfaces de dispositivos móveis (em seus vários tipos) e integrações diversas com outros sistemas e plataformas. As próprias interfaces web, graças a uma evolução cada vez maior de frameworks javacript (como AngularJS, Backbone, Knockout etc.) fizeram com que todo o conceito de desenvolvimento mudasse. Com isto, parte de nosso framework perdeu sua aplicabilidade. Sobre isto, espero fazer um ou mais posts específicos, revisitando o assunto de produtividade.

O bom de se trabalhar com desenvolvimento é que o trabalho nunca é monótono. As mudanças acontecem, e em ritmo rápido. A própria Microsoft, talvez pressionada por plataformas diferentes, tem acelerado bastante o ciclo de vida de suas ferramentas e plataformas. Mal o Visual Studio 2013 foi lançado, no final do ano passado, e já tivemos o Update 1 (e, brevemente, o Update 2). Web API, aplicações MVC e a evolução acelerada da plataforma Azure, com um sem número de facilitadores, módulos e serviços prontos, faz com que tenhamos que repensar toda nossa infraestrutura de código. Só que temos que fazer isto com o avião voando; temos um sem número de sistemas pra manter, que devem continuar funcionando e ao mesmo tempo serem evoluídos para fazer uso de toda esta nova tecnologia.

Junte a isto tudo o desafio de escalabilidade do P+, também mencionado anteriormente. Embora, como arquitetos, nós busquemos fazer sistemas que sejam escaláveis, isto vale até certo ponto. Uma coisa é projetar um sistema para 10 usuários que pode chegar a 10.000 em um ano. Outra, totalmente diferente, é projetar um sistema para 5.000 que pode chegar a 1.000.000 de usuários em pouco tempo. Isto exige um grande planejamento, um trabalho grande de identificação de gargalos e, às vezes, soluções pouco ortodoxas. No P+ temos trabalhado incessantemente para buscar arquiteturas que permitam suportar grandes volumes na Cloud sem ter que reescrever a aplicação a cada aumento. É grande desafio e que, quando não adequadamente tratado, gera situações complicadas de gerenciar. Mais ou menos como suportar uma Copa do Mundo em um ambiente sem a infraestrutura adequada. E nem é só uma questão de recursos, se eles forem mal empregados ou seu uso for mal planejado, vocês podem imaginar o resultado – ou vivê-los, como vamos ter a oportunidade de fazer aqui na cidade maravilhosa, em menos de 1 mês.

Vou ficando por aqui. Tenho vários tópicos mais técnicos rascunhados que espero em algum momento transformar em posts. Até a próxima então!

, , , , , , , , , ,

Leave a comment

De volta 2!

Oi pessoal!! Depois de um looooongo tempo sem postar, finalmente consegui um tempinho. Olhando o último post, dá pra notar que estávamos extremamente ocupados no início do ano passado. Mal podíamos imaginar o que viria pela frente. Do ano passado para cá, iniciamos um enorme projeto com um de nossos clientes, o Sistema de Ensino Poliedro, que nos tomou praticamente 1 ano de contínua dedicação e deve ainda prosseguir por bastante tempo.

O projeto foi participar da construção de aplicativos móveis, iOS (iPhone e iPad) e Android (smartphones e tablets), para disponibilizar para alunos uma grande parte das informações até então só existentes no site, como agenda, notas, resultados de simulados etc. Nossa parte foi expor em serviços toda a infraestrutura do domínio que tínhamos em sistemas, de forma a funcionar tanto para os aplicativos móveis quanto para uma nova versão web, também a ser desenvolvida. Trabalhamos com empresas parceiras, que ficaram responsáveis pela construção das interfaces móveis e web.

O maior desafio foi a definição desta API de serviços, para ser o mais reusável possível sem comprometer a facilidade e uso pelas interfaces. E tinha que ser extremamente escalável, já que o número de alunos previstos para os aplicativos era superior a 30.000.

A nossa opção foi utilizar a ASP NET MVC Web API. Uma das grandes vantagens desta arquitetura foi que o Web API já é capaz de retornar dados em vários formatos, como XML e JSon, o que foi providencial para nossa meta de reusabilidade. E por ser bem leve, atendeu bem também a necessidade de escalabilidade.

Como o sistema é, em quase todas as telas, somente leitura, optamos por otimizar o acesso a dados com a criação de banco de dados construídos especialmente para este fim. Assim, desenvolvemos procedimentos para trazer dados dos nossos bancos transacionais e produzir uma informação desnormalizada, pronta para consumo pela interfaces. Embora isto tenha exigido uma grande capacidade de processamento para gerar esta informação consolidada (optamos por executar isto durante as madrugadas), o acesso de cada uma das interfaces ficou extremamente rápido e escalável.

O resultado foi um sucesso completo. Os aplicativos iOS e Android tiveram centenas de downloads nos primeiros dias e hoje, menos de 6 meses após o lançamento, já temos mais de 10.000 aparelhos, entre tablets e smartphones, com acessos de alunos. O resultado foi tão positivo que já continuamos no mesmo ritmo para construção de mais aplicativos, agora voltados para professores e gestores. Nosso cliente provavelmente é hoje uma das instituições mais modernas do país, em termos de software. Ficamos super orgulhosos de termos participado deste projeto!

Em paralelo a isto, outros clientes nossos estão nos demandando bastante. Com isto, a White Fox está totalmente ocupada e estamos em busca urgente por bons desenvolvedores. Se você quer saber mais ou se candidatar, envie-nos seu currículo para rh@whitefox.com.br

Espero não demorar mais um ano para o próximo post! Até breve!

P.S.: Para quem ainda não se inscreveu e está no rio, não percam o DNAD 2013, nestes dias 2 e 3 de agosto. A grade de palestras está excelente e a White Fox é uma das patrocinadoras!

, , , , , , , , ,

Leave a comment

De volta!

Oi pessoal! Longo tempo sem postar! Nos últimos meses acabamos ficando extremamente ocupados na White Fox, graças à coincidência da finalização de um grande projeto de um dos nossos maiores clientes com a finalização e o lançamento de mais um produto com a marca White Fox. Felizmente tudo correu excepcionalmente bem, apesar de ter dado muito trabalho e ainda estarmos trabalhando em um ritmo acima do normal. E, felizmente ou infelizmente (depende do ponto de vista), tudo indica que o ritmo este não vai diminuir em curto prazo, já que estamos com algumas iniciativas em andamento que, se concretizadas, irão significar mais um grande esforço adicional.

O projeto cuja primeira entrega foi no final do ano passado, representa o resultado de quase um ano de trabalho. Nele, tivemos que desenvolver um novo mecanismo de comunicação com o Banco Central do Brasil (BACEN), baseado em troca de mensagens e em substituição a um antigo formato baseado em emulação de terminais (sim, isto ainda existe!). O projeto foi de âmbito nacional e envolveu todos os bancos e corretoras de câmbio do país. A segunda fase do projeto está em andamento neste primeiro semestre e deve consumir esforço até meados deste ano. Por ser uma área de infraestrutura (mensageria), fizemos praticamente tudo utilizando o Web Service Factory, da Microsoft, que facilitou enormemente a criação de mensagens e serviços. As mensagens do BACEN são artefatos XML, o que nos fez utilizar XSLT para a geração e transformação das mesmas. As nossas escolhas permitiram que tivéssemos um desenvolvimento rápido e uma grande facilidade de manutenção, o que foi crucial para finalizarmos tudo a tempo. Estamos mantendo estas escolhas para esta segunda fase e, graças a elas, estamos adiantados no nosso cronograma.

O segundo grande evento foi a finalização da plataforma da XChange. Este produto é um site de comércio eletrônico de Internet, destinado à venda de cartões pré-pagos VISA Travel Money (VTM) para quem viaja ao exterior a turismo ou trabalho, no qual tenho participação. A White Fox foi chamada a fazer um software que funcionasse com o site estático desenvolvido por uma agência de propaganda. O desafio foi criar mecanismos que permitissem trabalhar as áreas dinâmicas do site sem prejuízo para o layout e para as funcionalidades de navegação. Para atender a este objetivo, tivemos que fazer uma evolução significativa no nosso framework de interface. O resultado foi melhor do que esperávamos, e agora o nosso framework suporta a integração em qualquer layout HTML, com um mínimo de esforço.

O princípio que utilizamos foi uma evolução do funcionamento anterior da nossa engine MVC, que era gerar HTML através de transformações XSLT. Nesta nova versão, ao invés de gerar a página inteira, nós somente geramos trechos da página. Assim, podemos apontar um determinado <DIV> em um HTML e ele é substituído, em tempo de renderização, por um <DIV> de conteúdo dinâmico. Isto facilita a construção e a visualização de páginas, permitindo a “injeção” de trechos dinâmicos nos arquivos HTML provenientes das agências, praticamente sem modificações nos mesmos (nem mesmo os famigerados <% %> das engines tradicionais MVC). O resultado foi excepcional e graças a esta nova versão, somos capazes de gerar sistemas de maneira ainda mais rápida.

Espero voltar a escrever posts com uma regularidade mínima. No próximo, vou falar um pouco sobre os desafios que enfrentamos recentemente com desenvolvimento para alto desempenho, com paralelismo em SQL Server. Até a próxima!

, , , , , ,

1 Comment

White Fox: Ano I

Oi pessoal! Este mês comemoramos um ano de White Fox… Nem parece que já se passou um ano desde o início! Acho que o tempo passa mais depressa quando estamos fazendo algo que gostamos. Depois de definirmos o conceito do que buscávamos e iniciar a empresa, passamos este ano consolidando e definindo processos de trabalho e refinando nossos objetivos e áreas de atuação.

Na parte interna, conseguimos evoluir muito mais do que esperava. Nosso framework está extremamente maduro, conseguimos atingir o que eu sempre buscava em termos de produtividade, para manutenção e sistemas novos. Claro que ainda tem muita coisa a evoluir, especialmente nas partes mais complexas, ligadas à interface. Mas nas áreas de infra-estrutura, de suporte ao domínio (repositórios, serviços) e de serviços horizontais (segurança, log, agendamento), atingimos um nível ótimo. Atualmente, quando iniciamos uma nova aplicação, perdemos muito pouco tempo até termos algo básico no ar, com todas as funcionalidades mínimas necessárias (login etc.). Vamos continuar evoluindo, mas ele está tão maduro que hoje precisamos gastar muito pouco tempo na sua manutenção e evolução.

Outra área que evoluiu muito mais do que esperava foi a parte de gestão de processos de desenvolvimento. Graças ao esforço do Christian (que gosta muito desta área), conseguimos definir, implantar e criar ferramentas de gestão dos processos de desenvolvimentos ágeis que usamos nos nossos projetos novos e de manutenção. Ainda tem muita coisa a ser feita, queremos automatizar mais, termos uma ferramenta mais robusta (e talvez até um produto derivado dela) e dar ainda mais transparência para nossos clientes. Estamos criando algo muito interessante para a gestão de projetos de manutenção no formato ágil. No decorrer deste segundo ano, com certeza teremos novidades neste aspecto.

Refinamos um pouco os objetivos da empresa. Continuamos a buscar uma excelência técnica e um local de trabalho extremamente agradável para o desenvolvedor. E preferimos manter uma equipe pequena, mantendo nossa maneira de trabalho, do que crescer e sacrificar qualidade. Hoje o software White Fox é utilizado principalmente quando o cliente quer algum diferencial de qualidade e velocidade de construção. Continuamos a selecionar também nossos projetos, preferindo clientes que possuam experiência na contratação de desenvolvimento ágil e que consiga identificar um ROI nos projetos que necessita.

Consolidamos também nosso programa de novos integrantes. Hoje a White Fox possui somente 3 posições: estagiários, sócios juniores e sócios sêniores. O programa de estágio é utilizado para identificar e treinar novos talentos. Sócios júniores são pessoas que possuem um talento excepcional, estão identificados com os nossos valores e estão em um momento de transição até ter todo o necessário para ser um sócio sênior. E os sócios seniores participam da gestão da empresa e são convidados a atuar como investidores em todos os nossos empreendimentos. O modelo enxuto e claro facilita a conversa com novos interessados e auxilia na identificação do que é necessário para se fazer para ser parte dela.

As perspectivas para o segundo ano são ótimas. Continuaremos a atuar nas melhorias do nosso processo interno de desenvolvimento, buscando cada vez mais inserir o cliente com o uso de ferramentas automatizadas. Continuaremos a buscar projetos onde o software seja o diferencial competitivo. E continuaremos a trabalhar pra fazer produtos cada vez melhores, de maneira rápida e com um custo adequado. Vou mantê-los informados de como isto está evoluindo aqui por este blog. Até a próxima!

, ,

2 Comments

C#, Closures e Resharper

Olá pessoal! Tivemos um problema esta semana, em tese de origem simples, mas que nos tomou um tempo enorme de debug. Quero compartilhar aqui para tentar evitar que outros sigam pelo mesmo caminho!

Para começar, imaginem este código ilustrativo abaixo. Uma rotina simples para enumerar duas vezes por uma coleção e retornar a mesma, modificada. Claro que isto é somente representativo de um código real, mas imaginem qualquer função que por alguma razão modifica elementos de uma lista e retorna a mesma ou um subconjunto da mesma. Trivial, certo? O resultado esperado desta execução são duas linhas com o número “2”.

class MinhaClase {
    public decimal Valor { get; set; }
}
    
class Program {
    static IList<MinhaClase> Calcular(IList<MinhaClase> classes) {
        foreach (var minhaClase in classes) {
            minhaClase.Valor = 1;
        }
        foreach (var minhaClase in classes) {
            minhaClase.Valor++;
        }
        return classes;
    }
    static void Main(string[] args) {
        var classes = new[] {
                                new MinhaClase { Valor = 0}, 
                                new MinhaClase { Valor = 0}, 
                                new MinhaClase { Valor = 1}
                            };
        var result = Calcular(classes.Where(c => c.Valor != 1).ToList());
        foreach (var minhaClase in result) {
                Console.WriteLine(minhaClase.Valor.ToString());
        }
        Console.ReadLine();
    }
}

Todo o problema começa quando a gente tenta refatorar e melhorar o código. Como todo bom desenvolvedor, nós usamos o Resharper, que é uma ferramenta fantástica da JetBrains para nos ajudar a gerar um bom código. Na White Fox, nós a usamos praticamente todo o tempo, ela nos poupa muito esforço de código e ajuda a evitar problemas graves de maneira completamente automática. Porém, neste caso, como a rotina “Calcular” simplesmente enumera, o Resharper vai sugerir que a gente mude o IList<> para sua classe base, um IEnumerable<>. A regra seguida por ele faz sentido pois se só estamos usando métodos da classe base, não seria necessário usar a classe derivada na assinatura. O código gerado então após a refatoração fica da seguinte forma:

class MinhaClase {
    public decimal Valor { get; set; }
}
    
class Program {
    static IEnumerable<MinhaClase> Calcular(IEnumerable<MinhaClase> classes) {
        foreach (var minhaClase in classes) {
            minhaClase.Valor = 1;
        }
        foreach (var minhaClase in classes) {
            minhaClase.Valor++;
        }
        return classes;
    }
    static void Main(string[] args) {
        var classes = new[] {
                                new MinhaClase { Valor = 0}, 
                                new MinhaClase { Valor = 0}, 
                                new MinhaClase { Valor = 1}
                            };
        var result = Calcular(classes.Where(c => c.Valor != 1));
        foreach (var minhaClase in result) {
                Console.WriteLine(minhaClase.Valor.ToString());
        }
        Console.ReadLine();
    }
}

Depois deste refactor, o resultado do programa não deveria mudar, certo? Errado! Os mais experientes irão saber que o resultado da execução deste segundo código é uma lista vazia!

A explicação para isto tem a ver com o suporte do C# para closures (ver este post, que explica o que são de maneira simples, ou esta explicação mais acadêmica aqui). As operações LINQ simplesmente geram predicados para uma closure que é executada no momento que a coleção é acessada. Tem a ver também com a diferença básica entre um IList<> e um IEnumerable<>, já que num IList<>, um GetEnumerator (executado em um foreach) sempre aponta pra coleção interna, já existente… Já em um IEnumerable<>, o GetEnumerator vai sempre acionar o container para criar coleção e aí enumerar os elementos… Isto significa que a coleção de um IEnumerable<> produzido por uma closure vai ser gerada A CADA foreach, e não uma única vez. Ou seja, cada foreach da rotina “Calcular” executa a closure, bem como o foreach do resultado final. Como neste caso a closure é um filtro de Valor != 1, no segundo foreach da rotina “Calcular” e no último (onde ele imprime o resultado no console) ele simplesmente vai retornar 0 elementos!

Onde erramos? Os mais experientes vão notar que erramos na hora que tiramos o .ToList() do final da closure que define o filtro. A razão da remoção foi que como a rotina “Calcular” agora aceita um IEnumerable<>, o ToList() não seria mais necessário. Sem o ToList(), a closure não é mais executada naquele momento e sim passada para a variável e aí toda a rotina Calcular para de funcionar. Basta colocar o .ToList() de volta que tudo passa a funcionar novamente. Este erro, aparentemente óbvio, na prática é muito fácil de ser cometido, pois o uso de expressões LINQ é cada vez mais comum e, em um código complexo de negócios, se a função sendo chamada tem parametros IEnumerable<>, uma closure pode acabar sendo enviada inadivertidamente.

Portanto, neste caso, o Resharper não só facilita os erros, como pode ainda produzir alguns muito difíceis de identificar (no nosso casso, foram horas gastas até achar onde estava a closure sendo passada). Claro que desligamos esta sugestão na nossa configuração do Resharper e o problema foi resolvido. É importante ressaltar que, mesmo apesar deste caso, continuamos a achar o Resharper uma ferramenta essencial de trabalho para nós.

Outro ponto que merece ser comentado, é que pesquisando este problema, entendemos melhor o funcionamento do IEnumerable<> e o IList<>. Como o IEnumerable<> sempre tem que gerar a coleção a cada GetEnumerator(), podemos ter um desempenho pior das coleções, na maioria dos cenários, comparado a um IList<>. Só isto já seria motivo suficiente para favorecer o uso do IList<> ao invés do IEnumerable<>.

Bom, espero ter ajudado a poupar o tempo de outras pessoas ao deparar com problemas similares. Por causa deste problema, acabamos tendo que conhecer bem mais sobre closures e coleções no .NET, assim, no final, a existência deste bug até que foi benéfica!

Até a próxima!

, ,

4 Comments

Autenticação e Segurança

Olá pessoal! Esta semana quero falar de um assunto de infra-estrutura, mas extremamente crítico em nossas aplicações: a parte de autenticação e segurança de usuários. Quando fazemos uma aplicação Web, temos que definir como nossos usuários serão autenticados. Os desenvolvedores felizes são aqueles que utilizam autenticação integrada em suas aplicações e deixam a cargo da rede e do Active Directory (AD) a tarefa de identificar quem está logado. Claro que isto funciona bem em ambiente de Intranet. Na Internet é até possível, mas em geral é uma alternativa que não é utilizada por consumir uma banda excessiva e ser estranho para o usuário, abrindo aquela tela de login Windows cada vez que se acessa um site. Existe ainda a autenticação básica, utilizada em sites HTTPS e que basicamente mapeia o usuário logado para um usuário de rede. Esta alternativa também consome bastante banda e é pouco amigável para o usuário.

Nos cenários comuns, a autenticação é feita diretamente pela aplicação e o usuário se depara com campos de “login/senha” em alguma página da aplicação Web. Nestes casos, o mecanismo mais usado no .NET é o FormsAuthentication, com cookies. Nesta modalidade, após fornecer uma combinação login/senha válida, o sistema cria um cookie que é utilizado para autenticar as requisições subsequentes do usuário. Este cookie é associado à web session do usuário (na verdade, ele serve para “amarrar” a sessão, identificando-a a partir de sua criação) e permanece válido pelo tempo definido de expiração – normalmente 30 minutos. É possível ter FormAuthentication no formato cookieless, mas é menos utilizado por ser menos seguro.

Usar o FormsAuthentication (com cookies) no .NET é algo relativamente simples, todo o trabalho é feito pelo próprio framework. Para a maior parte dos sistemas, isto atende completamente a necessidade de autenticação. Em sistemas um pouco maiores, é possível também incluir uma implementação do security membership provider (ver estes excelentes posts aqui sobre o assunto), e ter a definição de perfis por usuário, resolvendo também as necessidades de autorização. É possível encontrar na web vários exemplos de implementação até com algumas customizações destes providers, como esta aqui fazendo uso de WCF.

Os problemas começam a surgir quando a aplicação cresce ao ponto de ter que ser integrada a outros sistemas e plataformas ou ter que coexistir com outras, ou ainda ter que suportar múltiplas formas de acesso (Windows Forms p. ex.). Nestes casos, temos que ter maneiras alternativas para identificar usuários e até fazer transferências de uma aplicação para outra. Em grandes empresas, surgem necessidades como definir uma política de segurança de expiração de senhas, um banco de dados único para os usuários entre as aplicações e até a necessidade de fazer login integrado ao AD em algumas situações. Aplicações de maior porte podem também necessitar de melhor desempenho na infra-estrutura de segurança, já que isto é utilizado em praticamente todos os requests. Finalmente, em aplicações corporativas é usualmente necessário ter coletas de estatísticas de uso e usuários ativos, para efeito de monitoramento e planejamento de carga. Nestes casos, a implementação padrão de segurança pode não atender completamente e é necessário desenvolver uma própria.

No nosso caso, desenvolvemos uma solução de segurança que já está em uso há mais de 12 anos. É uma solução WCF bastante simples, com um banco de dados de usuários, perfis e aplicações, classificados por empresa. Os serviços expõem mecanismos de autenticação direta por senha e por integração ao AD. A senha não é armazenada, utilizamos um hash gerado pelo próprio .NET. A integração ao AD é algo simples ainda, baseado no ID de rede (só liberamos para algumas poucas aplicações, onde o ambiente é controlado e os riscos baixos), há planos de se utilizar o Federated Services para algo mais avançado. Todo o acesso aos serviços são feitos por um intermédio de um agente de segurança, que implementa as classes de segurança e faz a tradução para os DTOs do WCF. O sistema suporta políticas de segurança, complexidade e expiração de senhas e coleta todas as estatísticas de uso das aplicações.

A solução possui ainda métodos para suportar a geração de tokens de segurança. Este tokens são identificadores (guid) que são passados, via querystring ou qualquer outro mecanismo, de um aplicação para outra. Eles possuem uma expiração rápida e podem ser utilizados apenas uma vez. Cada token está associado à sessão do usuário que o criou e pode ser utilizados para permitir o login rápido em outra aplicação. Com isto, conseguimos fazer a transferência de uma aplicação para outra de maneira transparente para o usuário.

Todos os nossos sistemas fazem uso da mesma solução de segurança, sempre através da utilização do agente. O FormsAuthentication continua sendo usado, a diferença é que a identificação do usuário é feita por nossa solução, não utilizando o membership provider. A única coisa que fazemos na aplicação é implementar classes para encapsular as chamadas ao agente e utilizar a session do ASP.NET para armazenar o usuário ativo e as respectivas permissões. Isto garante um melhor desempenho, evitando que a cada request os dados do usuário e respectivos perfis tenham que ser obtidos via chamadas WCF.

Aplicações Windows também utilizam o agente de segurança. A diferença é que como não temos um SessionID, como na Web, acabamos por simular um criando uma chave guid cada vez que a aplicação é inicializada. Esta chave é utilizada como se fosse o identificador daquela sessão Windows e pode também ser usada para se gerar tokens de autenticação. Assim é possível, por exemplo, clicar em um botão de uma aplicação Windows Form e se abrir um browser, com uma página de uma aplicação Web, já autenticada.

É isto, espero ter dado uma idéia de como lidamos com autenticação e autorização em nossos sistemas. Se alguém tiver alguma dúvida específica, basta entrar em contato. Até a próxima!

, ,

4 Comments

Follow

Get every new post delivered to your Inbox.

Join 291 other followers