Sie sind auf Seite 1von 11

Requisitos previos

Conocimientos: Se requieren ciertos conocimientos de Java, JSPs, Servlets i HTML.


Programas: Virtual Box + Debian; Java SE Development Kit (JDK) [preferentmente versin 7];
servlet container Apache Tomcat [preferentment versi 7]; Spring Security, Central
Authentication Service (CAS) [preferentment versi 3.5.2], OpenLDAP.

Ejercicio 1. Crear un directorio de empresa ( 1 punto )


Supongamos una empresa de importacin y distribucin llamada " homeland " . En
este ejercicio hay que crear un directorio utilizando OpenLDAP que almacene los
datos bsicos de trabajadores, proveedores y clientes de esta empresa.

1.1 Especificaciones

Para realizar el ejercicio emplearemos el organigrama de la empresa denominada "


homeland " . Su pgina web o dominio es " homeland.com " .
La empresa tiene los trabajadores siguientes :

Trabajador
(cn)

Actividad
(title)

Identificador de
usuario
(uid)

Password

Ubicacion
(roomNumber)

E-mail
(mail)

Saul
Berenson

Gerent

sberenson

sberenson79

Room1

sberenson@homeland.com

Nicholas
Brody

Cap Personal

nbrody

nbrody79

Room2

nbrody@homeland.com

Carrie
Mathison

Cap Vendes

cmathison

cmathison79

Room3

cmathison@homeland.com

Peter Quinn

Cap Compres

pquinn

pquinn79

Room4

pquinn@homeland.com

Dar Adal

Cap Magatzem

dadal

dadal79

Basement

dadal@homeland.com

La empresa tiene los siguientes clientes:


Cliente
(cn)

Empresa

Actividad
(title)

Identificador
d'usuari
(uid)

Password

direccion

Telfono
(telephoneNumber)

E-mail
(mail)

Andrew
Lockhart

CIA

Cap de
Compres

lockCL

qwerty

Langley,
Virginia, USA

+1 (210) 354-1661

alockhart@cia.gov

Tasneem
Qureshi

ISI

Cap de
Compres

tasneemCL

qwerty

Islamabad
Capital Venue,
Pakistan

+1 (602) 4335533

tqureshi@isi.pk

La empresa tiene los siguientes proveedores:


Proveedor
(cn)

Empresa Actividad Identificador


(title)
d'usuari
(uid)

Password

Direccion

Telfon
(telephoneNumber)

E-mail
(mail)

Andrew
Parker

Mi5

Cap
Comercial

andrewPR

qwerty

Thames
House,
London, UK

+44 1462 480000

andrewPR@mi5.uk

Tamir Pardo

Mossad

Cap
Comercial

tamirPR

qwerty

Tel Aviv, Israel

+1 819-623-7999

tamirPR@mossad.il

La estructura del empujada tiene los siguientes departamentos a considerar :


Gerencia, Ventas , Compras , Recursos Humanos y Almacn ; y cada trabajador est
a cargo de un departamento. Esto debe quedar eflejado en el directorio .

1.2 Configuracin del servidor OpenLDAP en el entorno


de trabajo de la asignatura ( Virtual Box + Debian )
Primero configuraremos un servidor OpenLDAP considerando que el dominio de la
empresa se " homeland.com " .
Se recomienda seguir el punto 6.1 "Instalacin del OpenLDAP " que aparece en la
Wiki de la asignatura para instalar y configurar el servidor OpenLDAP en una
Debian. Tambin se recomienda el punto 6.2 " rdenes bsicas " para familiarizarse
con los comandos bsicos de OpenLDAP . El punto 6.3 "Instalacin phpldapadmin "
no es relevante para el ejercicio .
Para facilitar el proceso de correccin , utilice la contrasea " admin " en el servidor
OpenLDAP esplegado , tal y como se indica en la Wiki.

1.3 Crear y cargar la estructura del directorio ( 0,25 puntos )


A continuacin se muestra a alto nivel la estructura del directorio que se quiere
implementar mediante OpenLDAP

Puntos a destacar :
Usamos " uid " para construir el " dn " de cada persona de la organizacin.

Agrupamos todos los trabajadores dentro de una organizational unido general.


Esto nos ser til para la Exercici2 de este examen , pero tambin implica que
tendremos que indicar por medio de un atributo dentro de cada instancia de
trabajador a qu departamento pertenece.
En cada departamento se indica que hay un encargado . Enlazamos cada "
encargado de departamento " con la persona que se encarga de esta
responsabilidad.

