Durante cierto tiempo tuve la inquietud de levantar un servidor de “Single Sign On” o SSO como se le conoce comunmente. Hace poco, al dar un curso de Java, se presentó esa necesidad y como resultado de tal esfuerzo, se generó esta mini- guía para su instalación. Espero siceramente que pueda servir de algo.

 

 

Ajuste de la resolución de nombre de dominio

Con la finalidad de que un servidor responda ante un nombre de dominio que NO ha sido asignado a través de un DNS, es posible modificar el archivo llamado ‘hosts’ (que en linux se ubica en ‘/etc/hosts’ y en windows en ‘c:\windows\system32\drivers\etc\hosts’) con la siguiente información por ejemplo:

127.0.0.1   www.se.upci.net

lo anterior también debe ser realizado para los clientes que se conectarán a tal servidor, de la siguinte manera:

172.125.41.100 www.se.upci.net

en donde la IP dada, es la IP del servidor al que se desea obtener una respuesta para ‘www.se.upci.net’

Generación de un certificado autogenerado (y auto firmado)

Para la generación de un certificado digital se requiere del uso de la herramienta ‘keytool’ (keytool es una herramienta que está incluida en el JRE de java) que creará tal certificado y lo guardará en un almacén de llaves llamado ‘keystore’, que a su vez, será creado si es que no existe.

Es conveniente tener este certificado ‘firmado’, pero tal firma es costosa si se emplea una autoridad de CA como Verisign. Por ello, en este ejercicio, el certificado será firmado por nosotros mismos. En este caso, cada vez que en un navegador se detecte este certificado, se mostrará la advertencia correspondiente y se nos solicitará que bajo nuestra propia responsabilidad lo aceptemos.

Para la primer parte, ejecutamos el siguiente comando:

keytool -genkey -keyalg RSA -keysize 2048 -dname “CN=www.se.upci.net, O=Default, C=MX” -keystore .keystore

Para que este comando tenga éxito, el directorio ‘bin’ de java debe estar incluido en el PATH del sistema. CN se refiere al nombre de dominio que estará avalado por este certificado (debe ser igual al nombre declarado en nuestro archivo ‘hosts’, por eso en este ejemplo usamos: ‘www.se.upci.net’) y la parte final incluye un ‘.keystore’ que es el nombre del almacén de claves del sistema y que será llamado de esa forma.

En caso de que se pregunte por una clave para el almacén de claves, se recomienda usar la clave por defecto que es: ‘changeit’.

Para auto-firmar el certificado, ejecutamos el siguiente comando:

keytool -certreq -keyalg RSA -file cert0001.csr -keystore .keystore

En el caso anterior, se genera un archivo llamado ‘cert0001.csr’ y nuevamente se indica la ubicación del almacén de certificados, es decir: ‘.keystore’. La herramienta pedirá una clave del almacén que será la clave por defecto: ‘changeit’.

Habilitar el protocolo de seguridad ‘https’ de tomcat

Para habilitar el puerto 8443 y el protocolo de seguridad SSL para tomcat 7, se deberá editar el archivo ‘server.xml’ ubicado en ‘CATALINA_HOME\conf’ con la siguiente información:

<Connector
port=”8443″ protocol=”HTTP/1.1″ SSLEnabled=”true”

keystoreFile=”${user.home}/.keystore”
keystorePass=”changeit” SSLCertificateFile=”/home/gustavo/cert0001.csr”

maxThreads=”150″ scheme=”https” secure=”true”
clientAuth=”false” sslProtocol=”TLS” />

Se asume que ya existe un certificado firmado en la trayectoria de ejemplo ‘/home/gustavo’ y que el almacén de llaves está en el ‘home’ del usuario.

El valor de SSLCertificateFile para windows sería, por ejemplo: ‘C:/Users/gustavo/cert0001.csr’

Nota: En caso de que el archivo cert0001.csr esté ubicado en el directorio CATALINA_HOME sólo se requiere (tanto para linux, como para windows) escribir: SSLCertificateFile=”cert0001.csr”

Nota 2: Como estamos asumiendo que el certificado actual no está firmado por un CA como Verisign, y en cambio asumimos que es un certificado auto-firmado, deberemos realizar una operación mas de forma manual, que es IMPORTAR el certificado al almacén de confianza de java, usando el siguiente comando:

