WSO2

Descifrando datasources en WSO2

Crear un datasource desde la consola de WSO2 Carbon es una tarea simple y si trabajamos con la familia de productos de WSO2 puede que te resulte una tarea trivial.

En este artículo queremos mostrarte algunas de las magias que pasan bajo el capó.

Cuando finaliza el proceso de creación de un nuevo datasource, éste de forma automática se cifra. Para cifrar esta información usa los certificados indicados en el archivo carbon.xml.

Ahora bien, ¿Qué pasa si los certificados cambian?

Pues que todos los datasources que hayamos creado, se quedarán ilegibles, debido a que el nuevo certificado no puede descifrar el contenido, perdiendo así, la información contenida en los archivos de configuración de los datasources.

En este artículo hablaremos acerca de las posibles soluciones que hay para no perder los datasources que hayan creado, además de cómo configurarlo.

1. ¿Qué son los datasources?

Los datasources son las fuentes de datos de las conexiones a las base de datos, es decir, se definen ciertas credenciales como son driver, usuario, contraseña y cadena de conexión, para poder almacenarlas para su posterior uso.

2. ¿Cómo crear un datasource?

Para poder crear un datasource debemos iniciar sesión en la consola de WSO2 (/carbon). En el menú de la izquierda hacemos clic en Configure > Datasources y después en añadir Datasource

Por defecto, cuando arrancamos un Enterprise Integrator, tendremos 3 datasources predefinidos (IN_MEMORY_SAMPLE_DS, ECHO_SAMPLE_DS y WSO2_CARBON_DB), y podemos visualizarlo, haciendo clic en View.

Cuando creamos un datasource, como podemos ver en la siguiente imagen, deberemos definir una serie de campos obligatorios:

  • Datasource Type: es el tipo, por defecto se usa, las Base de Datos Relaciones.

  • Name: es el nombre único que le daremos a la cadena de conexión.

  • Datasource Provider: es el proveedor de la fuente de datos.

  • Database Engine: es el motor de la base de datos que se usará.

  • Driver: driver interno que se empleará para la conexión a la base de datos.

  • URL: conexión a la base de datos.

  • User Name: usuario de la cadena de conexión.

  • Password:  contraseña del usuario.

Después de definir estos parámetros, podremos probar un test de connection, y si va todo correcto, guardamos y ya tendremos creado nuestro primer datasource.

3. Problemas con los cambios de certificados

Unos de los principales problemas que nos podemos encontrar con los datasources, es a la hora de generar un nuevo certificado cuando ya se hayan creado los datasources. Cuando creamos un datasource desde la consola de WSO2, esta pasa a cifrarse con el certificado de wso2carbon.jks que haya actualmente, al cambiar el certificado, nos encontraremos que el datasources que hemos creado no esta, además de que en el log, nos mostrará el ERROR.

[XXXX-XX-XX XX:XX:XX,XXX] [EI-Core] ERROR - DataSourceRepository Error in updating data source 
[remove:false] at path '/repository/components/org.wso2.carbon.ndatasource/WSO2_Datasource': 
Error in updating data source 'WSO2_Datasource' from registry [remove:false]: Error in secure 
load of data source meta info: An error occurred while decrypting data.

org.wso2.carbon.ndatasource.common.DataSourceException: Error in updating data source 
'WSO2_Datasource' from registry [remove:false]: Error in secure load of data source meta 
info: An error occurred while decrypting data.

Como podemos apreciar, nos da un error a la hora de cargar los datos del datasource que hemos creado, y cuando accedemos a la consola de WSO2, el datasource no aparecerá.

4. Cómo solventar el problema con los datasources: Soluciones

En este apartado hablaremos de las posibles soluciones que podemos utilizar para solucionar el problema con los datasources y las ventajas e inconvenientes de cada uno de ellos:

  • Definición en master-datasources.xml.
  • Generación de certificados exclusivos.
  • Recreación de los datasources.

4.1. Definición en master-datasources.xml

La primera solución que vamos a ver, es la creación del datasource, definiéndolo en el fichero de configuración de master-datasources.xml, ubicado en {carbon.home}/conf/datasource/. En este fichero de configuración ya encontraremos un el datasource  WSO2_CARBON_DB creado.

Para crear un datasource, deberemos crear un nuevo campo, en el cual definiremos el datasource que hemos creado con anterioridad desde la Consola de WSO2, con los mismos campos.

        <datasource>
            <name>WSO2_Datasource</name>
            <description>New datasource</description>
            <jndiConfig>
                <name>jdbc/WSO2CarbonDB</name>
            </jndiConfig>
            <definition type="RDBMS">
                <configuration>
                    <url>jdbc:h2:./repository/database/WSO2CARBON_DB;DB_CLOSE_ON_EXIT=FALSE;