Algunos recursos que pueden ser tiles para entender la estructura planteada y
cmo implementarla :

http://www.ldapman.org/articles/intro_to_ldap.html
http://www.zytrax.com/books/ldap/ch5/index.html#step1-dit
http://www.zytrax.com/books/ldap/apa/structure.html
Crea un fichero LDIF que permita crear las organizational units (OU) necesarias para
construir la estructura de directorio requerido. El archivo debe tener el nombre
siguiente:
Ex1_3.ldif
Proporciona un script que cargue el archivo .ldif anterior. El script debe tener el
nombre siguiente:
Ex1_3.sh

1.4 Cargar datos (0,75 puntos)


En esta seccin vamos a crear los usuarios de la empresa y llenaremos la estructura
creada en el punto anterior. Se utilizarn los objectClass y attributes adecuadas en
cada caso. Idealmente, los passwords no deben almacenarse en claro el directorio,
tenemos que guardar su hash.
** NOTA **: si los passwords se guardan en claro el apartado se valorar con un
mximo de 0,25 puntos.
Crea un fichero LDIF que contenga las sentencias para aadir los trabajadores de la
empresa en el directorio junto con la informacin bsica proporcionada. El archivo
debe tener el nombre siguiente:
Ex1_4_1.ldif
Crea un fichero LDIF que contenga las sentencias para aadir los clientes y
proveedores de la empresa en el directorio junto con la informacin bsica
proporcionada. El archivo debe tener el nombre siguiente:
Ex1_4_2.ldif
Crea un fichero LDIF que contenga las sentencias para crear los encargados de
departamento y enlazarlos con los trabajadores correspondientes. El archivo debe
tener el nombre siguiente:
Ex1_4_3.ldif

Proporciona un script que cargue los archivos .ldif anteriores. El script debe tener el
nombre siguiente:
Ex1_4.sh

1.5 Entrega ejercicio


La entrega de este ejercicio debe incluir los siguientes archivos:
Archivos LDIF: a continuacin se detallan todos los archivos a entregar y se han
indicado a lo largo del enunciado del ejercicio.

Ex1_3.ldif
Ex1_4_1.ldif
Ex1_4_2.ldif
Ex1_4_3.ldif

Scripts: debe adjuntar todos los archivos con los pedidos especificado a lo largo
del enunciado del ejercicio.
Ex1_3.sh
Ex1_4.sh
Toda la informacin anterior se comprimir en un archivo ZIP llamado "ejercicio1" el
cual se comprimir dentro del ZIP principal que debe entregarse mediante la
actividad "Examen Virtual" que se encuentra en "Entrega y registro de AC ".

1.6 Correccin (** IMPORTANTE **)


Para verificar el funcionamiento del ejercicio, se realizar una instalacin de
OpenLDAP en el entorno de trabajo de la asignatura (Virtual Box + Debian)
siguiendo los pasos de la Wiki (el dominio ser "homeland.com"). A continuacin, se
ejecutarn los archivos LDIF y los scripts facilidades para verificar los diversos
puntos solicitados. Asegrate de que este proceso se puede seguir
convenientemente en el entorno fijado y que se respetan los nombres de los
ficheros (LDIF y scripts). El objetivo es evitar problemas en el proceso de
evaluacin.

Ejercicio 2. Crear una aplicacin Web con


autenticacin va servidor CAS single sign-on. (7
puntos)
2.1 Introduccin
El objetivo de este ejercicio es desarrollar una aplicacin Web para la empresa
"homeland.com" introducida en el ejercicio anterior. Esta aplicacin permitir a los
trabajadores realizar ciertas operaciones segn los roles asignados. Estas
operaciones no se deben implementar, es decir, no es necesario desarrollar un
mdulo para hacer facturas de verdad. Slo habr que ver que las operaciones de
este mdulo se pueden realizar en funcin del rol de cada usuario.
La autenticacin de los usuarios se realizar utilizando un servidor CAS single signon. La etapa de autorizacin necesaria para limitar el acceso a ciertos recursos
segn los roles de los usuarios se implementar a nivel local utilizando el
framework Spring Security.
Los trabajadores de la empresa y sus datos ya se han presentado en el ejercicio1 de
este examen.
La aplicacin a desarrollar debe tratar los siguientes mdulos: Ventas , Compras y
Nminas. Cada mdulo engloba una serie de operaciones.

Los roles necesarios para gestionar la aplicacin son los siguientes

Rol

Descripcion

Gerent (G)

Autoritza las compras.

Responsable Compras
(CC)

