Section 5: Web Application Security
 

5.1 Based on the servlet specification, compare and contrast the following security mechanisms: (a) authentication, (b) authorization, (c) data integrity, and (d) confidentiality.

authentication: El proceso de autenticación es el encargado de determinar que el interesado en acceder los recursos es realmente quien dice que es. Lo más comun es hacer que el usuario/aplicación envie un password que lo identifica.

authorization: Es el proceso por el cual se restringe el acceso a ciertos recursos a un conjunto de clientes. En realidad, lo que se define es un conjunto de roles que pueden acceder a ciertos recursos y se asocia cada usuario a uno o mas roles.

data integrity: Es el proceso que 'asegura' que los datos que se reciben (tanto el cliente como el servidor) no han sido corrompidos. Generalmente se usan algoritmos de encriptación para lograr esto.

confidentiality: Es el proceso que intenta asegurar que solamente los clientes autorizados reciban la información. La manera de lograr esto puede ser a través del uso de claves públicas/privadas.

5.2 In the deployment descriptor, declare a security constraint, a Web resource, the transport guarantee, the login configuration, and a security role.

Este punto describe los mecanismos de seguridad que se pueden establecer 'declarativamente', es decir desde el deployment descriptor.

Elemento <security-constraint> - Este elemento sirve para limitar el acceso a un conjunto de recursos. Se limitan los métodos que lo pueden acceder, los roles y como se enviarán los datos al cliente. El formato es el siguiente:

<security-constraint>

   <web-resource-collection> <!-- Aca se define un nombre para el constraint, los recursos y los métodos http -->

       <description>

       <web-resource-name> <!-- se le da un nombre al constraint -->

       <url-pattern>

       <http-method> <!--el método a restringir (GET, PUT, etc.) -->

   </web-resource-collection>

   <auth-constraint>

          <role-name><!-- El tag vacio indica que se restringe a cualquier cliente, * permite el acceso de todos los roles definidos en el deployment descriptor. Sino, ponemos 1 o más <role-name>, que deben estar definidos mas abajo en <security-role> -->

    <user-data-constraint>

         <transport-garanty> <!-- INTEGRAL declara que se debe asegurar la integridad de los datos  CONFIDENTIAL que se debe asegurar la confidencialidad de los datos -->

</security-constraint>

Elemento <login-config> - cuando ponemos este tag, el servidor envia al browser un código de retorno que indica que tenemos que loguearnos para acceder a la aplicación. El browser entiende este código y muestra una ventanita para que introduzcamos el usuario y password.

<login-config>

    <auth-method>BASIC</auth-method>

</login-config>

o

<login-config>

    <auth-method>FORM</auth-method>

    <realm-name>Area de autenticación</realm-name>

    <form-login-config>

          <form-login-page>/autenticacion/autenticacion.jsp</form-login-page>

          <form-login-error>/autenticacion/autenticacion.jsp</form-login-error>

</login-config>

** Aunque parezca raro, ninguno de los 3 elementos es mandatorio.

Elemento <security-role> - podemos poner estos elementos por cada uno de los usuarios habilitados para entrar en la aplicación. El formato es el siguiente (pueden existir todas las entradas que sean necesarias):

<security-role>

     <role-name></role-name>

</security-role>

Elemento <security-role-ref> - Este elemento permite relacionar un role-name definido programaticamente (en el servlet) con uno que existe en el deployment descriptor. El formato es el siguiente:

<security-role-ref>

     <role-name></role-name>

     <role-link></role-link>

</security-role-ref>

** Este elemento se encuentra dentro del elemento <servlet> del deployment descriptor.

5.3 Compare and contrast the authentication types (BASIC, DIGEST, FORM, and CLIENT-CERT); describe how the type works; and given a scenario, select an appropriate type.

BASIC (SRV.12.5.1): Este es el método mas simple, pero el más inseguro. Cuando usamos este tipo de autenticación, se abre una ventana en el browser del cliente para que este ingrese el usuario y el password. El password se envia al servidor codificado a través de un proceso llamando Base64.

DIGEST (SRV.12.5.2): La autenticación también es hecha utilizando usuario y password, pero el password es enviado encriptado de una forma mucho más segura (por ejemplo, utilizando HTTPS client authentication)

FORM (SRV.12.5.3): Este método es similar a BASIC, pero utiliza un form provisto por el programador. Este form tiene que cumplir los siguiente requisitos:

1. El action debe ser j_security_check

2. El campo de usuario debe llamarse j_username

3. el nombre del password debe llamarse j_password

** El método Base64 es como si fuera plain text. No es considerado un método de encriptación (porque existen programitas en la web que podemos bajar para decodificar el contenido).

CLIENT-CERT (SRV.12.5.4): en este método se usan certificados digitales. El browser debe tener instalado el certificado para que la comunicación se pueda establecer.