El siguiente tutorial explica como poner en funcionamiento un sistema simple de autenticación y autorización utilizando el componente Auth de la extensión app del framework.

Importante: si está usando memcached con la aplicación, al momento de actualizar los grupos de un usuario o los permisos de los grupos sobre recursos el usuario deberá cerrar sesión y volver a ingresar para que los cambios sean actualizados.

La extensión app provee un sistema de autenticación y autorización que hace uso de usuarios, roles y permisos. Los roles se definen a través de grupos a los que pueden pertenecer los usuarios y los permisos son asignados a los grupos. De esta forma un usuario podrá pertenecer a uno o más grupos y tener los permisos de todos ellos.

Existen 4 tablas, con sus 4 mantenedores, disponibles en el módulo Module_Sistema.Usuarios:

• usuario: tabla de usuarios del sistema
• grupo: usuarios del sistema a los que pueden pertenecer los usuarios
• usuario_grupo: relación entre usuarios y los grupos a los que pertenencen. No es necesario usar este mantenedor, ya que a través del mantenedor de usuarios se pueden editar directamente los grupos de un usuario. Pero se deja porque es útil para obtener los listados de usuarios que pertenecen a cierto grupo.
• auth: esta tabla es la que asigna los permisos sobre recursos que tiene un grupo. Se explica en detalle a continuación como funciona esta tabla.

El mantenedor de la tabla auth permite definir nuevos permisos que tendrá un grupo sobre cierto recurso. Al agregar un nuevo permiso se solicitará el grupo que tendrá acceso y el recurso al que se quiere dar acceso.

El recurso corresponde al identificador del recurso sobre el que el grupo tendrá acceso. Por lo general será una URI, esta URI será sólo la parte de la solicitud de la URL. O sea, si la página de inicio se accede como example.com/sitio y las solicitudes son del tipo example.com/sitio/controlador/accion entonces el recurso será /controlador/accion.

Las URIs serán evaluadas de forma exacta, sin embargo hay casos, como la edición de un registro o eliminación, que requieren un ID y no se puede poner ese ID como parte del recurso al que se da el permiso. Para estos casos los permisos se definen con una terminación en * Ejemplo, para dar acceso al grupo passwd al mantenedor de usuarios se podrían definir los permisos a los siguientes recursos:

/sistema/usuarios/usuarios/listar
/sistema/usuarios/usuarios/crear
/sistema/usuarios/usuarios/editar/*
/sistema/usuarios/usuarios/eliminar*

Sin embargo, si lo que se desea es dar acceso a todas las opciones del mantenedor de usuarios, los 4 permisos anteriores se pueden resumir en:

/sistema/usuarios/usuarios*

En el fondo, el * permite que se haga match con cualquier URI que inicie con lo que está antes del *

Importante: se asume una instalación existente para un proyecto (base de datos creada y configurada en Config/core.php entre otros).

Cargar esquema según base de datos:

• Schema y datos para PostgreSQL
• Schema y datos para MariaDB/MySQL

Se utilizará la extensión app, para esto se debe editar el archivo webroot/index.php dejando la variable $_EXTENSIONS como sigue:

$_EXTENSIONS = ['sowerphp/app', 'sowerphp/general'];

Listo!!, si, así de fácil, la extensión app carga por defecto el componente Auth y ya trae incluídos los Controladores, Modelos y Vistas necesarias para tener el sistema funcionando.

Para iniciar sesión ir a http://example.com/usuarios/ingresar El usuario por defecto es admin con contraseña admin Para cerrar sesión ir a http://example.com/usuarios/salir

La autenticación previa es un mecanismo que permite a un usuario acceder a la aplicación web sin tener que volver a colocar sus credenciales, ya que un tercero confiable lo ha autorizado previamente. Esto sirve, por ejemplo, cuando un usuario ya ha iniciado sesión en otro software y queremos que pase a nuestra aplicación sin tener que volver a ingresar su usuario y contraseña.

La URL para pre-autenticación es la siguiente:

https://example.com/usuarios/preauth/PREAUTH_TOKEN/USER/URI_REDIRECT

Donde los valores son:

• PREAUTH_TOKEN: tiene dos posibles valores, puede ser:
  1. El hash del usuario (en cuyo caso el USER no se indica o es 0 si se usa URI_REDIRECT).
  2. Un token temporal (válido por el día) formado por una clave compartida entre la aplicación web y el tercero.
• USER: nombre del usuario que se desea autenticar si se está usando el tipo 2 de PREAUTH_TOKEN.
• URI_REDIRECT: recurso codificado en base64 a donde se debe redireccionar al usuario una vez autenticado (opcional)

Por defecto la pre-autenticación está desactivada, para habilitarla se debe realizar la siguiente configuración:

\sowerphp\core\Configure::write('preauth', [
    'enabled' => true,
    'key' => 'pre-shared-key', // clave compartida entre aplicaciones para autenticar con token de tipo 2
]);

Si se usa el tipo 2 de PREAUTH_TOKEN se deberá construir el token de la siguiente forma:

$preauth_token = md5($usuario.date('Ymd').$key);

Donde $usuario es el usuario que se desea pre-autenticar y $key es la clave compartida entre ambas aplicaciones.

El mismo proceso de pre-autenticación se puede hacer enviando los datos por POST en vez de usar GET con la URL. En dicho caso los campos a enviar por POST son token, usuario y url.

Importante: si el usuario tiene habilitada la autenticación secundaria, esta será revisada al momento de hacer la pre-autenticación.