gestion de compras y proveedores.

Responsable VEntas
(CV )

Crear y consultar factures y presupuestos. Gestin de clientes.

Responsable Personal
(CP)

Gestin de las nominas de los trabajadores.

Treballador (T)

Consultar dades i nmines prpies.

La asignacin de roles a cada trabajador es la siguiente:

Personal de la empresa

Actividad

Rol/s

Saul Berenson

Gerente

Nicholas Brody

Responsable Personal

CP, T

Carrie Mathison

Responsable VEntas

CV, T

Peter Quinn

Responsable Compras

CC, T

Dar Adal

Responsable Magatzem

G, CC, CV, CP, T

En la siguiente tabla se muestras las diferentes operaciones a tratar dentro de cada


mdulo y los roles necesarios para ejecutarlas :
Mdulo
Ventes
Mdulo
Compres
Mdulo
Nmines

Operacion

Rols

Afegir client

CV

Consultar cliente

CV

Crear presupuesto

CV

Operacion

Rols

Aadir proveedir

CC

Realitzar compra

CC

Operacion

Rols

Aadir trabajador

CP

Consultar datos trabajador

CP

Consultar datos propios

Mdulo
Ventes
Mdulo
Compres
Mdulo
Nmines

Operacion

Rols

Consultar presupuestos

CV

Crear factura

CV

Consultar facturas

CV

Operacion

Rols

Autorizar compra

Consultar compras

CC

Operacion

Rols

Crear nmina

CP

Consultar nminas

CP

Consultar nminas prpias

La aplicacin Web a desarrollar debe permitir que slo los usuarios registrados
puedan acceder a la aplicacin con su login y contrasea. A partir de este momento
deben visualizar un men con todos los mdulos mencionados ( nminas, compras
y ventas ) , pero para cada mdulo , el usuario slo podr acceder a las operaciones
para las que est autorizado segn los roles a los que pertenece . Idealmente, cada
operacin corresponder a un archivo JSP . Si un usuario intenta acceder a una
operacin ( ie, archivo JSP ) en la que no est autorizado, el sistema tiene que
evitarlo y mostrar un aviso.
El men principal tambin mostrar al usuario la posibilidad de hacer log - out del
sistema

2.2 Configuracin inicial


Como punto de partida, se proporciona junto con este enunciado un manual de
desarrollo de un servidor CAS single sign-on y una aplicacin web sencilla
CASificada donde se utiliza Spring Security para controlar el acceso a un
recurso (.jsp).
Tal y como se dice en el manual, la aplicacin web CASificada de ejemplo est
configurada para trabajar nicamente con un usuario llamado "user". Este usuario
tiene un rol asignado que no le permite acceder a la carpeta "extreme" donde hay
otro recurso protegido. Un primer paso para familiarizarse con el funcionamiento de
la aplicacin de ejemplo sera crear un nuevo usuario con los roles necesarios para
acceder a los dos recursos protegidos.

2.3 Modificaciones requeridas para completar el ejercicio


2.3.1 Modificaciones para la aplicacin web (2 puntos)
1) Como ya se ha indicado anteriormente, se debe desarrollar una aplicacin que
trabaje con tres mdulos (Ventas, Compras y Nminas) y dentro de cada mdulo se

deben considerar las operaciones indicadas. La solucin ideal sera tener un JSP
para operacin y controlar el acceso a todas las operaciones segn los roles
especificados mediante Spring Security. Tiene que garantizarse que un usuario slo
pueda acceder a las operaciones correspondientes a sus roles.
2) Un usuario autenticado podr solicitar el cierre de su sesin desde el men de la
aplicacin web. Cerrar la sesin implica hacer un log-out en el servidor CAS.

2.3.2 Utilizacin de CAS + OpenLDAP para realizar la


autenticacin (2,5 puntos)
El servidor CAS se conectar a un servidor OpenLDAP para consultar las
credenciales de los usuarios y realizar su autenticacin.
El directorio LDAP que se utilizar es el mismo que se ha implementado en el
ejercicio1.
Para que el servidor CAS pueda interactuar con un servidor OpenLDAP ser
necesario aadir ciertas libreras adicionales (.jar) en la carpeta \ lib del servidor
CAS (... \ caso-server-webapp-3.5.2 \ WEB-INF \ lib ) y modificar la configuracin
donde sea necesario.

** NOTA **:

Si por cualquier razn, el alumno no puede realizar esta


