Andrés González

Cuando queremos restringir el acceso a cierto recurso de nuestro
sistema podemos optar por el clásico esquema de proteger dicho
recurso con un par usuario/clave. Pero existe un tipo de accesos o
comunicaciones en el que dicho patrón no es adecuado. Estamos
hablando de las comunicaciones B2B (Business to Business),
es decir, de las comunicaciones entre sistemas, en contraste con las
comunicaciones B2C (Business to Client).

Pongamos un ejemplo: supongamos que tenemos un floreciente negocio
consistente en la venta de minutos de música on-line. Un
cliente puede comprar una licencia para escuchar música
on-line durante un cierto tiempo limitado. Para acceder al sistema el
usuario deberá conectarse a un determinado portal web e
identificarse tecleando su usuario y contraseña.

Ahora bien, cuando el tiempo de su licencia se agota, puede acudir
a la sección Recargas del portal y efectuar una recarga
de, por ejemplo, seis horas. Tras abonar el importe de la recarga
mediante una pasarela de pago, automáticamente su licencia se
recargará con seis horas. Pero mira por dónde, resulta
que el portal web y el sistema que gestiona las recargas de licencias
están alojados en máquinas diferentes y deben
comunicarse a través de internet. Para hacer posible esta
comunicación, el sistema de recargas proporciona un servicio
web(web service) accesible directamente usando HTTP.
Evidentemente, dicho servicio debe estar protegido, de forma que sólo
nuestro sistema pueda acceder a él.

En los dos párrafos anteriores se describen dos procesos de
comunicación distintos. El primero, el efectuado entre el
cliente y el portal web es la típica comunicación B2C,
donde la autenticación se realiza mediante un par
usuario/clave. En cambio, la segunda comunicación, entre el
portal web y el sistema de recargas es una comunicación B2B.
En dicho caso no tiene sentido que generemos un par usuario/clave,
puesto que quien se está identificando en esta ocasión
es un sistema, no una persona. En dicho escenario la solución
más adecuada es utilizar un certificado de cliente, que
identificará en este caso al portal web ante el sistema de
recargas.

Otro escenario donde quizá se vea mejor la utilidad de los
certificados cliente es el siguiente. Imaginemos que quien
efectúa las recargas es nuestra encantadora secretaria, Paula.
Paula tiene instalado en su PC un pequeño programilla que le
permite efectuar las recargas cuando un cliente llama por teléfono.
Imaginemos que en vez de utilizar un certificado cliente para
identificar el programa ante el sistema de recargas utilicemos un
esquema usuario/clave y codifiquemos directamente dichos valores en
el programilla en cuestión. ¿Qué pasaría
si dicho programilla se grabara en un CD para hacérselo llegar
a Paula y dicho CD se extraviara y llegara a manos del avispado
Maximino? Pues que Maximino podría instalar el programilla en
su casita y efectuar todas las recargas que quisiera sin pagar un
duro... En cambio, si lo que hacemos es identificar el PC que
efectúa la recarga mediante un certificado de cliente (se
instala en el propio sistema operativo, en el caso de Windows por
ejemplo) el programilla dejará de tener acceso al sistema de
recargas si se instala en otro ordenador.

Bueno, después de este rollo patatero vamos a lo que vamos,
a configurar nuestro tomcat para permitir este esquema de
autenticación. El tomcat permite configurar una autenticación
de este tipo, pero debe realizarse a nivel de "Connector"
(no se puede hacer a nivel de "Context" por
ejemplo). Lo que esto implica es que si queremos habilitar esta
autenticación para un servicio determinado debemos configurar
dicho servicio en un "Connector" independiente (con
su puerto, etc.)

Los parámetros de configuración del elemento
"Connector" que debemos establecer son:

1. clientAuth: true (Tomcat will require all SSL clients to present a client Certificate in order to use this socket)
2. TruststoreFile: the TrustStore file to use to validate client certificates
3. truststorePass: the password to access the TrustStore
4. truststoreType: JKS(formato de Java) o PKCS12(formato MSIE, Firefox)

Por supuesto, el Connector a configurar deberá estar configurado con SSL (ver http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html ) Por ejemplo, para configurar un servicio
en el puerto 8443 que requiera un certificado de cliente válido
para acceder a él debermos configurar un Connector
(TOMCAT_HOME/conf/server.xml) similar al siguiente:

<Connector port="8443"maxHttpHeaderSize="8192"
        maxThreads="150"minSpareThreads="25" maxSpareThreads="75"
        enableLookups="false"disableUploadTimeout="true"
        acceptCount="100"scheme="https" secure="true"
        clientAuth="true"sslProtocol="TLS"
        truststoreFile="/home/recargas/truststore" truststorePass="bliblibli"/>

El parámetro más importante es truststoreFile,
que indica la keystore (almacén de certificados de
java) donde se encuentran los certificados (bueno, las claves
públicas de los certificados, para ser más exactos) de
los clientes que podrán acceder a este servicio. Los pasos
para generar un certificado cliente (necesitaremos tener el JDK
instalado, para poder utilizar la herramienta keytool)
son los siguientes:

