JSP - Segurança

JavaServer Pages e servlets disponibilizam vários mecanismos aos desenvolvedores da Web para proteger os aplicativos. Os recursos são protegidos declarativamente, identificando-os no descritor de implantação do aplicativo e atribuindo uma função a eles.

Vários níveis de autenticação estão disponíveis, desde autenticação básica usando identificadores e senhas até autenticação sofisticada usando certificados.

Autenticação baseada em função

O mecanismo de autenticação na especificação do servlet usa uma técnica chamada role-based security. A ideia é que, em vez de restringir recursos no nível do usuário, você cria funções e restringe os recursos por função.

Você pode definir diferentes funções no arquivo tomcat-users.xml, que está localizado fora do diretório inicial do Tomcat em conf. Um exemplo deste arquivo é mostrado abaixo -

<?xml version = '1.0' encoding = 'utf-8'?>
<tomcat-users>
   <role rolename = "tomcat"/>
   <role rolename = "role1"/>
   <role rolename = "manager"/>
   <role rolename = "admin"/>
   <user username = "tomcat" password = "tomcat" roles = "tomcat"/>
   <user username = "role1" password = "tomcat" roles = "role1"/>
   <user username = "both" password = "tomcat" roles = "tomcat,role1"/>
   <user username = "admin" password = "secret" roles = "admin,manager"/>
</tomcat-users>

Este arquivo define um mapeamento simples entre username, passworde role. Observe que um determinado usuário pode ter várias funções; por exemplo,username = "both" está na função "tomcat" e na função "role1".

Depois de identificar e definir funções diferentes, as restrições de segurança baseadas em funções podem ser colocadas em diferentes recursos de aplicativos da Web usando o <security-constraint> elemento em web.xml arquivo disponível no diretório WEB-INF.

A seguir está um exemplo de entrada em web.xml -