modificacin (por ejemplo, no ha hecho el Ejercicio-1), deber entregar una solucin
donde el sistema de autenticacin por defecto del servidor CAS (NetID ==
Contrasea) se sustituya por la utilizacin de un archivo de texto donde se
encontrarn los usuarios y el hash de sus contraseas. Concretamente, se pide
utilizar File System Authentication Handler incluido dentro del Generic
Authentication Handler proporcionado por JA-SIG CAS y la clase
org.jasig.cas.authentication.handler.DefaultPasswordEncoder. Junto con este
enunciado se proporciona la librera caso-server-support-generic-3.5.2.jar necesaria
(a situarse en la carpeta \ lib del servidor CAS). El fichero con las contraseas debe
situarse dentro de la carpeta del servidor CAS (... \ caso-server-webapp-3.5.2). Esta
solucin alternativa se valorar con un mximo de 0,5 puntos.
Otra alternativa sera crear un Authentication Handler propio que permita trabajar
con hashed passwords con "saltos". Para hacer esto, se debera implementar una
clase nueva que extienda la clase AbstractUsernamePasswordAuthenticationHandler
y pueda trabajar con estos requisitos. Ms informacin al respecto se puede
encontrar en el siguiente link:
https://wiki.jasig.org/display/CAS/How+To+Write+an+AuthenticationHandler

Esta solucin alternativa se valorar con un mximo de 1,5 puntos.

2.3.3 Utilizacin de SSL (y certificados) para proteger * todas


* las comunicaciones (2 puntos)
Utilizaremos SSL (y certificados) para securizar todas las comunicaciones entre el
browser, la aplicacin CASificada, el servidor CAS y el servidor OpenLDAP. Algunos
recursos web que pueden ser tiles son:
https://wiki.jasig.org/display/CASUM/Demo
http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html

https://wiki.jasig.org/display/CASC/JA-SIG+Java+Client+Simple+WebApp+Sample

2.4 Entrega
La entrega del ejercicio debe incluir los siguientes puntos:
Documento en PDF que contenga:
Explicacin de los pasos seguidos para realizar las diferentes modificaciones
(utilizacin de CAS + OpenLDAP o la alternativa elegida, conexiones securizadas
con SSL,, etc.).
Juego de pruebas: Se debe mostrar con * capturas de pantalla * el funcionamiento
de la aplicacin web para los usuarios Carrie Mathison (Jefe de Ventas) y Peter
Quinn (Jefe de Compras). Se debe poder seguir el proceso desde la pgina inicial de
login, hasta la pantalla (o pantallas) donde se muestran las diversas operaciones
que puede realizar el usuario en cuestin.
La carpeta * entera * del apache-tomcat correspondiente a la aplicacin
CASificada con todos los archivos necesarios para ejecutar la aplicacin.
La carpeta * entera * del apache-tomcat correspondiente al servidor CAS con
todos los archivos necesarios para ejecutar el servidor.
El cdigo fuente de todas las clases que se hayan implementado. No se evaluarn
ejercicios donde no se proporcione el cdigo fuente.
Carpeta con los certificados necesarios para securizar el sistema con SSL. Aqu se
puede incluir cualquier archivo que el estudiante crea necesario para lograr esto.
Esto tambin incluye la configuracin bajo SSL del servidor OpenLDAP. Los pasos
necesarios para realizar las diferentes configuraciones tienen que detallarse en el
PDF pedido.
URL necesaria para acceder a la aplicacin.
Toda la informacin anterior se comprimir en un archivo ZIP llamado "Exercici2" el
cual se comprimir dentro del ZIP principal que debe entregarse mediante la
actividad "Examen Virtual" que se encuentra en "Entrega y registro de AC ".
** NOTA ** : El PDF que se pide, aporta un mximo de 0,5 puntos en la nota final. Su
valoracin depender de que cubra todos los puntos solicitados , del nivel de detalle
en las explicaciones y su calidad general.
Dado que el tamao de las carpetas apache-tomcat puede ser significativa, se
recomienda eliminar todas aquellas subcarpetas y / o ficheros irrelevantes para la
correcta ejecucin del ejercicio (por ejemplo: webapps \ docs, webapps \ examples \
servlets, etc.) .

2.5 Correccin (** IMPORTANTE **)


