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 Service (CAS) con la la siguiente documentació documentación n de soporte: https://apereo.github.io/cas/4.0.x/in https://apereo.githu b.io/cas/4.0.x/installation/Con stallation/Configuring-Authen figuring-Authentication-Compo tication-Components.html nents.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


MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE 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 administrado administrador, r, 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.

3


MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE

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 posteriormen posteriormente te 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:

4



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 continuación se procede 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.” 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

5



Quedando el fichero

6

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

7



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 explicad explicado o con anterioridad anterioridad..

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

8



Una vez cargados los datos, podemos usar la herramienta JXplorer (http://jxplorer.org http://jxplorer.org)) que es un navegador y editor de LDAP multiplataforma. multiplatafo rma. 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:

9



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

10


MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE 2.2.- Securi Securi zar zar un a aplicacion aplicacion Web Web co n autenticación vía servido servido r single si gn-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/do http://github.com/Jasi g/cas/releases/download/v4.0.0 wnload/v4.0.0/cas-server-4.0.0-rel /cas-server-4.0.0-release.zip ease.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

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) (deployerConfigContex.xml)

11

abrimos

un

navegador



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 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/

12



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. usuarios. Vamos a la ruta INF/deployerConfigContext.xml

/opt/CAS/apache-tomcat-8.5.30/webapps/cas-server-webapp-4.0.0/WEB-

eliminamos el usuario “casuser” y añadimos los nuevos usuario s.

Esto solo lo realizamos para comprobar paso a paso q ue 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.xml que deberá ser igual que (el cual ya hemos probado que /opt/APP/apache-tomcat-8.5.30/webapps/simplecasclient/WEB-INF/web 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

13



Relacionamos Relacionam os 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" 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"); }%>

14


puesto


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(); %>
Sistema de Gestión
<% if (request.getUserPrincipal() != null) { %>
Bienvenido/a<%= u.getName()%> (<%= request.getUserPrincipal().getName()%>)
<% } 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 comprue ba que su funcionamiento es correcto correc to 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. funcionamiento

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.githu https://apereo.github.io/cas/4.0.x/in b.io/cas/4.0.x/installation/LDAP-Au stallation/LDAP-Authentication.htm thentication.htmll podemos observar que es posible usar LDAP Supporting Direct Bind, además de contar con la siguiente dependenci dependencia a org.jasig.cas org.jasig.cas.cas-server-supp .cas-server-support.ldap. ort.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.

15



Si visitamos https://mvnrepository.com/artifact/org https://mvnreposi tory.com/artifact/org.jasig.cas/cas-ser .jasig.cas/cas-server-supportver-supportldap/4.0.0 podemos descargar descargar la versión 4.0.0. en formato f ormato .jar y la situamos en /opt/CAS/apachetomcat-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

por

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

16


MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE 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 administrad administrador or #ldap.authn.format=%[email protected] 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. funcionamiento 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 comunicacion comunicaciones. es.

17



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ó aplicación. 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.

18



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 https://wiki.jasig.org/displa .jasig.org/display/CASUM/HO y/CASUM/HOWTO+Setup+Dual+Au WTO+Setup+Dual+Authentication+in+ thentication+in+CAS+-+SSL+Client+ CAS+-+SSL+Client+Auth+and+LDAP Auth+and+LDAP

LDAP seguro - ldaps Al igual que el servidor web apache utiliza el puerto 80 para transmitir t ransmitir 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-segur /tmp/ldap-seguro.sh: o.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-s igned --load-privkey /etc/ssl/private/ca /etc/ssl/private/cakey.pem key.pem --outfile /etc/ssl/certs/cacert.pem sh -c "certtool --generate-privkey > /etc/ssl/private/ldap_slapd_key.pem" echo echo echo echo echo

--template

/etc/ssl/ca.info

organization = CertPaco>/etc/ssl/ldap.info cn = localhost>>/etc/ssl/ldap.info tls_www_server>>/etc/ssl/ldap.info encryption_key>>/etc/ssl/ldap.info 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 --

19


MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE 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 servidor slapd y admitirá conexiones 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

20


MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE 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

21


MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE 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:

22



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

23



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 correspon corresponde de 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

24


MASTER INTERUNIVERSITARIO EN SEGURIDAD DE LAS TIC IDENTIDAD DIGITAL – PRACTICA 2 – CURSO 2017/18 2º SEMESTRE 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=%[email protected]

Con ello indicamos la URL de LDAP por el puerto seguro 636 y le suministramos la información informac ión de la ubicación del certific certificado. ado. 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 .

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.

25



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 ofrece seguridad seguridad a través través del cifrado el proceso de encriptación es posible a través del uso de certific certificados ados digitales verificados por una tercera t ercera 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 (INTRO si es la misma contraseña que la del almacén de claves):

Lo último que pedirá keytool es que se especifiqu especifique e 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 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 Introduzca la contraseña del almacén de claves: changeit

26



También se puede usar la herramienta de claves para crear este archivo tal como se muestra a continuaci continuación. ón. # keytool -export -alias tomcat -file certgot.crt -keystore got_es.jks Introduzca la contraseña del almacén de claves: changeit Certificado almacenado en el archivo

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

27



Aunque Tomcat fue diseñado diseñado principalmente principalmente como un contenedor contenedor de servlets, 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 el conector utilice el protocolo de enlace 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: 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" sslProtocol="TLS"/>

Fuente : https://www.mulesoft.com/tcat/tomcat-ssl

28



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 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:
Cierre de Sesión

Logout

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 te ner 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:
Cierre de Sesión mediante log-out al servidor CAS

29


Logout

Y añadimos en applicationContext-security.xml la URL del logout:

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 el protocolo CAS , el punto final /logout es responsable de destruir la sesión actual act ual de SSO. Al desconectarse, desconect arse, también puede pu ede ser conveniente convenient e redirigir a un servicio. Esto se controla mediante la especificac especificación ió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 c ompleta la autenticación, autent icación, CAS generalmente generalment e 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 se muestra a continuació continuación: n:

30

applicationContext-security.xml ,

tal y como



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 r estringida 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 denegado". ". Aseguramos el acceso acceso seguro seguro a la URL al proporcionar proporcionar un formulario formulario de inicio 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: Denied Access
Denied Access

No tiene permisos para acceder a esta zona

back

Ello se realiza mediante la adición el código siguiente en el archivo

applicationContext-

security.xml , Consultado https://www.dineshonjava.com/customize-http-403-access-denied-page/

31

(6/5/2018)



Acceso a la aplicación aplicación desde el navegador: https://localhost:8443/IDwebapp/ Acceso solo al servidor servidor CAS: https://localhos https://localhost:8453/cas-server-w t:8453/cas-server-webapp-4.0.0/lo ebapp-4.0.0/login gin Descarga de la máquina virtual Virtualbox configurada con la práctica: https://drive.google.com/open?i https://drive.googl e.com/open?id=1Np8L4YL d=1Np8L4YLl5-cNVCGtBdR4 l5-cNVCGtBdR4iJuU1OSnP iJuU1OSnPaXp aXp

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-endebian/ 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-thesame-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

32


Identidad Digital

Recommend Documents

Sistema de Gestión

Cierre de Sesión

Cierre de Sesión mediante log-out al servidor CAS

Denied Access