Sobre este proyecto
it-programming / web-development
Abierto
Criterios de valoración:
Es necesario explicar los pasos que se han realizado para desarrollar la solución.
En la memoria se valorará la claridad de la información aportada, el estilo comunicativo empleado, y la capacidad de síntesis.
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.
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.
Es necesario explicar los pasos que se han realizado para desarrollar la solución.
En la memoria se valorará la claridad de la información aportada, el estilo comunicativo empleado, y la capacidad de síntesis.
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.
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.
Categoría Programación y Tecnología
Subcategoría Programación Web
¿Es un proyecto o una posición? No lo sé aún
Actualmente tengo Tengo las especificaciones
Disponibilidad requerida Según se necesite
Experiencia en este tipo de proyectos No (No he administrado este tipo de proyectos anteriormente)
Integraciones de API Otros (Otras APIs)
Roles necesarios Programador
Plazo de Entrega: 28 Marzo, 2015
Habilidades necesarias