Identidad Digital

DOCUMENTO ANEXO A LOS ARCHIVOS DE APLICACIÓN Y JUEGOS DE PRUEBAS
Francisco José Giner Ayguadé

MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC
IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE
0.- Aspectos introductorios y de configuración previa.

Sin pretender ser muy exhaustivo, creo interesante partir de unos conceptos gráficos
introductorios con el fin de contextualizar el trabajo que se va a llevar a cabo. Cabe significar
que para usar CAS y Spring Security se ha considerado la versión 4.0.0 del Central
Authentication Service (CAS) con la siguiente documentación de soporte:
https://apereo.github.io/cas/4.0.x/installation/Configuring-Authentication-Components.html
La arquitectura a construir es la que se desprende del siguiente esquema:
El diagrama siguiente muestra el acceso a un recurso protegido mediante CAS y Spring

Security:
2 Francisco José Giner Ayguadé

1.- Creación de un directorio de empresa usando OpenLDAP.

El servidor OpenLDAP está disponible en el paquete slapd por tanto, lo
instalaremos utilizando apt-get. También nos conviene instalar el paquete ldap-utils que
contiene utilidades adicionales. Desde consola:
apt-get install slapd ldap-utils

y se nos solicita la contraseña del administrador, sumininistrándole “admin”.
Posteriormente nos pide que confirmemos la contraseña:
Los archivos de configuración del servidor LDAP se almacenan en la carpeta

/etc/ldap/. En lugar de editar manualmente dichos archivos, es mejor lanzar el asistente de
configuración de slapd. Para ello debemos ejecutar el siguiente comando:
dpkg-reconfigure-slapd
Lo primero que nos pregunta el asistente es si deseamos omitir la configuración del

servidor LDAP y obviamente responderemos que no, ya que precisamente lo que queremos es
configurar el servidor LDAP.

Después nos preguntará si queremos que se elimine la base de datos cuando quitemos
slapd. Para evitar confusiones con bases de datos anteriores, lo mejor es responder Sí.
Al solicitarnos el DNS domain name el facilitamos gameofthron.es y posteriormente al
solicitarnos el nombre de la organización tecleamos gameofthron.
Tras introducir y confirmar el password e introducir el tipo de base de datos habremos
concluído la configuración inicial del servidor LDAP, que al igual que todos los servicios en
Debian, dispone de un script de arranque y parada en la carpeta /etc/init.d
// Arrancar o reiniciar el servidor LDAP
sudo /etc/init.d/slapd restart
// Parar el servidor LDAP

sudo /etc/init.d/slapd stop
Para comenzar creamos el archivo .ldif que nos permite crear las “organizational units”
(ou) necesarias para construir la estructura del directorio que se nos solicita:

