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.

[consultor2017]

Ejercicio 2 (3,5 punts)
2.1 Introducción
El objetivo de este ejercicio es usar el framework XACML para aplicar autorización al acceso a recursos de la aplicación web programada en el ejercicio 1. Básicamente, queremos sustituir JAAS por XACML+sistema de autenticación.
Tomcat no integra XACML por defecto y, por eso, usaremos otro tipo de tecnología
que integre XACML. En este caso, utilizaremos el WSO2 Application Server (como
servlet container) y el WSO2 Identity Server (como servidor de identidad que
autenticará y autorizará a los usuarios). A continuación se muestra una imagen de la arquitectura que tendríamos que construir:

2.2 Especificaciones
Tal como se ha dicho, la aplicación web a proteger será la misma que la requerida en el ejercicio 1, por lo tanto, las especificaciones anteriores en cuanto a usuarios,
módulos, roles y operaciones son las mismas.
Igualmente, el sistema proporcionado 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 para cada módulo sólo se mostrarán las
opciones a las que el usuario 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, debe
mostrar un mensaje indicando que no tiene acceso a dicho módulo.
Las diferencias principales con respecto al ejercicio 1 son las siguientes:

• En lugar de utilizar security-constraints o similar, ahora la aplicación web tendrá
un Filtro (AuthenticationFilter) encargado de evitar que un usuario no
autenticado acceda a páginas y recursos de la aplicación. Este filtro mostrará
una pantalla de login cuando un usuario llegue a la aplicación, y la pareja
login/password introducido se enviará al "Identity Server" para que compruebe
en su base de datos (User Directory) si las credenciales son correctas. Con
este proceso, el usuario quedará autenticado.

• Dado que usamos el User Directory del "Identity Server", ya no necesitamos
utilizar nuestro JAAS LoginModule ni nuestro fichero de shadowed passwords.

• La aplicación web también tendrá un Filtro (EntitlementFilter) diseñado para
capturar cualquier petición sobre un recurso específico protegido. Este Filtro
hará de PEP y básicamente lo que hará será comunicarse con el PDP situado
en el "Identity Server", indicándole la identidad del usuario que quiere acceder
al recurso en particular. El PDP tendrá una serie de políticas XACML definidas
(se habrán registrado en el sistema mediante el PAP también presente en el
"Identity Server") y mediante los atributos específicos del usuario y dichas
políticas decidirá si éste puede acceder al recurso o no.

Como punto de partida, se proporciona junto con este enunciado un manual de
despliegue de una aplicación web sencilla donde hay un recurso (un .jsp) a
proteger utilizando XACML y la tecnología WSO2 (tal y como se muestra en la
arquitectura anterior). Se recomienda tener este ejemplo funcionando correctamente y, entonces, adaptarlo para ofrecer las funcionalidades solicitadas en este ejercicio. En el ejemplo sólo hay un recurso a proteger (protected.jsp) y sólo se trata el acceso al recurso, no se considera la existencia de operaciones dentro de un módulo. Además, la política XACML 3.0 proporcionada simplemente indica que el usuario llamado "admin" puede acceder al recurso llamado "protected.jsp" haciendo una acción "GET".

En consecuencia, para resolver el ejercicio correctamente se debería:
• Adaptar el ejemplo proporcionado para que trabaje con los módulos requeridos
(nóminas, compras y ventas).
• Considerar la existencia de operaciones dentro de cada módulo.
• Proporcionar unas nuevas políticas que consideren los roles de los usuarios
a la hora de decidir el acceso a los recursos, en vez de su identidad.


2.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 (adaptar la aplicación web al entorno WSO2 planteado,
explicación de las políticas XACML3.0 que se han definido, etc.).

◦ Juego de pruebas: Se tiene que mostrar utilizando *capturas de pantalla*
el funcionamiento de la aplicación web para los usuarios Petyr Baelish
(Encargado de compras) y Daenerys Targaryen (Encargada de personal).
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* de la aplicación web (En el WSO2 Application
Server se encuentra en la carpeta \repository\deployment\server\webapps)
• El código fuente de todos los servlets y otras clases que se hayan
implementado. No se evaluarán ejercicios en los cuales no se proporcione el
código fuente
• El .war de la aplicación para poder desplegarla en un WSO2 Application
Server.

• El .xml con las reglas XACML 3.0 que hayáis definido.

• URL necesaria para acceder a la aplicación.

Toda la información anterior se debe comprimir en un archivo ZIP con nombre
“Ejercicio2” 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.

2.4 Corrección (**IMPORTANTE**)
Para verificar el funcionamiento de la práctica, se tomará el .war (o la carpeta entera
de la aplicación web) facilitado en el zip y se copiará directamente dentro de la
carpeta \repository\deployment\server\webapps del WSO2 Application Server del
consultor. En el WSO2 Identity Server del consultor estarán definidos los usuarios
especificados en el enunciado con los passwords y los roles correspondientes. Del zip
también se tomará el .xml con las reglas XACML definidas por el alumno, se importará
y se publicarán en el PDP del WSO2 Identity Server del consultor. 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 2.3 Entrega.

Gracias.

[Profesor_Falken]

Un ejercicio completo.

Que llevas hecho? Donde tienes dudas?


Un saludo

[Xerelo]

Respuesta 1.

La probabilidad de un cero crece por momentos.

[consultor2017]

Muchas gracias por responder,

tengo los siguientes .java:

Archivo módulo login:

import java.io.IOException;
import java.util.Map;

import javax.security.auth.Subject;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.callback.UnsupportedCallbackEx ception;
import javax.security.auth.login.LoginException;
import javax.security.auth.spi.LoginModule;

/**
* Login module that simply matches name and password to perform authentication.
* If successful, set principal to name and credential to "admin".
*
* @author Nicolas Fränkel
* @since 2 avr. 2009
*/
public class PlainLoginModule implements LoginModule {

/** Callback handler to store between initialization and authentication. */
private CallbackHandler handler;

/** Subject to store. */
private Subject subject;

/** Login name. */
private String login;

/**
* This implementation always return false.
*
* @see javax.security.auth.spi.LoginModule#abort()
*/
@Override
public boolean abort() throws LoginException {

return false;
}

/**
* This is where, should the entire authentication process succeeds,
* principal would be set.
*
* @see javax.security.auth.spi.LoginModule#commit()
*/
@Override
public boolean commit() throws LoginException {

try {

PlainUserPrincipal user = new PlainUserPrincipal(login);
PlainRolePrincipal role = new PlainRolePrincipal("tomcat");

subject.getPrincipals().add(user);
subject.getPrincipals().add(role);

return true;

} catch (Exception e) {

throw new LoginException(e.getMessage());
}
}

/**
* This implementation ignores both state and options.
*
* @see javax.security.auth.spi.LoginModule#initialize(jav ax.security.auth.Subject,
* javax.security.auth.callback.CallbackHandler, java.util.Map,
* java.util.Map)
*/
@Override
public void initialize(Subject aSubject, CallbackHandler aCallbackHandler, Map aSharedState, Map aOptions) {

handler = aCallbackHandler;
subject = aSubject;
}

/**
* This method checks whether the name and the password are the same.
*
* @see javax.security.auth.spi.LoginModule#login()
*/
@Override
public boolean login() throws LoginException {

Callback[] callbacks = new Callback[2];
callbacks[0] = new NameCallback("login");
callbacks[1] = new PasswordCallback("password", true);

try {

handler.handle(callbacks);

String name = ((NameCallback) callbacks[0]).getName();
String password = String.valueOf(((PasswordCallback) callbacks[1]).getPassword());

if (!name.equals(password)) {

throw new LoginException("Authentication failed");
}

login = name;

return true;

} catch (IOException e) {

throw new LoginException(e.getMessage());

} catch (UnsupportedCallbackException e) {

throw new LoginException(e.getMessage());
}
}

/**
* Clears subject from principal and credentials.
*
* @see javax.security.auth.spi.LoginModule#logout()
*/
@Override
public boolean logout() throws LoginException {

try {

PlainUserPrincipal user = new PlainUserPrincipal(login);
PlainRolePrincipal role = new PlainRolePrincipal("tomcat");

subject.getPrincipals().remove(user);
subject.getPrincipals().remove(role);

return true;

} catch (Exception e) {

throw new LoginException(e.getMessage());
}
}
}



Archivo Módulo Usuario rol:


import java.security.Principal;

public class PlainRolePrincipal implements Principal {

String roleName;

public PlainRolePrincipal(String name) {
roleName = name;
}
public String getName() {
return roleName;
}

public String toString() {
return ("RolePrincipal: " + roleName);
}

public boolean equals(Object obj) {
if (this == obj) {
return true;
}
if (obj instanceof PlainRolePrincipal) {
PlainRolePrincipal other = (PlainRolePrincipal) obj;
return roleName.equals(other.roleName);
}
return false;
}

public int hashCode() {
return roleName.hashCode();
}
}


Módulo usuario:


import java.security.Principal;

public class PlainUserPrincipal implements Principal {

String UserName;

public PlainUserPrincipal(String name) {
UserName = name;
}
public String getName() {
return UserName;
}

public String toString() {
return ("UserPrincipal: " + UserName);
}

public boolean equals(Object obj) {
if (this == obj) {
return true;
}
if (obj instanceof PlainUserPrincipal) {
PlainUserPrincipal other = (PlainUserPrincipal) obj;
return UserName.equals(other.UserName);
}
return false;
}

public int hashCode() {
return UserName.hashCode();
}
}


Lo requerido es modificarlo de manera tal que permita:

1. tener usuarios predeterminados con claves predeterminadas:

Personal- Cargo- Login- Password
Ned Stark- Gerente- nstark- nstark79
Daenerys Targaryen- Encargado Personal- dtargaryen- dtargaryen79
Tyrion Lannister- Encargado Ventas- tlannister- tlannister79
Petyr Baelish- Encargado Compras- pbaelish- pbaelish79
Ramsay Snow- Mantenimiento- rsnow- rsnow79


2. 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.

Quedo atento a sus comentarios. Muchas gracias.

[Profesor_Falken]

Buenas,

Lo que pones es un copy&paste exacto del código de este señor: http://blog.frankel.ch/custom-loginmodule-in-tomcat

Ni siquiera te has molestado en quitar los comentarios.

Una cosa es pedir ayuda y otra que te hagan los deberes.

Si no puedes aportar nada más que el enunciado de ésta y un código copiado que ni siquiera has intentado entender (si lo hicieras al menos habrías intentado hacer el primer punto), entonces sin duda alguna mereces el 0 que vas a sacar en la práctica.


Un saludo

[consultor2017]

Bueno, gracias por nada de todas maneras.
Que Dios te bendiga.