Artigo Java Magazine 71 - Segurança em Aplicações Corporativas
Aprenda como compartilhar a autenticação entre as aplicações web implementando o recurso de Single Sign On no Apache Tomcat.
De que se trata o artigo:
Existem diferentes possibilidades para implementar o recurso de Single Sign On em aplicações Web. O artigo apresenta a implementação do Single Sign On utilizando o container Web Tomcat na versão 6.x.
Para que serve:
O recurso Single Sign On é útil para permitir compartilhar uma autenticação entre diversas aplicações Web. Essa técnica é utilizada por gigantes da Web, para que o usuário informe o login e senha em apenas uma das aplicações e ao acessar as demais não seja necessário autenticar-se novamente.
Em que situação o tema é útil:
A utilização do recurso de Single Sign On é relevante em ambientes corporativos onde se disponibiliza diversas aplicações Web na intranet e deseja apenas uma única autenticação, muitas vezes integradas a uma base LDAP.
Segurança em Aplicações Corporativas:
A segurança em Aplicações Web é obtida a partir da implementação de um conjunto de técnicas. A autenticação é uma técnica para garantir confidencialidade da informação. Para alcançar a autenticação em múltiplas aplicações utilizando o Apache Tomcat é necessário implementar o recurso de Single Sign On. Uma vez que seja implementado o recurso de autenticação nativa do container Web (Etapa 2), é necessário habilitar o recurso Single Sign On (Etapa 3), para termos a autenticação única e compartilhada entre as aplicações do container Web Tomcat.
A autenticação é um meio de oferecer a confidencialidade das informações disponíveis em uma aplicação. Uma forma de garanti-la nas aplicações Web é através do controle de sessão. Em um ambiente corporativo onde existem diversas aplicações hospedadas em um mesmo servidor Web com finalidades específicas, um requisito importante é prover uma única forma de autenticação. Quando não existe esse recurso para o usuário esta tarefa torna-se repetitiva e cansativa, pois o mesmo tem que informar suas credencias em cada aplicação que deseja acessar. O Single Sign On (SSO) é um mecanismo criado para permitir um único ponto de entrada no acesso do usuário. Neste caso o usuário necessita se autenticar uma única vez para acessar diversas aplicações, sem a necessidade de informar suas credenciais em cada sistema.
Neste artigo apresentaremos como é possível garantir uma única autenticação para diferentes aplicações através do compartilhamento de sessão entre contextos instalados no container Web Apache Tomcat, utilizando os seus recursos nativos. Mostraremos também, um exemplo prático que criará duas aplicações, cada uma delas será disponibilizada em um contexto diferente no servidor Web. Apesar de contextos diferentes, através do recurso Single Sign On, o usuário fará uma única autenticação e terá acesso ao conteúdo restrito de ambas as aplicações.
Ambiente WEB
Esta seção pode ser pulada sem prejuízo por leitores que já conhecem o desenvolvimento de aplicações Web, suas especificações fundamentais em Java (Servlets e JSP), e o container Apache Tomcat.
Amplamente adotado nos projetos de desenvolvimento de software, o paradigma Web se consolidou devido ao crescimento acelerado da Internet. Neste paradigma, a troca de informações entre o usuário e a aplicação acontece através da camada de apresentação, e a comunicação acontece através do protocolo HTTP (HyperText Transfer Protocol).
O fluxo na troca de mensagem é entre um navegador e um servidor Web. Mas o que vem a ser um servidor Web? É um processo capaz de receber requisições HTTP de clientes (geralmente browsers), transformá-las em chamadas para uma aplicação, e devolver-lhes uma resposta, geralmente em código HTML. Os servidores Web são compostos, geralmente, por um container HTTP, responsável por receber as requisições e enviar as respostas, e um container Web, responsável por processar essas requisições e gerar as respostas (Figura 1).
Figura 1. Modelo de requisição e resposta.
A comunicação entre o cliente e o servidor utilizando o protocolo HTTP é feita através da troca de mensagens de requisição e resposta (request/response). O cliente faz uma requisição (request) ao servidor, solicitando algum serviço, e este devolve uma mensagem de resposta (response), com as informações solicitadas. Durante esse processo de troca de mensagens, o HTTP não consegue guardar o estado de nenhuma informação, ou seja, ele não tem como manter o status da conexão e o estado das variáveis, por isso dizemos que ele é um protocolo " [...] continue lendo...