El script que carga el fichero Ex1_3.ldif anterior es Ex1_3.sh
El comando slapadd necesita ejecutarse con privilegios, por tanto, se han elevado para
ejecutar los scripts que lo contienen. En el script se comprueba si el proceso de LDAP se está
ejecutando y se finaliza en el caso de ser así. Posteriormente se introducen los datos al LDAP
con slapadd –c –v –l Ex1_3.ldif
A continuación se procede a crear el archivo .ldif que contiene las sentencias para añadir
a los trabajadores de la empresa al directorio junto con la información proporcionada en el
enunciado. En este caso va a ser necesario almacenar los passwords cifrados en el interior de
LDAP, por lo que, dado que esta estructura va a usarse posteriormente elijo con el criterio de
máxima seguridad el algoritmo SSHA, que es una versión de SHA con salt: “This is the salted
version of the SHA scheme. It is believed to be the most secure password storage scheme
supported by slapd.” (https://www.openldap.org/doc/admin24/security.html).
Para obtener el password cifrado y proporcionárselo al archivo .ldif se usa el comando
slappasswd –h {SSHA} –s password

Quedando el fichero Ex1_4_1.ldif con los trabajadores como sigue:

Se procede de forma análoga en el archivo que contiene las sentencias para

añadir los clientes y proveedores y se nombra Ex1_4_2.ldif

Finalmente se crea el fichero .ldif que contiene las sentencias para crear los
encargados de departamento y enlazarlos con los trabajadores correspondientes y se nombra
Ex1_4_3.ldif
Y con el fin de cargar los archivos Ex_1_4_x.ldif, se proporciona una script cuyo
funcionamiento interno es similar al explicado con anterioridad.
A continuación adjunto pantalla del resultado de la ejecución.

Una vez cargados los datos, podemos usar la herramienta JXplorer

(http://jxplorer.org) que es un navegador y editor de LDAP multiplataforma. Se trata de un cliente
LDAP de propósito general compatible con los estándares que se puede usar para buscar, leer,
y editar cualquier directorio LDAP estándar, o cualquier servicio de directorio con una interfaz
LDAP o DSML. Nosotros lo podemos usar para verificar tanto la estructura como los datos.
Esta sería la pantalla donde se introducen los datos de conexión:

Y en la siguiente captura se puede apreciar la estructura; si nos posicionamos

en cada componente de la estructura, el editor nos proporciona los valores que lleva asociados.
Fuente: http://www.ite.educacion.es/formacion/materiales/85/cd/linux/m6/openldap.html

2.- Securizar una aplicacion Web con autenticación vía servidor single sign-on.
Tras descargar la versión de Apache-Tomcat 8.5.30 (binary distribution-core) de
https://tomcat.apache.org/donwnload-80.cgi, se descomprime y copia el Tomcat en dos
carpetas bajo /opt del entorno de trabajo (VirtualBox 5.2.8 r121009(Qt5.6.2) + Debian 9.0). Una
carpeta se denomina CAS y otra APP, y tienen inicialmente el mismo contenido.
Ello nos permite además de la operativa que iremos viendo a lo largo del ejercicio, tener
instalaciones limpias y evitarnos deshacer algunas configuraciones que eran necesarias para
hacer funcionar JAAS, ya que usaremos la aplicación que se entregó en la práctica 1 y que
estaba diseñada para ejecutarse en este entorno.
En la práctica tenemos dos Tomcat ejecutándose simultáneamente en la misma
máquina por lo que van a intentar usar los mismos puertos por defecto, lo que implicaría que
no sería posible que los dos servidores funcionaran a la vez, puesto que si arrancáramos un
segundo Tomcat con puertos coincidentes daría error y se cerraría.
Este problema lo evitamos cambiando los puertos por defecto del servidor web. Se ha
procedido editando el archivo server.xml de la carpeta CAS en la ruta
/opt/CAS/apache-tomcat-8.5.30/conf/server.xml
sumándole de forma decimal 10 a cada puerto; así HTTP escucha peticiones en el

puerto 8090 en lugar del 8080, redirige al 8453 en lugar del 8443 y el AJP 1.3 connector on port
8009 pasa a ser 8019.
Instalación básica del CAS

Seguídamente se procede a descargar el zip con el CAS server 4.0.0 de
http://github.com/Jasig/cas/releases/download/v4.0.0/cas-server-4.0.0-release.zip y una vez
descomprimida se obtiene el cas-server-webapp-4.0.0.war de la carpeta /modules del zip
descargado y se coloca en la carpeta /webapps del servidor tomcat situado en la carpeta CAS,
ruta: /opt/CAS/apache-tomcat-8.5.30/webapps/cas-server-webapp-4.0.0.war
Arrancamos tomcat con ./startup.sh desde /opt/CAS/apache-tomcat-8.5.30/bin y se
descomprime automáticamente la carpeta con el CAS Server y queda situada en:
/opt/CAS/apache-tomcat-8.5.30/webapps/cas-server-webapp-4.0.0
Si abrimos un navegador para conectar con el servidor CAS

http://localhost:8090/cas-server-webapp-4.0.0/login podemos comprobar la conexión e iniciar sesión
con el usuario casuser y la contraseña Mellon, que vienen harcodeadas el fichero de
configuración del CAS (deployerConfigContex.xml)

Instalación básica de la aplicación de ejemplo

Utilizando el tomcat APP (situado en la carpeta APP), no será necesario cambiar
los puertos en este servidor debido a que ya los hemos cambiado en el otro servidor y hemos
comprobado que no hay puertos coincidentes.
A continuación extraemos la aplicación web facilitada en el enunciado del
paquete simplecasclient.zip y se sitúa en la carpeta /webapps del servidor apache-tomcat APP.
Esta aplicación implementa controles de acceso mediante roles sobre dos
carpetas llamadas “secure” y “extreme” contemplando un único usuario llamado “casuser” con
un rol asignado que solo se da acceso a la carpeta “secure” realizándose la autenticación de
usuario al conectar con un servidor CAS.
Arrancamos el apache-tomcat y usamos un navegador para conectar con la
aplicación CASificada mediante la URL http://localhost:8080/simplecasclient/

Y podemos comprobar que la aplicación funciona correctamente y se conecta con el

servidor CAS al introducir el usuario “casuser”, el cual tiene asignado el rol “ROLE_USER” que
no permite acceder a la carpeta “extreme”. De la misma forma se crea un usuario “paco” con
un “ROLE_ADMIN” para permitir el acceso a la carpeta extreme, con éxito.
Una vez configurado el entorno de trabajo básico y comprobada la conectividad, se va
a proceder al desarrollo de la práctica.
En primer lugar incorporo la web que queremos hacer funcionar en este entorno; para
ello copio exclusivamente la carpeta IDwebapp procedente de la Práctica 1 dentro de la carpeta
webapps de APP en la siguiente ruta /opt/APP/apache-tomcat-8.5.30/webapps/Idwebapp
Ello significa que no se consideran ni la configuracion JAAS, ni las clases
implementadas, ni los archivos donde se encontraban usuarios y contraseñas... las
configuraciones están por defecto debido a que se ha instalado el servidor de nuevo. A partir
de aquí habrá que realizar modificaciones en el código sobre todo de menu.jsp como veremos
más adelante.
Añadimos nuevos usuarios.

Vamos a la ruta /opt/CAS/apache-tomcat-8.5.30/webapps/cas-server-webapp-4.0.0/WEB-
INF/deployerConfigContext.xml eliminamos el usuario “casuser” y añadimos los nuevos usuarios.
Esto solo lo realizamos para comprobar paso a paso que estamos realizando el
ejercicio correctamente, puesto que no es de recibo que hayan contraseñas harcodeadas.
Cuando conectemos con OpenLDAP corregiremos este extremo.
Protegemos los recursos.

Necesitamos indicar el uso de Spring Security, lo que se consigue mediante el
archivo /opt/APP/apache-tomcat-8.5.30/webapps/Idwebapp/WEB-INF/web.xmlque deberá ser igual que
/opt/APP/apache-tomcat-8.5.30/webapps/simplecasclient/WEB-INF/web (el cual ya hemos probado que
funciona)
Creamos las políticas de seguridad para interceptar las URL en el archivo
/opt/APP/apache-tomcat-8.5.30/webapps/Idwebapp/WEB-INF/applicationContext-security.xml

Relacionamos los usuarios y sus roles en el mismo archivo anterior
Modificaciones en código de la web procedente de la Práctica 1

Fundamentalmente hay unos cambios que hacer sobre todo en menu.jsp.
En primer lugar hay que añadir a los roles el prefijo “ROLE_” para compatibilizarlo con
el código que se ha introducido debido a que con la configuración por defecto, Spring Security
requiere que los roles contengan este prefijo.
Posteriormente será necesario eliminar %@page import="util.MyInfo,util.User" % puesto
que no usamos las clases java que creamos en la práctica anterior, y añadir:
También debemos eliminar:

<% if (request.getParameter("logoff") != null){
session.invalidate();
response.sendRedirect("login.jsp");
}%>

Puesto que el cierre de sesión de forma provisional (dado que acabaremos cerrando la
sesión CAS) ahora es:
Finalmente, eliminamos
<%User u = MyInfo.getUser(); %>
<h1>Sistema de Gestión</h1>
<% if (request.getUserPrincipal() != null)
{
%>
<p>Bienvenido/a<%= u.getName()%> (<%= request.getUserPrincipal().getName()%>)</p>
<%
} else {
%>
<% response.sendRedirect("/secure/error.jsp"); %>
En primer lugar porque la clase de java ya no es necesaria, en segundo lugar porque el

control de usuario está externalizado y finalmente porque los métodos empleados no funcionan
en este entorno.
Para obtener el login se consigue con
En este punto se prueba la aplicación y se comprueba que su funcionamiento es correcto

antes de pasar a la utilización de CAS + OpenLDAP para autenticar. Para ello son necesarias
una librerías que podemos usar copiando el contenido de la carpeta lib de simplecasclient de
la ruta /opt/APP/apache-tomcat-8.5.30/webapps/simpleasclient/WEB-INF/lib/* en la
carpeta /lib correspondiente de IDwebapp.
Se mantiene una copia del sistema en este momento del desarrollo para verificar el
funcionamiento, si resultara de interés.
Utilización de CAS + OpenLDAP para autenticar.

Para que el servidor CAS pueda interactuar con un servidor OpenLDAP es necesario
añadir algunas librerías adicionales en la carpeta /lib del servidor CAS. Este punto y la
modificación de la configuración es lo que vamos a tratar para que funcione el sistema.
Segun la web https://apereo.github.io/cas/4.0.x/installation/LDAP-Authentication.html
podemos observar que es posible usar LDAP Supporting Direct Bind, además de contar con la
siguiente dependencia org.jasig.cas.cas-server-support.ldap.
El hecho de caracterizar el sistema como LDAP Supporting Direct Bind surge porque se
cumplen dos requisitos definidos en el enunciado:
- Todos los usuarios están en una sola sucursal en el directorio, p. ou = Usuarios, dc =
ejemplo, dc = org.
- El nombre de usuario proporcionado en el formulario de inicio de sesión de CAS forma
parte del DN, p. uid =% s, ou = Usuarios, dc = exmaple, dc = org.
Ello permite que podamos usar una plantilla para la autenticación LDAP donde no se
requiere búsqueda para calcular el DN necesario para una operación de vinculación.

Si visitamos https://mvnrepository.com/artifact/org.jasig.cas/cas-server-support-
ldap/4.0.0 podemos descargar la versión 4.0.0. en formato .jar y la situamos en /opt/CAS/apache-
tomcat-8.5.30/webapps/cas-server-webapp-4.0.0/WEB-INF/lib/cas-server-support-ldap-4.0.0.jar
Comprobamos que tenemos dentro de la carpeta anterior (../WEB-INF/lib) las

dependencias que hay en la siguiente captura de pantalla, con especial atención a la versión,
y descargamos las que falten en formato .jar y las situamos en la misma carpeta. Debido al
procedimiento seguido solo falta org.ldaptive.ldaptive en su versión 1.0.3
Una vez instalado lo configuramos para que se use en lugar de usar el listado de
contraseñas que hay en el archivo para lo que borramos dentro del deployerConfigContext.xml
la bean primaryAuthenticationHandler y posteriormente añadimos el código que se encuentra
en el tutorial para conectar el módulo y OpenLDAP usando Direct Bind, que se encuentra en
https://apereo.github.io/cas/4.0.x/installation/LDAP-Authentication.html#ldap_supporting_direct_bind
con la salvedad que aun no podemos usar ssl por lo que comentamos la propiedad
“sslConfig” de la bean “connectionConfig” y la bean “sslConfig”.
En los ejemplos de configuración del módulo de LDPA nos encontramos que para
buscar a los usuarios dentro de la organización usa ${ldap.auth.baseDN} por lo que sustituimos
la propiedad ${ldap.baseDN} por la anteriormente mencionada.
Posteriormente sustituimos el módulo usado para autenticar
<entry
key-ref="primaryAuthenticationHandler"
value-ref="primaryPrincipalResolver" />
por
<entry
key-ref="ldapAuthenticationHandler"
value-ref="primaryPrincipalResolver" />
Para finalizar se añade el código que se encuentra en el link de supporting direct bind,
al que hemos hecho referencia, para configurar las propiedades LDAP en el archivo
cas.properties
/opt/CAS/apache-tomcat-8.5.30/webapps/cas-server-webapp-4.0.0/WEB-INF/cas.properties
Sustituyendo

ldap://directory.ldaptive.org por ldap://localhost

para seleccionar el servidor local
ldap.useStartTLS=false
porque aun no está configurado ssl
ou=Users,dc=example,dc=org por ou=employees,dc=gameofthron,dc=es
para que los usuarios puedan acceder al sistema y que usuario con clave puedan
realizar operaciones sobre el servidor LDAP
ldap.authn.managerPassword=nonsense por ldap.authn.managerPassword=admin
sustitución de contraseña de administrador
#ldap.authn.format=%s@example.com se comenta para desactivarla
ldap.authn.format=uid=%s,ou=employees,dc=gameofthron,dc=es
se descomenta para activarla.
Se mantiene una copia del sistema en este momento del desarrollo para verificar el
funcionamiento, si resultara de interés.
En el video 1 se muestra el funcionamiento de la aplicación, no obstante, realizo captura

de pantalla para significar la URL de conexión, así como que todavía se trata de una conexión
no segura.
Por supuesto, tiene un funcionamiento correcto una vez logueado con cualquiera de los
usuarios y contraseñas que proporciona el enunciado, seguro en tanto que se ha utilizado el
algoritmo de cifrado más seguro posible dentro de esta técnica e independiente de la web, para
lo que hay habilitados dos servidores con el objetivo de aplicar el control de acceso a una
aplicación web java, mediante el servidor CAS single sign-on que se encarga de realizar la
autenticación de los usuarios, y el framework Spring Security que nos proporciona la etapa de
autorización mediante roles.
En el próximo punto se trata de utilizar SSL y los correspondientes certificados que

permitan proteger las comunicaciones.

2.3.3.- Utilización de SSL y certificados para proteger todas las comunicaciones.

a.- Autenticación segura OpenSSL y OpenLDAP
Los permisos que los usuarios tienen sobre los sistemas se basan en la autentificación
del usuario. Aunque ya se han desarrollado sofisticados métodos de autentificación como
sistemas de tarjeta electrónica (DNI electrónico) o sistemas biológicos como la huella dactilar o
el iris del ojo, la realidad es que requieren de elementos caros para su aplicación. En entornos
educativos y en pequeñas y medianas empresas, se sigue utilizando el mecanismo tradicional
de autentificación del usuario mediante su nombre de usuario (login) y su contraseña
(password).
Desde que el usuario introduce su contraseña hasta que ésta llega al servidor para
comprobar la autentificación, el paquete de datos que contiene la contraseña viaja por los
cables de red atravesando concentradores (hubs), conmutadores (switches) y enrutadores
(routers) hasta llegar al servidor. Durante el trayecto, cualquier persona con los conocimientos
necesarios podría quedarse con una copia del paquete de datos para, posteriormente analizarlo
y tratar de descubrir el nombre y la contraseña del usuario sin que éste se percatase.
Con la finalidad de dificultar que alguien trate de descubrir contraseñas analizando los
datos que las contienen, existe la posibilidad de cifrar los paquetes de datos en el PC antes de
enviarlos por la red, de manera que lleguen al servidor cifrados. De esta forma, aunque un
usuario malintencionado capture un paquete de datos con la información del usuario y la
contraseña, será muy dificil, por no decir imposible, que sea capaz de descifrarlos ya que se
utiliza cifrado asimétrico.
El cifrado asimétrico permite la generación de una pareja de claves comunmente

denominadas clave pública y clave privada en el servidor. La pareja de claves es tal que, todo
lo cifrado con una, solo se puede descifrar con la otra.
El servidor tiene guardada en un lugar seguro la clave privada. Cuando un cliente intenta
autentificarse, el servidor le trasfiere la clave pública para que cifre los datos con dicha clave
antes de enviarlos. El cliente utiliza la clave pública del servidor para cifrar los datos, así al
llegar el paquete al servidor, éste podrá descifrarlo porque dispone de la clave privada. Si un
usuario malintencionado intercepta el paquete de datos cifrado con la clave pública, no podrá
hacer nada porque no dispone de la clave privada. Si el usuario malintencionado intercepta el
primer paquete que envía el servidor con la clave pública, no le servirá para nada ya que no le
permitirá descifrar los datos emitidos por el PC que se va autentificar.

La estructura que se pretende es la que sigue, independientemente que la nomenclatura

mostrada en gráfica no se adapta totalmente al ejercicio, pero nos da una idea muy aproximada.
Fuente: https://wiki.jasig.org/display/CASUM/HOWTO+Setup+Dual+Authentication+in+CAS+-+SSL+Client+Auth+and+LDAP
LDAP seguro - ldaps
Al igual que el servidor web apache utiliza el puerto 80 para transmitir información sin
encifrar (protocolo http) y el puerto 443 para transmitir información cifrada (protocolo https),
openLDAP también se puede configurar para que utilice las prestaciones de cifrado que ofrece
OpenSSL.
Normalmente las consultas al servidor LDAP se realizan por el puerto 389 (protocolo
ldap) pero dichas consultas se transmiten sin cifrar. Para realizar consultas seguras cifrando
los datos con SSL, es necesasrio utilizar el puerto 636 (protocolo ldaps o protocolo ldap seguro).
Para ello, el servidor deberá disponer de un certificado firmado por una entidad certificadora
(CA) y habrá que configurar slapd para que utilice los certificados. Se deberán realizar los
siguentes pasos:
Crear una nueva entidad certificadora

Crear una petición de firma de certificado del servidor
Firmar el certificado con la CA
Copiar los certificados a la carpeta deseada, renombrar y proteger
Configurar slapd para que utilice los certificados
Modificar script de inicio de slapd para que utilice protocolo seguro ldaps
Reiniciar slapd
Crearemos un script que realizará automáticamente todos los pasos. Guardaremos el
script en /tmp/ldap-seguro.sh:
# ------- Script /tmp/ldap-seguro.sh -------
apt-get install gnutls-bin

sh -c "certtool --generate-privkey > /etc/ssl/private/cakey.pem"
echo cn = CertPaco>/etc/ssl/ca.info
echo ca>>/etc/ssl/ca.info
echo cert_signing_key>>/etc/ssl/ca.info
certtool --generate-self-signed --load-privkey /etc/ssl/private/cakey.pem --template /etc/ssl/ca.info

--outfile /etc/ssl/certs/cacert.pem
sh -c "certtool --generate-privkey > /etc/ssl/private/ldap_slapd_key.pem"
echo organization = CertPaco>/etc/ssl/ldap.info

echo cn = localhost>>/etc/ssl/ldap.info
echo tls_www_server>>/etc/ssl/ldap.info
echo encryption_key>>/etc/ssl/ldap.info
echo signing_key>>/etc/ssl/ldap.info
certtool --generate-certificate --load-privkey /etc/ssl/private/ldap_slapd_key.pem --load-ca-certificate

/etc/ssl/certs/cacert.pem --load-ca-privkey /etc/ssl/private/cakey.pem --template /etc/ssl/ldap.info --

outfile /etc/ssl/certs/ldap_slapd_cert.pem
ldapmodify -Y EXTERNAL -H ldapi:/// << EOF

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap_slapd_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap_slapd_key.pem
EOF
adduser openldap ssl-cert
chgrp ssl-cert /etc/ssl/private/ldap_slapd_key.pem
chmod g+r /etc/ssl/private/ldap_slapd_key.pem
echo SLAPD_SERVICES=\"ldap:/// ldapi:/// ldaps:///\" >> /etc/default/slapd

/etc/init.d/slapd restart
# ----------- FIN del Script -----------
Una vez guardado el script, solo queda ejecutarlo:
// Ejecutar script /tmp/ldap-seguro.sh

sudo sh /tmp/ldap-seguro.sh
En las siguientes capturas de pantalla podemos observar el resultado de la ejecución

del script.
Al finalizar el script se habrá reiniciado el servidor slapd y admitirá conexiones seguras

por el puerto 636.
root@debian:/tmp# ./sudo /temp/ldap-seguro.sh

bash: ./sudo: No existe el fichero o el directorio
root@debian:/tmp# sudo sh /tmp/ldap-seguro.sh
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
gnutls-bin ya está en su versión más reciente (3.5.8-5+deb9u3).
Los paquetes indicados a continuación se instalaron de forma automática y ya no son necesarios.
libstax-java libstax2-api-java libwoodstox-java linux-image-4.9.0-4-amd64
Utilice «sudo apt autoremove» para eliminarlos.
0 actualizados, 0 nuevos se instalarán, 0 para eliminar y 52 no actualizados.
Generating a 3072 bit RSA private key...
Generating a self signed certificate...
X.509 Certificate Information:
Version: 3
Serial Number (hex): 5ae96c9912f182c3e95fe7ae
Validity:
Not Before: Wed May 02 07:45:29 UTC 2018
Not After: Thu May 02 07:45:29 UTC 2019
Subject: CN=CertPaco
Subject Public Key Algorithm: RSA
Algorithm Security Level: High (3072 bits)
Modulus (bits 3072):
00:bc:bf:c8:11:20:be:0d:85:75:70:62:23:96:21:b5
2c:7f:75:3d:2c:46:19:c7:a3:5e:e9:4c:8a:ae:0e:f3
30:c5:6f:5c:3a:b8:4f:02:86:dc:ab:77:1a:6b:ac:99
ba:9d:42:84:ce:6e:f6:11:34:50:e9:ba:6b:85:12:67
bc:b9:11:ca:bc:fa:77:7b:dc:25:d0:ab:0b:8e:d6:eb
96:24:34:a2:c3:f9:6a:bc:28:50:e6:d0:25:57:7a:36
77:c1:90:34:72:cc:d7:91:c1:57:6d:db:89:52:e8:4a
02:fa:24:b9:16:58:5e:52:0d:cb:88:a1:d2:20:8f:8d
85:54:2d:0d:f5:ad:de:58:2a:3c:50:31:67:33:99:1a
2b:0e:8a:db:0d:37:81:cd:ae:ff:28:ca:dd:1b:b9:8a
8e:e9:d7:d2:de:f3:f9:98:c1:e1:d0:26:f6:b0:54:24
2f:c2:5b:7f:c4:4a:47:03:ac:00:72:44:e1:7a:5f:50
84:0b:89:05:6b:96:58:f0:16:b2:36:d4:21:00:f0:f2
48:23:5a:7b:fa:13:27:18:21:63:87:32:92:9f:6f:19

44:99:d3:e2:76:31:83:81:f1:b4:71:61:f9:1f:67:55
8c:b3:0e:e5:50:6d:c5:66:4e:21:8e:13:c8:06:c2:89
d3:17:52:38:e4:c4:60:92:01:52:a0:bc:41:0e:47:52
95:19:59:3a:23:fe:76:c9:de:54:5e:28:c4:14:63:dd
2f:f3:5b:c5:be:f3:61:4e:59:c1:02:9f:11:f0:23:73
ce:7b:86:e0:ef:be:e7:e2:58:8d:5d:28:44:c5:8b:b8
9d:5c:de:78:63:68:37:f6:10:91:01:b7:ad:96:eb:05
f6:10:54:b6:00:5a:53:4e:64:0e:e7:54:54:10:87:e8
70:62:22:3d:1e:81:1a:8e:1b:59:52:60:fc:fb:c8:b8
47:08:b2:68:cb:6c:71:2b:02:3f:35:dc:8f:1d:73:75
4d
Exponent (bits 24):
01:00:01
Extensions:
Basic Constraints (critical):
Certificate Authority (CA): TRUE
Key Usage (critical):
Certificate signing.
Subject Key Identifier (not critical):
5aca733ee26c20272500de1c95e45155bfdb58f3
Other Information:
Public Key ID:
sha1:5aca733ee26c20272500de1c95e45155bfdb58f3
sha256:ea135e4fdbcd74fbaa905a1f3429f932df1912759d24bc9c07e7f40a4ecab32d
Public key's random art:
+--[ RSA 3072]----+
|o .o+o..... |
|o o o.. . |
| o o . . |
| . . . |
| o S . o |
| o o. + = o|
| + .= . o .E|
| .o+. |
| oo... |
+-----------------+
Signing certificate...
Generating a 3072 bit RSA private key...
Generating a signed certificate...
X.509 Certificate Information:
Version: 3
Serial Number (hex): 5ae96c99327447f54aa336ee
Validity:
Not Before: Wed May 02 07:45:29 UTC 2018
Not After: Thu May 02 07:45:29 UTC 2019
Subject: O=CertPaco,CN=localhost
Subject Public Key Algorithm: RSA
Algorithm Security Level: High (3072 bits)
Modulus (bits 3072):
00:ac:8d:a7:48:3e:ce:1d:4c:f4:9c:92:9e:08:e8:bc
19:56:f1:3e:f2:a7:93:d7:fb:22:bc:57:6a:1b:8e:87
40:38:dc:3b:09:30:8e:74:ff:51:30:1c:ce:e7:89:e3
99:da:d7:51:08:7c:79:66:c5:41:a5:1e:17:07:8f:d4
68:8f:b3:de:48:02:77:0d:fe:92:d0:a8:88:be:f7:7d
ac:44:e6:6c:2f:f5:48:ab:b6:4d:e9:12:5a:25:e9:5d
18:38:bf:16:2f:72:c5:d9:e3:76:d2:e6:6f:23:82:a9
7e:1f:04:b6:61:5e:15:d2:d0:ce:ef:62:9c:45:6d:cc
02:b4:f4:8c:29:b8:ab:5a:93:8c:8d:aa:07:1e:da:b0
d4:7c:c4:25:1b:a7:f4:c9:8d:3b:00:7b:f7:0a:0c:45
6d:44:f6:35:96:0f:eb:98:e7:91:42:6b:88:9e:43:96
fb:0c:e4:de:43:6a:58:66:4c:78:1c:d2:14:4f:ff:c1
73:d3:0e:bc:b6:55:11:f2:00:a7:65:5f:d4:21:1e:5c
18:c5:24:02:ac:72:f9:d6:de:66:11:a1:ad:b3:db:87
3e:aa:51:52:0b:8e:a6:f7:fb:94:21:35:72:14:a4:fe
9e:91:57:3e:f3:16:74:79:53:35:53:b3:9f:e7:2d:f9
ad:bf:5c:2d:0c:f7:b2:c9:53:4b:24:6d:99:4f:68:b7
ff:a3:85:a1:9e:d1:68:55:66:ad:74:bf:0f:13:11:57
3d:43:97:db:75:62:6b:87:86:e8:ae:b7:67:38:9b:d7
6c:d2:bc:81:4d:27:1b:e3:11:88:69:63:6c:c9:17:6d
b2:12:38:56:6d:ab:45:e6:3c:59:10:b5:86:74:62:29
ed:0d:27:fa:a4:80:6d:b7:54:b3:56:17:09:f6:02:c5

d9:6b:99:2e:82:03:76:dc:c7:2e:22:19:25:25:fe:1c
94:db:6f:1e:6b:a5:81:9d:8d:92:82:bd:15:e2:71:f5
0f
Exponent (bits 24):
01:00:01
Extensions:
Basic Constraints (critical):
Certificate Authority (CA): FALSE
Key Purpose (not critical):
TLS WWW Server.
Key Usage (critical):
Digital signature.
Key encipherment.
Subject Key Identifier (not critical):
a12976818881548675ec152a725b610de4d5eefc
Authority Key Identifier (not critical):
5aca733ee26c20272500de1c95e45155bfdb58f3
Other Information:
Public Key ID:
sha1:a12976818881548675ec152a725b610de4d5eefc
sha256:f8fe2e0fe7d836228fd4a9b7020a37ed1857ddd8a37dbabbb615ddd7989abe4d
Public key's random art:
+--[ RSA 3072]----+
|+.++o*ooo |
|.+..+o+o . |
|...oo+o o |
| o +. + o |
| .o + S |
| . o o |
| . |
| E |
| |
+-----------------+
Signing certificate...
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
El usuario `openldap' ya es un miembro de `ssl-cert'.

[ ok ] Restarting slapd (via systemctl): slapd.service.
root@debian:/tmp#
Probando el acceso por ssl
Si nuestro servidor LDAP está funcionando en modo seguro, estará escuchando en el

puerto 636 ya que es el puerto utilizado por el protocolo ldaps. Para probarlo, iniciamos JXplorer
pero la conexión la realizamos a dicho puerto y el nivel de seguridad seleccionamos SSL + User
+ Password ya que la autentificación va a ser por usuario y contraseña pero utilizando SSL:

Ldaps utiliza el puerto 636

Al intentar conectar, nos aparecerá la información del certificado. Podremos aceptar el
certificado para esta sesión (This session only) o para siempre (Always).
Podemos ver el certificado:
Aceptar certificado

Una vez que hemos conectado, podemos apreciar en la parte inferior que la conexión
se ha realizado al puerto 636:
Siempre debemos conectarnos al servidor LDAP utilizando el protocolo seguro ldaps

debido a que en las conexiones al servidor LDAP, enviamos contraseñas y si estas viajan en
texto plano, serían fácilmente descubiertas por algún usuario avanzado que coloque un sniffer
en la red y almacene los paquetes de datos.
Fuente: Se ha hecho uso en este apartado de contenido licenciado (CC BY-SA 3.0) con modificaciones para
adaptarse al ejercicio propuesto, procedente de:
http://www.ite.educacion.es/formacion/materiales/85/cd/linux/m6/autentificacin_segura_openssl_y_openldap.html
En este punto corresponde probar si la aplicación funciona con LDAP securizado; para
ello hemos modificado las líneas marcadas en rojo del archivo cas.properties en la ruta de la
carpeta CAS ../WEB~INF/cas.properties
========================================
# General properties
#========================================
ldap.url=ldaps://localhost:636
# LDAP connection timeout in milliseconds
ldap.connectTimeout=3000
# Whether to use StartTLS (probably needed if not SSL connection)
ldap.useStartTLS= false
ldap.trustedCert=file:///etc/ssl/certs/cacert.pem
#========================================
# LDAP connection pool configuration
#========================================
ldap.pool.minSize=3
ldap.pool.maxSize=10
ldap.pool.validateOnCheckout=false
ldap.pool.validatePeriodically=true
# Amount of time in milliseconds to block on pool exhausted condition
# before giving up.
ldap.pool.blockWaitTime=3000
# Frequency of connection validation in seconds
# Only applies if validatePeriodically=true

ldap.pool.validatePeriod=300
# Attempt to prune connections every N seconds
ldap.pool.prunePeriod=300
# Maximum amount of time an idle connection is allowed to be in
# pool before it is liable to be removed/destroyed
ldap.pool.idleTime=600
#========================================
# Authentication
#========================================
# Base DN of users to be authenticated
ldap.authn.baseDn=ou=employees,dc=gameofthron,dc=es
# Manager DN for authenticated searches
ldap.authn.managerDN=cn=admin,dc=gameofthron,dc=es
# Manager password for authenticated searches
ldap.authn.managerPassword=admin
# Search filter used for configurations that require searching for DNs
#ldap.authn.searchFilter=(&(uid={user})(accountState=active))
ldap.authn.searchFilter=(uid={user})
# Search filter used for configurations that require searching for DNs
ldap.authn.format=uid=%s,ou=employees,dc=gameofthron,dc=es
#ldap.authn.format=%s@example.com
Con ello indicamos la URL de LDAP por el puerto seguro 636 y le suministramos la
información de la ubicación del certificado. Asimismo comentamos el puerto LDAP no seguro
en el archivo de configuración slapd (ruta etc/default) ya que slapd normalmente sirve LDAP en
el puerto TCP 389 y en este caso hay que indicarle que atienda solicitudes en el puerto TCP
636 (LDAPS).
En este punto tras comprobar que el usuario openldap tiene los oportunos permisos de
acceso, creamos un nuevo bean con la configuración de SSL en deployerConfigContext.txt.
<bean id="connectionConfig" class="org.ldaptive.ConnectionConfig"

p:ldapUrl="${ldap.url}"
p:connectTimeout="${ldap.connectTimeout}"
p:useStartTLS="${ldap.useStartTLS}"
p:sslConfig-ref="sslConfig"/>
<bean id="sslConfig" class="org.ldaptive.ssl.SslConfig">

<property name="credentialConfig">
<bean class="org.ldaptive.ssl.X509CredentialConfig"
p:trustCertificates="${ldap.trustedCert}" />
</property>
</bean>
Una vez reiniciado el servicio mediante root@debian:/etc/init.d# ./slapd restart

y reiniciados los servidores tomcat, podemos observar que efectivamente funciona aunque el
resto de comunicaciones aun no es segura.

b.- Autenticación segura SSL con Tomcat

La forma más común en que SSL se integra en las comunicaciones de Internet es a
través del protocolo HTTPS. Llamar a HTTPS un "protocolo" no es del todo exacto, ya que es
simplemente una combinación de los protocolos HTTP y SSL. Cuando decimos que se envió
un mensaje usando HTTPS, lo que realmente estamos diciendo es que el mensaje se cifró
primero usando SSL, se transmitió y se recibió usando el protocolo HTTP normal, y luego se
descifró por el receptor, también con SSL. Resumiendo:
 SSL ofrece seguridad a través del cifrado

 el proceso de encriptación es posible a través del uso de certificados digitales verificados
por una tercera autoridad certificadora.
 la implementación más común de este proceso es el protocolo de combinación HTTPS.
La configuración de SSL para Tomcat se puede dividir en dos tareas principales: crear
un almacén de claves funcional y configurar los conectores y aplicaciones de Tomcat.
PARTE I. Certificados de seguridad
Pas 1 - Creando el Keystore/Truststore (almacén de claves donde guardar los

certificados en los que el servidor confía)
Un programa llamado keytool, que se incluye con JDK, realiza el trabajo de crear el
nuevo almacén de claves. Para crear un nuevo almacén de claves usando este programa,
ingresar en por linea de comandos:
# keytool -genkey -alias tomcat -keyalg RSA -keystore got_es.jks -keysize 2048 -dname "CN=localhost,
OU=CertificaPaco, O=Paco, L=ALC, ST=ALC, C=ES"
Introduzca la contraseña del almacén de claves:changeit
Volver a escribir la contraseña nueva:changeit
Introduzca la contraseña de clave para <tomcat>
(INTRO si es la misma contraseña que la del almacén de claves):
Lo último que pedirá keytool es que se especifique la contraseña clave, que es la

contraseña específica de estos certificados específicos. En lugar de ingresar nada en este
aviso, simplemente presionamos ENTER.
Esto hará que keytool establezca la contraseña de la clave en un valor equivalente a la

contraseña del almacén de claves. Las contraseñas coincidentes son REQUERIDAS para que
Tomcat pueda acceder al certificado. Si se eligen dos contraseñas diferentes, cualquier intento
de acceder al almacén de claves provocará un bloqueo.
Paso 2: Creación de la solicitud de firma de certificado
Ahora que ha creado su almacén de claves, es hora de crear un archivo llamado solicitud
de firma de certificado, o CSR, que será utilizado por la autoridad de certificación de su elección
para generar el certificado que SSL presentará a otras partes durante el protocolo de enlace.
# keytool -certreq -keyalg RSA -alias tomcat -file certgot.csr -keystore got_es.jks

También se puede usar la herramienta de claves para crear este archivo tal como se
muestra a continuación.
# keytool -export -alias tomcat -file certgot.crt -keystore got_es.jks
Certificado almacenado en el archivo <certgot.crt>
De esta manera keytool ha creado un archivo llamado certgot.crt, que se puede enviar
a la CA. Al usar este archivo, se genera un certificado personalizado para el servidor.
Paso 3 - Instalar el nuevo certificado

SSL verifica la autenticidad del certificado de un sitio utilizando algo llamado "cadena de
confianza", lo que básicamente significa que, durante el intercambio, SSL inicia un apretón de
manos adicional con la Autoridad de certificación especificada en el certificado de su sitio, para
verificar que uno mismo no hizo su propia CA.
Para "anclar" la cadena de confianza de su certificado, debe descargar un certificado
adicional, llamado "Certificado de raíz", de su CA, y luego importar este certificado y el nuevo
de su sitio en su almacén de claves.
En nuestro caso vamos a importar el certificado de confianza al almacén de certificados
de Java y puesto que contamos con dos servidores Tomcat, se utilizará el mismo certificado
para las dos aplicaciones.
root@debian:/home/paco/Escritorio/certificados# keytool -J-Duser.language=en -import -trustcacerts -
alias tomcat -file certgot.crt -keystore /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts
Enter keystore password:
Owner: CN=localhost, OU=CertificaPaco, O=Paco, L=ALC, ST=ALC, C=ES
Issuer: CN=localhost, OU=CertificaPaco, O=Paco, L=ALC, ST=ALC, C=ES
Serial number: 4448aac9
Valid from: Sun May 06 18:14:47 CEST 2018 until: Sat Aug 04 18:14:47 CEST 2018
Certificate fingerprints:
MD5: 04:AC:CE:61:01:75:78:49:F0:0D:D0:6B:B0:F1:1C:F7
SHA1: 59:97:B9:08:1A:18:AD:0D:75:4C:63:26:1A:BE:76:66:43:2B:51:04
SHA256:
84:68:DD:BE:FF:B2:DB:98:3B:AF:3A:62:99:0B:4E:2C:15:E9:DB:A9:38:7A:76:06:00:0F:B5:96:C5:48:CE:E5
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 33 D5 17 52 63 7F 9D 67 F1 AC 85 46 3F B9 97 30 3..Rc..g...F?..0
0010: 3C 0B 86 A1 <...
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
PARTE II. Configuración de Tomcat para el uso de SSL. Conectores.
Las opciones del conector global de Tomcat se configuran en el archivo de

configuración principal de Tomcat, .. / conf / server.xml, dado que tenemos dos Tomcat, para la
aplicación (APP) se le asigna el puerto 8443, mientras que para el CAS se le asigna el puerto
8453 y se crea una carpeta en ambos directorios que contenga el certificado que se ha
generado y que es válido para ambos servidores.

Aunque Tomcat fue diseñado principalmente como un contenedor de servlets, parte de

lo que lo hace tan poderoso es la capacidad de Catalina para funcionar como un servidor web
independiente. Esta funcionalidad es posible gracias al elemento Conector HTTP.
Este elemento de conector, que admite el protocolo HTTP / 1.1, representa un único
componente de conector que escucha un puerto TCP específico en un servidor determinado
para las conexiones.
El conector HTTP tiene muchos atributos que se pueden modificar para especificar
exactamente cómo funciona, y funciones de acceso como redireccionamiento y reenvío de
proxy.
Dos de los atributos más importantes de este conector son los atributos "protocolo" y
"SSLEnabled".
El atributo "protocolo", que define el protocolo que el Conector utilizará para
comunicarse, se establece de forma predeterminada en HTTP / 1.1, pero se puede modificar
para permitir el acceso a protocolos más especializados. Por ejemplo, si desea exponer las
propiedades de los conectores de nivel bajo de los conectores para un ajuste fino, puede usar
el atributo "protocolo" para habilitar el protocolo NIO. Establecer el atributo "SSLEnabled" en
"verdadero" hace que el conector utilice el protocolo de enlace SSL / cifrado / descifrado.
Los conectores HTTP también se pueden usar como parte de un esquema de equilibrio
de carga, junto con un equilibrador de carga HTTP que admita la coherencia de sesión, como
mod_proxy. Sin embargo, como AJP tiende a manejar proxys mejor que HTTP, este uso no es
común.
Pues vamos allá; en el archivo server.xml de la carpeta APP tendremos:


<Connector
protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"
keystoreFile="ssl/got_es.jks" keystorePass="changeit"
clientAuth="false" sslProtocol="TLS"/>
Y en el archivo server.xml de la carpeta CAS solo cambiará con respecto al

anterior el puerto, que en este caso es port="8453"


<Connector
protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8453" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"
keystoreFile="ssl/got_es.jks" keystorePass="changeit"
clientAuth="false" sslProtocol="TLS"/>
Fuente : https://www.mulesoft.com/tcat/tomcat-ssl

c.- Modificación de llamadas dentro de la aplicación IDwebapp

Indicamos que se trata de una comunicación SSL en la ruta de la carpeta APP
../WEB~INF/applicationContext-Security.xml
Finalmente, modificamos el archivo cas.properties en los parámetros :
server.name=https://localhost:8443
host.name=localhost
Tras reiniciar los servidores el sistema está preparado para funcionar.
Cierre de sesión con log-out al servidor CAS

En un primer momento, si deseamos realizar un cierre desde la aplicación podemos
utilizar en el archivo menu.jsp la redirección de logout de spring security:
<h3>Cierre de Sesión</h3>
<p><a href="../j_spring_security_logout">Logout</a></p>
No obstante se solicita que el cierre de sesión implique hacer un log-out al servidor CAS,
así como que la página “menu.jsp” debe tener un link que permita al usuario autenticado hacer
logout y cerrar la sesión, devolviendo a la página de portada “index.jsp”.
Para conseguirlo realizamos los siguientes cambios; en primer lugar sustituimos el

código anterior del archivo menu.jsp por:
<h3>Cierre de Sesión mediante log-out al servidor CAS</h3>

<p><a href="../logout">Logout</a></p>
Y añadimos en applicationContext-security.xml la URL del logout:
<security:logout logout-url="/logout" logout-success-url="http://localhost:8090/cas-server-

webapp-4.0.0/logout" invalidate-session="true"/>
Y si probamos con cualquier usuario autenticado podemos comprobar que se realiza el

logout del CAS.
Desde este punto de partida y tras securizar las comunicaciones con https, procedemos
a tratar el cierre de sesión con logout CAS y la redirección a index.jsp
Para abordar el tema de la redirección a index.jps, hay que comprender el parámetro de

del archivo cas.properties en la propiedad cas.logout.followServiceRedirects=false por defecto
deshabilitada, ya que según el protocolo CAS , el punto final /logout es responsable de destruir
la sesión actual de SSO. Al desconectarse, también puede ser conveniente redirigir a un
servicio. Esto se controla mediante la especificación del enlace de redirección a través
del parámetro service. El hecho es que CAS no es un gestor de sesión de aplicación, ya que es
responsabilidad de las aplicaciones mantener y controlar sus propias sesiones de
aplicación. Una vez que se completa la autenticación, CAS generalmente está fuera en
términos de las sesiones de la aplicación. Por lo tanto, la política de caducidad de la sesión de
la aplicación en sí es totalmente independiente de CAS y puede coordinarse y ajustarse de
forma flexible dependiendo de la experiencia del usuario ideal en caso de que la sesión de la
aplicación caduque.
En el caso de que Single Logout no estuviera activado, normalmente, la aplicación

puede exponer un punto final de sesión para destruir la sesión y, a continuación, redirigir el
agente al punto final CAS logout para destruir completamente también la sesión SSO.
Para ello se ha modificado el código del archivo applicationContext-security.xml, tal y como

se muestra a continuación:

Consultado https://docs.spring.io/spring-security/site/docs/3.1.x/reference/cas.html (6/5/2018)
Página personalizada de error por acceso a zona restringida
Para concluir, tan solo resta crear una página que informe del intento de acceso a una
zona restringida, así como la posibilidad de volver a la página de menú desde donde se originó
la petición.
La página Acceso denegado aparece cuando un usuario no autorizado que no tiene
privilegios para ver una página / sección, intenta verla usando su nombre de usuario y
contraseña. Por ejemplo, cuando un usuario sin privilegios intenta ver páginas de una sección
de administrador, aparecerá una página de error que muestra el código de error 403 y un
mensaje "Acceso denegado".
Aseguramos el acceso seguro a la URL al proporcionar un formulario de inicio de sesión

utilizando Spring Security. El usuario debe proporcionar una credencial de inicio de sesión
correcta para ver la página.
El código utilizado en la web 403.jsp es:

<html>
<head>
<title>Denied Access</title>
</head>
<body>
<h1><font color="red">Denied Access</font></h1>
<p>No tiene permisos para acceder a esta zona</p>
<p><a href='<%= response.encodeURL("../menu.jsp") %>'>back</a></p>

</body>
</html>
Ello se realiza mediante la adición el código siguiente en el archivo applicationContext-

security.xml, <security:access-denied-handler error-page="/403.jsp"/>
Consultado https://www.dineshonjava.com/customize-http-403-access-denied-page/ (6/5/2018)

Acceso a la aplicación desde el navegador: https://localhost:8443/IDwebapp/

Acceso solo al servidor CAS: https://localhost:8453/cas-server-webapp-4.0.0/login
Descarga de la máquina virtual Virtualbox configurada con la práctica:
https://drive.google.com/open?id=1Np8L4YLl5-cNVCGtBdR4iJuU1OSnPaXp
Otra bibliografía externa a la recomendada y/u oficial consultada:
https://www.digicert.com/es/sfc-creacion-java.htm
https://www.elarraydejota.com/administracion-de-autoridades-de-certificacion-de-confianza-en-
debian/
https://www.mulesoft.com/tcat/tomcat-ssl
https://coderanch.com/t/681099/application-servers/Tomcat-SSL-config-Tomcat
https://wiki.jasig.org/display/CASUM/HOWTO+Setup+Dual+Authentication+in+CAS+-
+SSL+Client+Auth+and+LDAP
https://docs.oracle.com/cd/E19509-01/820-3503/ggfka/index.html
https://stackoverflow.com/questions/21633274/should-we-point-keystore-and-truststore-to-the-
same-jks-file
https://stackoverflow.com/questions/21833732/configure-truststore-in-tomcat
http://magmax.org/blog/creando-tu-propia-entidad-certificadora-ssl/
https://www.dynacont.net/documentation/linux/openssl/
https://wiki.pentaho.com/display/ServerDoc2x/Enabling+SSL+on+the+CAS+Server
https://rubensa.wordpress.com/2010/03/03/recipe-for-creating-sample-certificates-from-scratch/
Firmado por FRANCISCO JOSE GINER

AYGUADE - NIF:21462005S el día
07/05/2018 con un certificado emitido
por ACCVCA-120

Identidad Digital

Cargado por

Copyright:

Formatos disponibles

Identidad Digital

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Identidad Digital

Cargado por

Copyright:

Formatos disponibles

DOCUMENTO ANEXO A LOS ARCHIVOS DE APLICACIÓN Y JUEGOS DE PRUEBAS

Francisco José Giner Ayguadé

0.- Aspectos introductorios y de configuración previa.

El diagrama siguiente muestra el acceso a un recurso protegido mediante CAS y Spring

2 Francisco José Giner Ayguadé

1.- Creación de un directorio de empresa usando OpenLDAP.

apt-get install slapd ldap-utils

Posteriormente nos pide que confirmemos la contraseña:

Los archivos de configuración del servidor LDAP se almacenan en la carpeta

Lo primero que nos pregunta el asistente es si deseamos omitir la configuración del

3 Francisco José Giner Ayguadé

// Parar el servidor LDAP

4 Francisco José Giner Ayguadé

El script que carga el fichero Ex1_3.ldif anterior es Ex1_3.sh

5 Francisco José Giner Ayguadé

Quedando el fichero Ex1_4_1.ldif con los trabajadores como sigue:

6 Francisco José Giner Ayguadé

Se procede de forma análoga en el archivo que contiene las sentencias para

7 Francisco José Giner Ayguadé

A continuación adjunto pantalla del resultado de la ejecución.

8 Francisco José Giner Ayguadé

Una vez cargados los datos, podemos usar la herramienta JXplorer

9 Francisco José Giner Ayguadé

Y en la siguiente captura se puede apreciar la estructura; si nos posicionamos

10 Francisco José Giner Ayguadé

sumándole de forma decimal 10 a cada puerto; así HTTP escucha peticiones en el

Instalación básica del CAS

Si abrimos un navegador para conectar con el servidor CAS

11 Francisco José Giner Ayguadé

Instalación básica de la aplicación de ejemplo

12 Francisco José Giner Ayguadé

Y podemos comprobar que la aplicación funciona correctamente y se conecta con el

Añadimos nuevos usuarios.

Protegemos los recursos.

13 Francisco José Giner Ayguadé

Relacionamos los usuarios y sus roles en el mismo archivo anterior

Modificaciones en código de la web procedente de la Práctica 1

También debemos eliminar:

14 Francisco José Giner Ayguadé

En primer lugar porque la clase de java ya no es necesaria, en segundo lugar porque el

En este punto se prueba la aplicación y se comprueba que su funcionamiento es correcto

Utilización de CAS + OpenLDAP para autenticar.

15 Francisco José Giner Ayguadé

Comprobamos que tenemos dentro de la carpeta anterior (../WEB-INF/lib) las

16 Francisco José Giner Ayguadé

ldap://directory.ldaptive.org por ldap://localhost

En el video 1 se muestra el funcionamiento de la aplicación, no obstante, realizo captura

En el próximo punto se trata de utilizar SSL y los correspondientes certificados que

17 Francisco José Giner Ayguadé

2.3.3.- Utilización de SSL y certificados para proteger todas las comunicaciones.

El cifrado asimétrico permite la generación de una pareja de claves comunmente

18 Francisco José Giner Ayguadé

La estructura que se pretende es la que sigue, independientemente que la nomenclatura

LDAP seguro - ldaps

Crear una nueva entidad certificadora

apt-get install gnutls-bin

certtool --generate-self-signed --load-privkey /etc/ssl/private/cakey.pem --template /etc/ssl/ca.info

echo organization = CertPaco>/etc/ssl/ldap.info

certtool --generate-certificate --load-privkey /etc/ssl/private/ldap_slapd_key.pem --load-ca-certificate