Consulta Parte 1

[consultor2017]

Cordial saludo, acudo a su amable ayuda, por si de pronto pueden ayudarme con el siguiente ejercicio (posiblemente se vea un poco raro, pero es porque no pude encontrar opción para adjuntar el documento). De antemano muchas gracias por la ayuda que puedan brindarme, ya que estoy muy enredado con el tema, y no sé por donde iniciar, adicional a que no tengo mucha experiencia en programación:

1.1 Introducción
El objetivo de este ejercicio es desarrollar una aplicación Web donde se apliquen los conceptos que se han visto en el primer módulo sobre los "Shadowed Passwords" y el control de acceso basado en roles (RBAC), junto con el funcionamiento básico de Java Authentication and Authorization Services (JAAS) que se han explicado en el segundo módulo.
Nos basaremos en una supuesta empresa de importación y distribución para hacer
una aplicación que autentique los usuarios y les permita hacer unas acciones u otras en función de su rol. Estas acciones no se deben implementar, es decir, no es necesario desarrollar un módulo para hacer facturas de verdad. Sólo habrá que
mostrar que las funciones de este módulo se pueden realizar en función del rol de
cada usuario.
Cabe destacar que la aplicación que desarrollaremos en este ejercicio la usaremos
también el ejercicio 2 de este mismo enunciado y en la futura PRAC2.

1.2 Especificaciones
Supondremos que una empresa que se dedica a la importación y distribución de
productos tiene el personal siguiente:

La empresa dispone de una aplicación que tiene los módulos siguientes: Ventas,
Compras y Nóminas.
Los roles necesarios para gestionar dicha aplicación son los siguientes:

La asignación de roles a cada trabajador es la siguiente:

Los roles necesarios para ejecutar las diferentes operaciones de cada módulo son los siguientes:

La aplicación Web a desarrollar debe permitir que sólo los usuarios registrados
puedan acceder a la aplicación con su login y contraseña. A partir de este
momento tienen que visualizar un menú con todos los módulos mencionados
(nóminas, compras y ventas), pero por cada módulo sólo se mostrarán las opciones a las que tiene acceso (según los roles a los que pertenece). Si hay un módulo al que el usuario no tiene acceso a ninguna funcionalidad, se debe mostrar un mensaje indicando que no tiene acceso dicho módulo.
A continuación se dan algunas indicaciones para el desarrollo de la aplicación:

• La aplicación Web debe usar el servidor Web Apache-Tomcat y Java
Authentication and Authorization Services (JAAS) para autenticar usuarios y
autorizarlos a realizar operaciones según los roles asignados. Encontraréis
indicaciones sobre cómo configurar Tomcat para utilizar JAAS en los materiales de la asignatura y en los documentos facilitados por el consultor.

• La interacción con el usuario se resolverá usando páginas JSP y HTML. Se
puede utilizar como base los ficheros de ejemplo que vienen con el Apache-
Tomcat. Particularmente los de la carpeta "examples\jsp\security\protected",
dentro del "webapps".
• La página inicial debe mostrar dos campos de texto, uno para el identificador
de usuario (login) y el otro para la contraseña (password).

• Un usuario autenticado podrá solicitar el cierre de su sesión. En este caso la
aplicación debe volver a la pantalla inicial.

• El acceso a las distintas páginas web necesarias para realizar las operaciones
tiene que restringirse mediante los "security-constraint" del web.xml.

◦ La solución mínima aceptable sería implementar un JSP diferente para
cada módulo y utilizar los "security-constraints" para controlar el acceso a
cada uno de estos módulos/JSPs según los roles del usuario. Una vez
dentro del módulo/JSP deseado, se podrían mostrar las operaciones
disponibles para el usuario realizando un control en el mismo JSP.

• La gestión de las contraseñas se tiene que realizar siguiendo un método
similar a los "Shadowed Passwords".

◦ Una solución válida sería utilizar un archivo de texto que contenga el "salt"
y el "hashed password" (por ejemplo, utilizando SHA1) correspondiente a
cada usuario. Es importante que cada usuario tenga un "salt" diferente.

• La persistencia de los datos se realizará únicamente mediante archivos
(*no* se debe utilizar mysql o similar, sólo archivos). Hay que crear una
clase que aísle el resto de la aplicación del acceso a fichero. Por ejemplo, si
queremos recuperar los datos de un usuario, se pedirá a esta clase la
información de un usuario mediante un método.

• Para gestionar qué funciones corresponden a cada rol, se puede guardar en un
fichero las distintas relaciones.

1.3 Entrega
La entrega de la práctica debe incluir los siguientes puntos:
• Documento en PDF que contenga:

◦ Explicación de los pasos que se han seguido para resolver cada punto
solicitado (integración y utilización de JAAS, gestión de contraseñas,
utilización de security-constraints, etc.).

◦ Juego de pruebas: Se tiene que mostrar utilizando *capturas de pantalla*
el funcionamiento de la aplicación web para los usuarios Tyrion Lannister
(Encargado de ventas) y Ramsay Snow (Mantenimiento). Se tiene que
poder seguir el proceso desde la página inicial de login, hasta la pantalla (o
pantallas) donde se muestren las diversas operaciones que puede realizar
el usuario en cuestión.

• Vuestra carpeta *entera* del apache-tomcat (en Debian se encuentra dentro
del directorio /opt) con todos los ficheros necesarios para ejecutar la aplicación
• El código fuente de todas las clases que se hayan implementado. No se
evaluarán ejercicios en los cuales no se proporcione el código fuente

• Un listado de los ficheros .xml, .java, .jsp y .html utilizados en la aplicación,
indicando su localización.

• URL necesaria para acceder a la aplicación.
Toda la información anterior se debe comprimir en un archivo ZIP con nombre
“Ejercicio1” el cual se comprimirá dentro del ZIP principal que debe entregarse
mediante el enlace de "Entrega y registro de AC".

NOTA: El PDF que se pide, aportará un máximo de 0,5 puntos a la nota final. Su
valoración dependerá de que cubra todos los puntos requeridos, del nivel de detalle de las explicaciones y de su calidad en general.
Dado que el tamaño de la carpeta apache-tomcat puede ser significativo, se
recomienda eliminar todas aquellas subcarpetas y/o archivos irrelevantes para la
correcta ejecución de la práctica (ejemplo: webapps\docs, webapps\examples\servlets, etc).

1.4 Proceso de corrección (*Importante!*)
Para verificar el funcionamiento de la práctica, se tomará la carpeta apache-tomcat
facilitada en el ZIP y se copiará directamente dentro de la carpeta /opt del entorno de trabajo del consultor (Virtual Box + Debian). A continuación, se re-compilarán los archivos .java que se hayan proporcionado (para facilitar la corrección se recomienda indicar claramente su localización y proporcionar un pequeño script que compile dichos archivos) y se ejecutarán el script startup.sh. Finalmente, se introducirá en el browser la URL de acceso a la aplicación facilitada.
Por favor, antes de hacer la entrega, seguid vosotros mismos este proceso y
aseguraos que todo se ejecuta convenientemente en el entorno fijado para evitar
problemas en el proceso de evaluación. Comprobad también que vuestra entrega
contiene todos los puntos indicados en la sección 1.3 Entrega.

Gracias.