1. Creamos el par de claves del cliente (formato PKCS12, para
   poder importar después el certificado en nuestro explorador y
   poder testear la configuración del tomcat):
   

   
   

   /home/andres$ keytool -v -keystore
   keystore.p12 -genkey -keyalg rsa -alias RECARGAS -storetype pkcs12
   

   
   

   El keytool nos pedirá una contraseña para el
   almacén de certificados que va a crear (keystore.p12).
   Introduce, por ejemplo, blablabla. Después nos pedirá
   una serie de datos para el certificado (no son importante, pero hay
   que rellenarlos):
   

   
   

   ¿Cuáles son su nombre y apellido?: Portal Web
   musica.com
   

   
   

   ¿Cuál es el nombre de su unidad de
   organización?: Dpto. web
   

   
   

   ¿Cuál es el nombre de su ciudad o localidad?:
   Baiona
   

   
   

   ¿Cuál es el nombre de su estado o provincia?:
   Pontevedra
   

   
   

   ¿Cuál es el código de país de dos
   letras de la unidad?: es
   

   
   

   ¿Es correcto CN=Portal Web musica.com, OU=Dpto. web,
   O=musica.com, L=Baiona, ST=Pontevedra, C=es?: si
   

   
   

   Generando bit 1.024 par de claves rsa y certificado
   autofirmado (MD5WithRSA) para: CN=Portal Web musica.com, OU=Dpto.
   web, O=musica.com, L=Baiona, ST=Pontevedra, C=es
   

   
   

   Escriba la contraseña clave para <RECARGAS>
   

   
   

   Finalmente, la herramienta keytool nos preguntará una
   contraseña nueva para la clave privada de este certificado.
   Le damos a INTRO para que utilice la misma que la del almacén.
   

   
   

2. Exportamos el certificado (nos pedirá la clave del
   almacén, introducir blablabla):
   

   
   

   /home/andres$ keytool -export -file
   recargas.cert -alias RECARGAS -keystore keystore.p12 -storetype
   pkcs12
   

   
   

3. Importamos ese certificado en la truststore del
   tomcat. En este paso estaremos creando un nuevo almacén de
   certificados, esta vez para el tomcat, por lo que se nos pide una
   nueva clave para este nuevo almacén. Introduce bliblibli:
   

   
   

   /home/recargas$ keytool -import -keystore
   /home/recargas/.truststore -file recargas.cert
   

   
   

   Se nos preguntará si confiamos en el certificado después
   de mostrar sus datos por pantalla. Diremos que si.

   
   
   
   

Ahora solo resta reiniciar el tomcat. Para comprobar que la
configuración es correcta podemos intentar acceder a una
página web del tomcat con nuestro explorador. Por ejemplo,
imaginemos que accedemos a https://recargas.musica.com:8443/,
donde tenemos un tomcat recién instalado y configurado con SSL
en el puerto 8443. Veríamos la siguiente página sin
mayor problema:

Ahora, si seguimos los pasos aquí descritos, reiniciamos el
tomcat y refrescamos la página veremos lo siguiente:

El explorador detecta que el servidor está solicitando un
certificado de cliente, por lo que muestra un diálogo al
usuario instándole a que seleccione el certificado a utilizar.
Muy probablemente no tengamos ningún certificado de cliente
instalado, por lo que dicho diálogo nos muestra una lista
vacía. Le damos a "Esc" para cerrar el diálogo
y efectuamos los siguientes pasos para instalar el almacén de
certificados "keystore.p12" generado anteriormente en el
almacén de certificados de Windows (nota: probablemente, al
cerrar el diálogo el Explorer nos muestre la página del
tomcat de nuevo. Esto no quiere decir que el Explorer sea un genio y
se haya saltado nuestro mecanismo de autenticación,
simplemente nos está mostrando una página guardada en
la caché):

1. En el Explorer seleccionamos Herramientas->Opciones de
   Internet
   

   
   

2. Seleccionamos la pestaña Contenido y pinchamos
   en Certificados. En la pestaña actual (Personal)
   pinchamos en Importar y seguimos los pasos del asistente.
   Deberemos seleccionar el archivo "keystore.p12" generado
   anteriormente e introducir la contraseña del mismo
   ("blablabla"). En el último paso dejamos marcada la
   opción Seleccionar automáticamente el almacén
   de certificados en base al tipo de certificado, pulsamos
   Siguiente y Finalizar.
   

   
   

3. Ahora debemos cerrar todas las ventanas del Explorer y volver
   a arrancarlo.
   

   
   

Si intentamos acceder de nuevo a https://recargas.musica.com:8443/
veremos lo siguiente:

Pinchamos en Aceptar para que el Explorer utilice el
certificado mostrado para autenticarse y... ¡estamos dentro! :)

Una nota final. La clave privada asociada al certificado
regargas.cert se encuentra en el almacén "keystore.p12".
Cuando se exporta el certificado dicha clave no es exportada (lo cual
es bastante evidente, pero como todo esto es un poco lioso no está
de más señalarlo). Por tanto, para importar el
certificado de cliente en el firefox, por ejemplo, éste debe
acceder a "keystore.p12", no a recargas.cert

Hasta la próxima.

# posted by andresgr @ 10:43 PM