keytool -import -trustcacerts -file /home/gustavo/cert0001.csr -keystore $JAVA_HOME/jre/lib/security/cacerts

Por favor, notar que lo anterior sólo es un ejemplo.
Usando el mismo ejemplo, para windows sería aslgo así como:

keytool -import -trustcacerts -file C:/Usrers/gus/cert0001.csr -keystore %JAVA_HOME%/jre/lib/security/cacerts

Instalación del servidor CAS

El servidor CAS es un software que nos ofrece un sistema de autenticación tipo SSO. Es un aplicativo tomcat, que debe ser ensamblado usando maven, ya que el bundle que se descarga contiene el código fuente del mismo.

Nota: En su versión por defecto, el servidor de CAS contiene una estrategia de autenticación de prueba que exige que el usuario y la clave coincidan. Es por ello, que antes de realizar el ensamble con maven, se deberá modificar el archivo:

CAS_HOME/src/main/webapp/WEB-INF/deployerConfigContext.xml

con la finalidad de inhabilitar la funcionalidad ‘demo’ y habilitar la funcionalidad real.

Conviene mencionar que CAS_HOME, para nuestro caso es: cas-server-webapp y está ubicado dentro de la distribución: cas-server-3.4.11

Existe una gran de formas a través de las cuales podemos establecer distintas estrategias de autenticación.
Por ejemplo, podemos basarnos en las siguientes recomendaciones:

https://wiki.jasig.org/display/CASUM/Authentication

http://static.springsource.org/spring-security/site/docs/3.0.x/reference/cas.html

https://wiki.jasig.org/display/CASUM/Best+Practice+-+Setting+Up+CAS+Locally+using+the+Maven2+WAR+Overlay+Method

Una vez realizados los cambios anteriores, se debe ejecutar el comando: mvn package desde ‘CAS_HOME’ parar generar un ‘war’ que deberá ser copiado al directorio webapps de tomcat.

Ajustar clientes Tomcat para suscripción a un servidor CAS

En la práctica existirán diversos servidores físicos que contendrán aplicativos suscritos al servidor CAS ubicado remotamente y que por ello compartan un esquema de SSO entre ellos.

Para lograr el efecto anterior, los aplicativos deberán soportar una arquitectura SS3 y deberán poseer un archivo de configuración de seguridad ‘spring’.

Los siguientes son los pasos para lograr este objetivo:

1) Incluir dependencias CAS en el pom.xml del aplicativo:

<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-cas-client</artifactId>
<version>${org.springframework.version}</version>
</dependency>
<dependency>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-client-core</artifactId>
<version>3.1.10</version>
</dependency>
<dependency>
<groupId>org.jasig.cas.client</groupId>
<artifactId>cas-client-integration-tomcat-common</artifactId>
<version>3.2.1</version>
</dependency>

2) Copiar el archivo de seguridad ‘applicationContext-security.xml’ (que se adjunta) a la carpeta de ‘spring’ de nuestro proyecto y realizar los siguientes cambios:

a) En el tag de ‘logout’ logout-success-url=”https://www.se.upci.net:8443/cas/logout”
(ojo1: se asume que hay otro servidor (en funcionamiento) en el que ya se desplegó el CAS modificado y empaquetado con maven)
(ojo2: también se asume que en ese servidor está nuestro certificado auto-firmado y que el SSL está habilitado y corriendo en el puerto 8443)
b) En el bean ‘serviceProperties’ la propiedad ‘service’ con el valor:
value=”http://localhost:18080/ej023/j_spring_cas_security_check”
SE ASUME QUE NUESTRO NUEVO APLICATIVO TIENE EL CONTEXTO: ‘ej023′ Y CORRE EN EL PUERTO 18080
c) En el bean ‘casEntryPoint’ la propiedad ‘loginUrl’ con el valor:
value=”https://www.se.upci.net:8443/cas/login”
d) En el bean ‘casAuthenticationProvider’ en la propiedad ‘ticketValidator’ que contiene un bean anónimo cuyo constructor en su primer argumento deberá llevar el valor de: “https://www.se.upci.net:8443/cas”

Nota: La máquina que contenga este aplicativo DEBE saber (gracias a su archivo ‘hosts’) que el servidor de CAS se ubica en: ‘www.se.upci.net’

 

Cheers,

Goose

© 2017 Goose Workshop Suffusion theme by Sayontan Sinha