Para verificar el funcionamiento del ejercicio, se tomarn las dos carpetas apachetomcat facilitados y se pondrn a la carpeta / opt del entorno de trabajo de la
asignatura (Virtual Box + Debian). En caso de ser necesario, se aplicarn las
indicaciones facilitadas por el alumno al PDF entregado (por ejemplo respecto al
posicionamiento de certificados, modificaciones al OpenLDAP, etc). Finalmente, se
arrancarn los Tomcats y se introducir en el browser la URL de acceso a la
aplicacin facilitada.
Si por favor, antes de hacer la entrega, siga usted mismo este proceso y asegrese
de que todo se ejecuta convenientemente en el entorno fijado para evitar
problemas con el proceso de evaluacin. Compruebe tambin que su entrega
contiene todos los puntos indicados en la seccin 2.4 Entrega.

Ejercicio 3. Encontrar debilidades (2 puntos)


Supone que una empresa est dividida en diferentes zonas (laboratorios, almacn,
oficinas, etc ...). Cada miembro del personal tiene una tarjeta RFID (Radio-frequency
identification) que contiene un identificador numrico nico (ID) de 128 bits que
est asociado a las zonas donde puede acceder y una clave secreta K de 128 bits
compartida por todos los lectores y tarjetas de la empresa. Los trabajadores no
pueden acceder a los contenidos almacenados en sus tarjetas (por tanto, no
conocen K o su ID particular).
El protocolo de autenticacin se describe a continuacin:
El trabajador acerca su tarjeta al lector para acceder a la zona Z.
El lector detecta que hay una tarjeta a su rango.
La tarjeta enva al lector un entero F de 128 bits y un entero N de 4 bits. Ambos
obtenidos de forma aleatoria.
El lector recibe F y N, calcula su respuesta R1, y la enva a la tarjeta:
R1 = (F ^ J) PRG (N || K)
Donde:
o
o
o
o
o

J es un entero de 128 bits obtenido de forma aleatoria por el lector.


"^" corresponde a la operacin AND.
"" corresponde a la operacin OR exclusivo (XOR).
PRG es un pseudorandom generator seguro.
"||" es el operador para concatenar dos cadenas.

La tarjeta recibe R1, obtiene (F ^ J), calcula la respuesta R2, y la enva al lector:
R2 = (F ^ J) ID
El lector obtiene ID del mensaje R2, y enva al sistema central Z y ID.
El sistema central realiza las siguientes operaciones:
o Bsqueda ID en su base de datos.
o Si ID no existe, o no tiene acceso a la zona Z, devuelve un "acceso
denegado" al lector. Si el sistema detecta 3 intentos de acceso denegados
consecutivos al mismo lector, salta una alarma y el personal de seguridad
se personifica en la zona problemtica.
o Si ID tiene acceso a la zona Z devuelve un "acceso aceptado".
El lector permite que el usuario acceda en funcin de la respuesta del sistema
central.

Preguntas:
a) Supongamos un trabajador con una tarjeta que contiene un ID que * no * le da
acceso a una determinada zona Z1. Crees que este trabajador puede hacer algn
ataque que le permita engaar al lector / sistema central y as poder entrar en la
zona protegida? Si crees que s, explica cmo sera este ataque. (1 punto)

** Importante **: se detallarn * exactamente * qu pasos seguira el


atacante, qu mensajes construira para engaar al lector, como
manipulara los diferentes mensajes, etc.
Consideraciones: supongamos que este atacante puede capturar las
comunicaciones entre el lector y las tarjetas de los diferentes trabajadores que
intentan acceder a la zona (esto incluye: trabajadores que s tienen acceso, l
mismo, etc). El atacante tambin puede construir los mensajes que desee y
enviarlos al lector ya su propia tarjeta (no puede enviar nada a las tarjetas de los
otros trabajadores). El atacante no tiene acceso a los contenidos de su tarjeta o del
lector

b ) Supongamos que se modifica el protocolo de forma que el entero aleatorio N de


4 bits lo genera directamente el lector. De este modo, el mensaje R1 se genera as :
R1 = N || ( F ^ J ) PRG ( N || K )

Esta modificacin evita poder engaar al lector / sistema central ?, si todava es


vulnerable , como sera el ataque ? ( 1 punto )

Entrega ( ** IMPORTANTE ** )
Este es un ejercicio terico. Las soluciones a los dos
apartados de este ejercicio se pueden aportar
directamente al espacio marcado debajo de cada
pregunta ; por esta razn, se entrega el archivo Word de
este enunciado.
Para realizar la entrega simplemente debe responder los
dos apartados tal como se ha indicado, crear un archivo
PDF llamado " Exercici3 " y comprimir este PDF dentro
del ZIP principal que debe entregarse mediante la
actividad " Examen Virtual" que se encuentra en el "
Entrega y registro de AC " .

Das könnte Ihnen auch gefallen