UniZar

Característica #2265

Updated by Juanjo Ortilles 6 months ago

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** **remote_bbdd_XXX** 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 : 

 ``` javascript 
 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" 
                                   }  
   }  
 ``` 
 

 otro ejemplo de archivo eda_api_config.js es : 

 ``` javascript 
 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: remote_bbdd:{ 
                                       type: "orcl"   
                                      } remote_bbdd_orcl 
   }  
 ``` 

 otro ejemplo de archivo eda_api_config.js es : 

 ``` javascript 
 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.  

Back