Reemplazando con SSO propio a Arai-Usuarios

Caso de uso

Se desea reemplazar la solución Arai-Usuarios como Proveedor de Identidad (IdP), Manejador de Identidad (IdM) y soporte de información de los diversos módulos del Expediente Electronico Integrado (EEI) como asi tambien de los diversos modulos SIU utilizando un SSO propio.

Ventajes

• Utilizar IDP/IDM propio con software conocido y en uso.
• Mantener sistemas legacy sin modificaciones.
• Mantener valores y campos actuales utilizados durante el login.

Desventajas

• Reimplementar API que brinda soporte de información a los módulos SIU.
• Personalizar el token SAML con atributos adicionales que son esperados por dichos módulos.
• Mapear atributos del token con datos del backend del IDM en caso que los valores se encuentren almacenados con otra estructura.
• Cuentas locales desvinculadas en los módulos
  • Pilagá necesita la password localmente (autorizar pagos)
  • Otras que usen la password local como 2FA
• Si se quiere vincular por mail por ejemplo, necesita personalizar apps/modulos que se encuentren como minimo en Toba 3.3.20

Llevandolo adelante

• Reimplementar API segun la version/es necesaria/s

  • Referencia API v1
  • Referencia API v2

  @TODO: Explicitar lugares donde los proyectos publiquen que recursos consumen y la version de API.

• Personalizar token SAML (describir atributos o link a donde esté)

  • Estructura Token

    uid: Identificador del usuario en formato `uuid`
    cn: Nombres del usuario
    sn: Apellido del usuario
    givenName: Nombre a mostrar en la aplicación
    jpegPhoto: Imagen del usuario en formato base64
    jpegPhotoUrl: URL donde se encuentra alojada la imagen del usuario
    mail: Email principal del usuario
    uniqueIdentifier: Nombre por convencion del usuario
    accessTo: Lista de aplicaciones accesibles
    appLauncherData: Datos informativos para SIU-Toba
    userAccounts: Lista todas las cuentas del usuario
    defaultUserAccount: Lista la cuenta con que se debe iniciar la sesion (si hay mas de una)
  

  Algunos datos en el token pueden aparecer duplicados, esto esta relacionado a los requerimientos de organización de los mismos. El formato del campo appLauncherData se puede consultar directamente en su repositorio

• En apps/módulos que utilicen al menos SIU-Toba >=v3.3.20 si se quiere autenticar por un campo alternativo que no sea la clave de la tabla interna de Toba, se necesita:

  • Iniciar una personalizacion de la app/módulo en una instalación de desarrollo
  • Explicitar en instalacion.ini el atributo adicional del token SAML que se requiere para su uso por la subclase que realice la autenticación. Esto se hará por cada instalación.

     token_atributos_extra="email"
  

  • Incorporar dicha extension en metadatos si es que no se encuentra presente dentro de las extensiones del nucleo, mediante la operación de configuración del proyecto.
  • Incorporar y/o implementar una extension de la clase toba_usuario_basico (o su derivada del módulo) redefiniendo los metodos que participan del proceso de autenticación.

  Por ejemplo, si quisieramos utilizar el email del usuario como valor para autenticarlo deberiamos incorporar como minimo los siguientes cambios:

  class siu_modulo_pers_usuario extends siu_modulo_usuario
  {
     /**
     * Se debe modificar la manera de recuperar los datos del usuario y luego proseguir con el mecanismo
     */
     static public function autenticar($email_usuario, $clave, $datos_iniciales=null, $usar_log=true)
     {
        $datos_usuario = self::get_info_autenticacion_por_email($email_usuario);
        ...
        ...
     }
  
     /**
     * Se debe modificar la manera de recuperar los datos del usuario y luego proseguir 
     */
     public function __construct($email_usuario)
     {
        $this->datos_basicos = $this->recuperame_los_datos_por_mail($email_usuario);
  
        $id_usuario = $this->datos_basicos['id'];
        $this->grupos_acceso = toba::instancia()->get_perfiles_funcionales( $id_usuario, toba::proyecto()->get_id() );
        $this->perfiles_datos = toba_proyecto_implementacion::get_perfiles_datos_usuario( $id_usuario, toba::proyecto()->get_id() );
        if (! empty($this->perfiles_datos)) {
           $this->perfil_datos = current($this->perfiles_datos);
        }
     }
  
     /**
     * Como nuestro usuario se verifica por el campo mail, debemos cambiar esta logica aqui.
     */
     static public function existe_usuario($email_usuario)
     {
        $datos_usuario = self::get_info_autenticacion_por_email($email_usuario);
        return (isset($datos_usuario) && !is_null($datos_usuario));
     }
  
     /**
     * Redefinir aquellos lugares donde deberiamos retornar el email como identificador
     */
     public function get_id_en_arai()
     {
        $usuario_arai = toba::manejador_sesiones()->get_autenticacion()->get_id_usuario_arai();
        if (! is_null($usuario_arai)) {
           return $usuario_arai;
        }
        return $this->get_email();
     }
  
     //-------------------------------------------------------------------------------------
     // Luego definir los metodos que recuperan los datos
     //-------------------------------------------------------------------------------------
  
     static protected function get_info_autenticacion_por_email($email){}
  
     protected function recuperame_los_datos_por_mail($email){}
  }