LOCK_TIMEOUT=60000</url>
                    <username>wso2carbon</username>
                    <password>wso2carbon</password>
                    <driverClassName>org.h2.Driver</driverClassName>
                    <maxActive>50</maxActive>
                    <maxWait>60000</maxWait>
                    <testOnBorrow>true</testOnBorrow>
                    <validationQuery>SELECT 1</validationQuery>
                    <validationInterval>30000</validationInterval>
                    <defaultAutoCommit>false</defaultAutoCommit>
                </configuration>
            </definition>
        </datasource>

Una vez definido, arrancamos el producto, y cuando accedemos al datasources, veremos que se nos habrá creado el datasource:

Como podemos ver, se nos ha creado el datasource, y aunque cambiemos el certificado no habrá problemas a la hora de perder el datasource.

Ahora vamos a analizar las ventajas e inconvenientes que tiene esta configuración:

  • Ventajas:
    • No es necesario estar recreando el datasource cada vez que se cambie de certificado.
  • Inconvenientes:
    • Contraseña de la base de datos legible, problemas de seguridad.
    • No podremos editar los datasources y para ellos deberemos hacerlo desde el fichero de configuración y deberemos reiniciar el producto.

Esta es la primera solución que veremos, una alternativa para que la contraseña no quede en claro, es implementarlo con Secure Vault, para que la contraseña pase a ser encriptada.

4.2. Generación de certificados exclusivos.

La segunda alternativa, es la creación de un nuevo certificado exclusivo para el cifrado internos de WSO2, al crear un certificado que tendrá uso exclusivo interno, podremos darle una mayor durabilidad de tiempo, para no estar cambiando el certificado.

La configuración que debemos hacer es la siguiente:

  1. Generación de un certificado, podemos almacenarlo en nuevo certificado dentro del wso2carbon.jks o crear un nuevo almacén para este nuevo certificado.
  2. Editar el fichero carbon.xml, en {carbon.home}/conf/, iremos al apartado InternalKeyStore, y editaremos la configuración, especificando nuestro nuevo certificado:
  • Location: ubicación del nuevo almacén de claves.
  • Password: contraseña del almacén de claves.
  • KeyAlias: es el nombre que le hemos puesto al nuevo certificado.
  • KeysPasswrod: es la contraseña del nuevo alias creado.
<InternalKeyStore>
    <!-- Keystore file location-->
    <Location>${carbon.home}/repository/resources/security/new_store.jks</Location>
    <!-- Keystore type (JKS/PKCS12 etc.)-->
    <Type>JKS</Type>
    <!-- Keystore password-->
    <Password>pass_new_store</Password>
    <!-- Private Key alias-->
    <KeyAlias>new_alias</KeyAlias>
    <!-- Private Key password-->
    <KeyPassword>pass_alias</KeyPassword>
</InternalKeyStore>

Una vez aplicada esta configuración, podremos regenerar el certificado de wso2carbon, que se encuentra en wso2carbon.jks, ya que no lo usaremos para el cifrado interno.

Está configuración que hemos realizado, conlleva a que todo cifrado interno de WSO2, se haga por medio de este nuevo certificado, no es necesario el guardar el certificado en un nuevo almacén de claves, también podemos almacenarlo en el propio wso2carbon.jks

Ahora vamos a analizar las ventajas e inconvenientes que tiene esta configuración:

  • Ventajas:
    • El datasource pasa a estar cifrado con un certificado que caducará en función de los años que le hayamos indicado al nuevo certificado.
    • Los datasources pasan a estar cifrados.
  • Inconvenientes:
    • Habrá que cambiar el certificado cuando éste caduque, pero a diferencia del primer caso, el tiempo de expiación lo indicamos nosotros mismos.

4.3. Recreación de los datasources

La tercera y última alternativa es la recreación de los datasources que se han perdido al cambiar el certificado.

Ahora vamos a analizar las ventajas e inconvenientes que tiene esta configuración:

  • Ventaja:  Los datasources están cifrados.
  • Inconveniente: Cada vez que se cambie de certificado, supondrá recrear los datasources de nuevo.

5. Conclusión

En conclusión, podemos apreciar que la configuración de los datasources es un tema delicado, y cada configuración que podemos realizar tienen sus ventajas y sus inconvenientes.

A la hora de decidir cuál es la mejor, podríamos elegir la segunda opción, ya que nos permite cambiar de certificado anualmente sin necesidad de recrear los datasources.

Por otra parte, otra opción sería elegir la primera opción, definir los datasources en un fichero de configuración, y luego usar el Secure Vault, para encriptarlo.

En definitiva, los datasources son un tema a tener mucho cuidado, por el cifrado interno que utilicemos, además de la caducidad del certificado que estemos empleando para WSO2, por lo que antes de arrancar el servicio, deberemos decidir cual de estas opciones elegir, para luego no tener problemas cuando se nos caduque el certificado y necesitemos recrear uno nuevo.

secure-vault-ebook-es

Cómo implantar Secure Vault en tu empresa

Aprende paso a paso cómo implantar WSO2 Secure Vault con esta guía tutorial, conviértete en un experto y añádele una capa extra de seguridad a tus datos.

Written By

Daniel Bascón

Systems Analyst