UniZar

Se quiere implementar la posibilidad de hacer login mediante SSO y tener una autenticación con SAML y autorización con Base de Datos.

En la actualidad se puede autenticar con Active Directoy, directamente en base de datos o mediante OAUTH2 de Microsoft o Google.

Se quiere hacer la autenticación más flexible y para eso se requiere una redefinición de la arquitectura.

En el archivo eda_api/config/eda_api_config.js se añadirá un valor más que determinará el tipo de autenticación. Si el valor no existe se considerará autenticación nativa ( la actual de mongo)

authentication_type con lo valores siguentes:
native: la autenticación normal de mongo.
ActiveDirecotry la autenticación actual de active directory.
remote_bbdd autenticación remota mediante una base de datos del tipo XXX que puede ser "orcl", "mysql", "postgres", "sqlserver", etc. Implementaremos orcl y postgres.
sso: mediante sso donde podemos tener un array de elementos [ google, microsoft, saml, oauth ]
sso_mixto: para una autenticación mixta donde podamos tener autenticación con sso y autorización con bbdd donde tenedremos un objeto con los valores posibles { saml y bbdd_orcl}

un ejemplo de archivo eda_api_config.js es :

module.exports = {
    //podem modificar el valor null de la bbdd per a que ens otorgui un altre valor de lectura en pantalla
    null_value: '',
    log_file: "/root/.pm2/logs/server-out.log", // log de consoltas del servidor
    error_log_file: "/root/.pm2/logs/server-error.log", // log de errores del servidor
    authentication_type: sso_mixto{
                           authentication: "saml"
                           authorization: "bbdd_orcl"
                                  } 
    
  } 

Cuando se autoriza contra una base de datos oracle. Habrá que configurar un archivo de configuración extra con las credenciales de acceso a la base de datos y la consulta sql a desarrollar. A continuación se muestra una propuesta de archivo bbdd_orcl.js:

module.exports = {
    bbdd_host:
    bbdd_user:
    bbdd_pass:
    authorization_sql: "select group_name from groups where username = ${USERNAME}"   

  } 

otro ejemplo de archivo eda_api_config.js es :

module.exports = {
    //podem modificar el valor null de la bbdd per a que ens otorgui un altre valor de lectura en pantalla
    null_value: '',
    log_file: "/root/.pm2/logs/server-out.log", // log de consoltas del servidor
    error_log_file: "/root/.pm2/logs/server-error.log", // log de errores del servidor
    authentication_type: bbdd_orcl
  } 

A continuación se muestra una propuesta de archivo bbdd_orcl.js:

module.exports = {
    bbdd_host:
    bbdd_user:
    bbdd_pass:
    authentication_sql: "select user_name from users where username = ${USERNAME} and password = ${PASSWORD}"
    authorization_sql: "select group_name from groups where username = ${USERNAME}"

  } 

otro ejemplo de archivo eda_api_config.js es :

module.exports = {
    //podem modificar el valor null de la bbdd per a que ens otorgui un altre valor de lectura en pantalla
    null_value: '',
    log_file: "/root/.pm2/logs/server-out.log", // log de consoltas del servidor
    error_log_file: "/root/.pm2/logs/server-error.log", // log de errores del servidor
    authentication_type: sso: [  google, microsoft, saml ]
  } 

En función de esa configuración la autenticación / autorización se hará siguendo esos métodos.

El protocolo será el mismo que hasta ahora:

1. Se autentica / autoriza mediante el protocolo definido
2. Se guarda la configuración del usuario y grupos a los que pertenece el usuairo en mongodb como hasta ahora.
3. Una vez que tenemos los datos en mongodb seguimos trabajando con normalidad. Porque cuando un informe pida los datos de los permisos de un usuario ya tendremos los datos copiados en nuestra bbdd interna.