diff options
Diffstat (limited to 'doc/es_ES/plugin-authentication-architecture.markdown')
| -rw-r--r-- | doc/es_ES/plugin-authentication-architecture.markdown | 99 |
1 files changed, 99 insertions, 0 deletions
diff --git a/doc/es_ES/plugin-authentication-architecture.markdown b/doc/es_ES/plugin-authentication-architecture.markdown new file mode 100644 index 00000000..86069aa0 --- /dev/null +++ b/doc/es_ES/plugin-authentication-architecture.markdown @@ -0,0 +1,99 @@ +Arquitectura de autenticación +============================= + +Kanboard provee una flexible y conectable arquitectura de autenticación. + +Por default, el usuario puede autenticarse con multiple metodos: + +- Autenticación por usuario y password (Base de datos local y LDAP) +- Autenticación OAuth2 +- Autenticación Reverse-Proxy +- Autenticación basada en Cookie (Recuerdame) + +Además, despues de una autenticación satisfactoria un puede hacerse post de autenticación Two-Factor . +Kanboard sopoarta nativamente el standart TOTP. + +Interfaces de autenticación +---------------------------- + +Para tener un sistema conectable, los drivers de autenticación deben implementar un conjunto de interfaces + +| Interface | Rol | +|------------------------------------------|------------------------------------------------------------------| +| AuthenticationProviderInterface | Interface base para otras interfaces de autenticación | +| PreAuthenticationProviderInterface | The user is already authenticated al alcanzar la aplicación, Usualmente los servidores web definen algunas variables de entorno | +| PasswordAuthenticationProviderInterface | El metodo de autenticación que usa el username y password provienen del formulario de login | +| OAuthAuthenticationProviderInterface | Proveedores OAuth2 | +| PostAuthenticationProviderInterface | Drivers de autenticación Two-Factor ,pide el código a confirmar | +| SessionCheckProviderInterface | Los proveedores que son capaces de comprobar si la sesión de usuario es válida | + +### Ejemplos de autenticación de proveedores: + +- Database por default metodos a implementar `PasswordAuthenticationProviderInterface` y `SessionCheckProviderInterface` +- Reverse-Proxy metodos a implementar `PreAuthenticationProviderInterface` y `SessionCheckProviderInterface` +- Google metodos a implementar `OAuthAuthenticationProviderInterface` +- LDAP metodos a implementar `PasswordAuthenticationProviderInterface` +- RememberMe cookie metodos a implementar `PreAuthenticationProviderInterface` +- Two-Factor TOTP metodos a implementar `PostAuthenticationProviderInterface` + +flujo de trabajo de autenticación ** Workflow ** +------------------------------------------------ + +Para cada peticion HTTP: + +1. Si la sesión de usuario esta abierta, ejecuta el registro de proveedores que implementa`SessionCheckProviderInterface` +2. Ejecuta todos los proveedores que implementa `PreAuthenticationProviderInterface` +3. Si el usuario final hace un submit al formulario del login, Los proveedores que implementa `PasswordAuthenticationProviderInterface` are executed +4. Si el usuario final quiere usar OAuth2, el selecciona el proveedor a ejecutar +5. Despues de una autenticación satisfactoria, el ultimo registro utilizará `PostAuthenticationProviderInterface` +6. Sincronizar la información del usuario si es necesario + +Este workflow es manejado por la clase `Kanboard\Core\Security\AuthenticationManager`. + +Eventos disparados: + +- `AuthenticationManager::EVENT_SUCCESS`: autenticación satisfactoria +- `AuthenticationManager::EVENT_FAILURE`: autenticación fallida + +Cada vez que se produce un evento de fallo , el contador de intentos fallidos se incrementa. + +La cuenta de usuario se puede bloquear para el período de tiempo configurado y un captcha puede ser mostrado para evitar ataques de fuerza bruta . + +Interface de usuario del proveedor +--------------------------------- + +Cuando la autenticación es satisfactoria, la `AuthenticationManager` pedura la información del usuario para que el driver llame al metodo `getUser()`. +Este metodo debe regresar un objeto que implementa la interface `Kanboard\Core\User\UserProviderInterface`. + +Esta clase abstracta reune la información dede otro sistema. + +Ejemplos : + +- `DatabaseUserProvider` proporciona información para un usuario interno +- `LdapUserProvider` para un usuario LDAP +- `ReverseProxyUserProvider` para un usuario Reverse-Proxy +- `GoogleUserProvider` represtan un usuario de Google + +Los métodos para la interface del proveedor de Usuario: + +- `isUserCreationAllowed()`: Regresa true para permitir la creación automática de usuarios +- `getExternalIdColumn()`: Obtener Identificación del nombre de la columna externa (google_id, github_id, gitlab_id...) +- `getInternalId()`: Obtener el id interno de la base de datos +- `getExternalId()`: Obtener el id externo(Unique id) +- `getRole()`: Obtener el rol de usuario +- `getUsername()`: Obtener en nombre de usuario ** username ** +- `getName()`: Obtener nombre completo del usuario +- `getEmail()`: Obtener el correo electronico del usuario +- `getExternalGroupIds()`: Obtiene los ids externos del grupo, automáticamente sincroniza la membresia del grupo y la presenta +- `getExtraAttributes()`: Obtiene los atributos extras para ser mostrados a el usuario durante la sincronización local + +No es obligatorio que el metodo devuelva un valor. + +Sincronización de un usuario local +---------------------------------- + +La información del usuario puede ser sincronizada automáticamente con la base de datos local. + +- Si el metodo`getInternalId()` regresa un valor no realiza la sincronización +- Los metodos `getExternalIdColumn()` y `getExternalId()` debe regresar un valor para sincronizar el usuario +- Las propiedades que regresan un ** String ** vacios no se sincronizan |