<web-app>
   ...
   <security-constraint>
      <web-resource-collection>
         <web-resource-name>SecuredBookSite</web-resource-name>
         <url-pattern>/secured/*</url-pattern>
         <http-method>GET</http-method>
         <http-method>POST</http-method>
      </web-resource-collection>
      
      <auth-constraint>
         <description>
            Let only managers use this app
         </description>
         <role-name>manager</role-name>
      </auth-constraint>
   </security-constraint>
   
   <security-role>
      <role-name>manager</role-name>
   </security-role>
   
   <login-config>
      <auth-method>BASIC</auth-method>
   </login-config>
   ...
</web-app>

As entradas acima significariam -

  • Qualquer solicitação HTTP GET ou POST para uma URL correspondida por / secure / * estaria sujeita à restrição de segurança.

  • Uma pessoa com a função de gerente recebe acesso aos recursos protegidos.

  • o login-config elemento é usado para descrever o BASIC forma de autenticação.

Se você tentar navegar em qualquer URL, incluindo o /securitydiretório, a seguinte caixa de diálogo será exibida solicitando nome de usuário e senha. Se você fornecer um usuário"admin" e senha "secret", então você terá acesso ao URL correspondido por /secured/* conforme definimos o usuário admin com função de gerente que tem permissão para acessar este recurso.

Autenticação baseada em formulário

Ao usar o método de autenticação FORM, você deve fornecer um formulário de login para solicitar ao usuário um nome de usuário e uma senha. A seguir está um código simples delogin.jsp. Isso ajuda a criar um formulário com o mesmo propósito -

<html>
   <body bgcolor = "#ffffff">
      
      <form method = "POST" action ="j_security_check">
         <table border = "0">
            <tr>
               <td>Login</td>
               <td><input type = "text" name="j_username"></td>
            </tr>
            <tr>
               <td>Password</td>
               <td><input type = "password" name="j_password"></td>
            </tr>
         </table>
         <input type = "submit" value = "Login!">
         
      </form>
      
   </body>
</html>

Aqui você deve se certificar de que o formulário de login deve conter os elementos do formulário chamados j_username e j_password. A ação no<form> tag deve ser j_security_check. POSTdeve ser usado como o método de formulário. Ao mesmo tempo, você terá que modificar o<login-config> tag para especificar o método de autenticação como FORM -

<web-app>
   ...
   <security-constraint>
      <web-resource-collection>
         <web-resource-name>SecuredBookSite</web-resource-name>
         <url-pattern>/secured/*</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
      </web-resource-collection>
      
      <auth-constraint>
         <description>Let only managers use this app</description>
         <role-name>manager</role-name>
      </auth-constraint>
   </security-constraint>
   
   <security-role>
      <role-name>manager</role-name>
   </security-role>
   
   <login-config>
      <auth-method>FORM</auth-method>
      <form-login-config>
         <form-login-page>/login.jsp</form-login-page>
         <form-error-page>/error.jsp</form-error-page>
      </form-login-config>
   </login-config>
   ...
</web-app>

Agora, quando você tenta acessar qualquer recurso com URL /secured/*, ele exibirá o formulário acima solicitando o ID do usuário e a senha. Quando o contêiner vê o "j_security_check", ele usa algum mecanismo interno para autenticar o chamador.

Se o login for bem-sucedido e o chamador estiver autorizado a acessar o recurso seguro, o contêiner usará um ID de sessão para identificar uma sessão de login para o chamador daquele ponto em diante. O contêiner mantém a sessão de login com um cookie contendo o id da sessão. O servidor envia o cookie de volta ao cliente e, desde que o chamador apresente esse cookie com solicitações subsequentes, o contêiner saberá quem é o chamador.

Se o login falhar, o servidor enviará de volta a página identificada pela configuração da página de erro do formulário

Aqui, j_security_checké a ação que os aplicativos que usam o login baseado em formulário devem especificar para o formulário de login. No mesmo formulário, você também deve ter um controle de entrada de texto chamadoj_username e um password input control chamado j_password. Ao ver isso, significa que as informações contidas no formulário serão enviadas para o servidor, que verificará nome e senha. A forma como isso é feito é específica do servidor.

Verifique as implementações de domínio padrão para entender comoj_security_check funciona para contêiner Tomcat ..

Segurança Programática em um Servlet / JSP

o HttpServletRequest objeto fornece os seguintes métodos, que podem ser usados ​​para extrair informações de segurança em tempo de execução -

S.No. Método e Descrição
1

String getAuthType()

o getAuthType() método retorna um objeto String que representa o nome do esquema de autenticação usado para proteger o Servlet.

2

boolean isUserInRole(java.lang.String role)

o isUserInRole() método retorna um valor booleano: verdadeiro se o usuário está na função fornecida ou falso se não estiver.

3

String getProtocol()

o getProtocol()método retorna um objeto String que representa o protocolo que foi usado para enviar a solicitação. Este valor pode ser verificado para determinar se um protocolo seguro foi usado.

4

boolean isSecure()

o isSecure()método retorna um valor booleano que representa se a solicitação foi feita usando HTTPS. Um valor true significa que sim e que a conexão é segura. Um valor false significa que a solicitação não foi.

5

Principle getUserPrinciple()

o getUserPrinciple() método retorna um objeto java.security.Principle que contém o nome do usuário autenticado atual.

Por exemplo, para uma página JavaServer que vincula a páginas para gerentes, você pode ter o seguinte código -

<% if (request.isUserInRole("manager")) { %>
   <a href = "managers/mgrreport.jsp">Manager Report</a>
   <a href = "managers/personnel.jsp">Personnel Records</a>
<% } %>

Ao verificar a função do usuário em um JSP ou servlet, você pode personalizar a página da Web para mostrar ao usuário apenas os itens que ele pode acessar. Se você precisar do nome do usuário conforme inserido no formulário de autenticação, pode ligar para ogetRemoteUser método no objeto de solicitação.