cookie ticket de autenticação - Dei-Isep

Forms Authentication em ASP.NET
Em muitos sites web é necessário restringir selectivamente o acesso a determinadas
áreas, ou páginas, enquanto para outras páginas pode permitir-se acesso livre.
ASP.NET possui uma funcionalidade, designada Forms Authentication, que simplifica e
automatiza muitas tarefas de validação.
Em ASP.NET as funcionalidades de Forms Authentication são tratadas na classe
FormsAuthentication, através de métodos estáticos.
Na segurança de um sistema intervêm 2 conceitos: Autenticação e Autorização.
Autenticação é o processo pelo qual se obtém a identidade do utilizador. Como a Web
pode ser usada por qualquer utilizador anónimo, a identidade do utilizador é
normalmente obtida pedindo “username” e “password”.
Autorização consiste em permitir ou negar o acesso a um determinado recurso. Ocorre
depois da autenticação, e usa informação obtida durante o processo de autenticação.
Na terminologia usada em .Net a autenticação é implementada através de Providers.
Providers são classes que contêm métodos estáticos que possibilitam a autenticação de
Clientes.
Uma aplicação Asp.Net pode ser configurada para usar um de entre 4 modos diferentes
para Autenticação:
• Forms Authentication
• Windows Authentication
• Passport Authentication
• None
Autenticação Baseada em Formulários
(Forms-Based Authentication)
O método de autenticação mais usado para tornar seguras Aplicações Web ASP.NET é
a autenticação baseada em formulários (Forms Authentication).
Modo de funcionamento da autenticação baseada em formulários
Quando um utilizador pede uma página Web protegida pela autenticação baseada em
formulários ocorrem os seguintes eventos:
1. O browser efectua o pedido de uma página .aspx protegida.
2. ASP.NET verifica se o pedido contém um cookie de autenticação válido. Se
existe, significa que as credenciais do utilizador já foram verificadas. Então
ASP.NET efectua o teste de autorização, comparando as credenciais contidas no
cookie de autorização recebido no pedido com as regras de autorização
existentes no ficheiro web.config. Se o teste sucede o acesso à página segura é
permitido.
3. Se o pedido não contém um cookie válido, ASP.NET redirige o pedido para uma
página de login (indicada no ficheiro de configuração da aplicação), onde são
pedidas as credenciais do utilizador, normalmente username e password.
4. O código da aplicação na página de login verifica a autenticidade das
credenciais. Se autentica, anexa ao pedido um cookie com as credenciais.
5. Se a autenticação falha, o pedido é retornado com uma mensagem informando
acesso negado.
6. Se a autenticação sucede, ASP.NET verifica a autorização. Se autorizado
permite o acesso à página segura pedida originalmente. Se não autorizado
redirige o pedido para uma outra página informando a não autorização ou
simplesmente retorna com uma mensagem de acesso negado.
Com Forms Authentication é necessário criar um formulário para pedir as credenciais
do utilizador (username e password) . Se as credenciais são validadas com sucesso,
asp.net cria um Cookie que é automaticamente verificado em cada pedido efectuado ao
servidor.
Para configurar o processo de segurança de uma aplicação Web, coloca-se no ficheiro
web.config localizado no directório raiz da aplicação, o elemento authentication
com o atributo mode= "[Windows/Forms/Passport/None]"
Ficheiro web.config:
<configuration>
<system.web>
<authentication mode= "[Windows/Forms/Passport/None]">
</authentication>
</system.web>
</configuration>
Autorização (Protecção de Recursos)
Para proteger todos os recursos, de utilizadores não autenticados, e redirigir o utilizador
para uma página de Login (usando redirecção do lado do cliente) acrescentam-se os
seguintes elementos no ficheiro web.config
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<authentication mode="Forms">
<forms loginUrl="Login.aspx"/>
</authentication>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Para cada pedido de um recurso, por exemplo da página Admin.aspx, a aplicação
verifica se o pedido tem o cookie de autorização. Se o cookie não está presente no
pedido, o utilizador é redirigido para a página de Login com uma QueryString
indicando que após autenticação deve voltar para a página pedida inicialmente, neste
caso Admin.aspx.
A redirecção para a página de Login é efectuada com a instrução seguinte:
Response.Redirect(“Login.aspx?ReturnUrl=Admin.aspx”);
Na página de Login, se a autenticação sucede, para criar o cookie de autenticação e
redireccionar o utilizador para o recurso inicialmente pedido é necessário colocar o
seguinte código:
FormsAuthentication.RedirectFromLoginPage(nome, false);
O cookie de autenticação é criado pelo método RedirectFromLoginPage().
Este método, além de criar o cookie, redirige o utilizador para o recurso pedido
inicialmente, baseado no valor do parâmetro ReturnUrl da QueryString, ou caso o valor
do parâmetro seja null, redirige para a página Default.aspx.
O uso desta classe FormsAuthentication e outras realtivas a segurança obriga a
referenciar o namespace System.Web.Security;
using System.Web.Security;
Uma aplicação web pode ter múltiplos ficheiros web.config, colocados em diferentes
directórios, para proteger os recursos existentes no respectivo directório.
<deny users="?" />
Significa negar o acesso a todos os utilizadores não autenticados.
URL Authorization
Para estabelecermos permissões para um directório específico criámos um ficheiro
web.config.
Para indicar que apenas certas páginas específicas são seguras, deve criar-se para cada
página segura da aplicação Web um elemento <location> contendo um elemento
<system.web> o qual contém um elemento <authorization>:
<location path=”carrinhoCompras.aspx”>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</location>
O valor do atributo path do elemento location pode ser um formulário asp.net
ou um directório. Se é um directório também todos os seus subdirectórios ficam
seguros. Se se pretende segurar múltiplas páginas Web ou directórios, deve usar-se
múltiplos seções location.
A secção <authorization> contém elementos <allow> e <deny> para permitir o acesso
ou negar acesso dos utilizadores a páginas. Há dois nomes de utilizadores especiais, * e
?, com os seguintes significados:
* = qualquer utilizador (ou todos os utilizadores)
? = utilizador anónimo (ou utilizador não autenticado).
Controlo do acesso de clientes de aplicações web a recursos URL
No ficheiro web.config podemos permitir (allow) ou negar (deny) a permissão de aceder
a um recurso URL (ficheiro ou directório) para um utilizador ou grupos de utilizadores
(roles). Múltiplos utilizadores ou roles podem ser especificados num único elemento
colocando uma lista separada por vírgulas.
Para verificar um dado acesso, primeiro são usadas as regras de autorização URL do
próprio directório, em seguida as do directório pai, continuando a subir na hierarquia,
até encontrar uma regra aplicável ao utilizador corrente. Se encontra uma regra
aplicável ao utilizador corrente, o acesso é permitido ou negado de acordo com a regra
encontrada. Se não encontra nenhuma regra aplicável ao utilizador corrente, o valor por
omissão na configuração para toda a máquina especificada no ficheiro machine.config é
permissão para todos os utilizadores.
Depois de especificar o modo de autenticação, é necessário indicar que toda a aplicação
Web necessita de autorização, ou que páginas são seguras e portanto necessitam de
autorização.
Para indicar que toda a aplicação Web necessita de autorização
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
Exemplo 1:
<authorization>
<allow users="joao, maria" />
<allow roles="Administradores" />
<deny users="*" />
</authorization>
Exemplo 2:
<authorization>
<allow users=”miguel” />
<deny users=”joao” />
<deny users=”?” />
</authorization>
Significado: permissão para o utilizador miguel, não permissão para o utilizador joao e
não permissão todos os utilizadores anónimos. Qualquer outro utilizador autenticado
terá também permissão.
Providers
Serviços que necessitam de armazenamento persistente de dados (por exemplo em bases
de dados, ficheiros XML, etc.) não comunicam directamente com a camada de acesso a
dados, mas sim com um provider.
Um Provider é um módulo de software que fornece um interface uniforme entre um
serviço e uma fonte de dados.
Assim se pretendemos mudar a fonte de dados, código fora do provider não necessita
ser modificado. Para ligar os serviços ao novo provider basta apenas uma alteração na
configuração, realizada declarativamente no web.config.
A ideia é a seguinte: em vez de realizar certas acções directamente do código no
serviço, como por exemplo criar um utilizador na base de dados, delega-se a
responsabilidade dessa acção num componente separado. Deste modo, facilmente se
substitui o componente por outro para realizar a mesma função.
Em ASP.NET, o provider por omissão é a base de dados SQL Server. Assim a execução
do método Membership.CreateUser() numa página aspx resulta na inserção de um
registo na base de dados SQL Server. O registo não é criado directamente pelo método
CreateUser da classe Membership, mas por outro método semelhante do provider
configurado.
O modelo de provider permite facilmente reconfigurar a aplicação para usar um
provider diferente, por exemplo criar o utilizador num ficheiro XML, ou numa base de
dados Microsoft Access.