# Devkron Basic Web Layer (BWL)

Habilita un modelo coherente de acceso a los recursos del sitio Web.

Se basa en el Resourse Access Authorization Model (RAAM) de Induxsoft

## Componentes

* Proveedor de identidades (IDP). Verifica la validez de un identificador (token) de sesión y recupera información del usuario.
* API de Operaciones del Sistema de Archivos (FSO API). Proporciona un mecanismo para gestionar privilegios y metadatos, así como realizar operaciones sobre los archivos y carpetas del sitio Web.
* Controlador de autorizaciones (auth.dk). Autoriza el acceso a los recursos y reúne información de sesión apoyándose en el IDP y la API de FSO.

## Flujo de autorización
Aprovechando el modelo del flujo de la solicitud HTTP de Devkron, el programa auth.dk provisto en la BWL agrega el miembro ```session``` al objeto ```@http_context``` con información del usuario y el recurso solicitado.

auth.dk cargará el programa del IDP que deberá agregar al miembro ```session``` el campo ```user``` si es posible recuperar un token de sesión válido.

De manera predeterminada, auth.dk buscará el programa del IDP en ```/_protected/idp/default.dk```

Luego, auth.dk con el apoyo de FSO recuperará información del archivo o carpeta indicada (por el URI) y la pondrá a disposición a través del campo ```resource``` de ```session```

Si no hay un token de sesión disponible en la solicitud o éste no es válido, no existirá el campo ```user``` en ```session```.

Si el token recibido ha podido comprobarse, además del miembro ```user``` en session, se agregará el campo ```authforuser``` al miembro ```resource``` de ```session``` con la lista de privilegios del recurso que han podido verificarse que tiene disponibles el usuario sobre el recurso.

El siguiente bloque en JSON ilustra el contenido del objeto ```@http_context``` con el miembro ```session``` anexado:

```
{
  "request":{...},
  "response":{...},
  "session": {
        "user": {
            "ids": "ce59246a401441af8d1735bbb2764ec6",
            "uid": "C248E9BAF92411E5AA35C04A000418D7",
            "name": "ADMIN",
            "multifactor": 0,
            "verified_email": 0,
            "verified_mobile": 1,
            "memberships": {
                "workspaces": [
                    "0f251c4fa95c4a579ed1c2f8e75e1a4c"
                ],
                "teams": [
                    "87b65838ecde4ce4b88c5328d27ad4e5"
                ],
                "roles": [
                    "a200c6efd6654d7d91c545400e9f4267"
                ]
            }
        },
        "resource": {
            "type": "folder",
            "fullpath": "/",
            "path": null,
            "name": "",
            "creation": "2022-04-01T06:06:03",
            "lastaccess": "2022-04-16T08:56:17",
            "lastwrite": "2022-04-16T08:56:17",
            "privileges": {
                "admin": [
                    {
                        "user": "C248E9BAF92411E5AA35C04A000418D7"
                    }
                ]
            },
            "priv_inherited": 0,
            "authforuser": [
                "admin"
            ]
        }
    }
}
```

## Acerca de los 4 Privilegios básicos

BWL prevé la existencia de 4 privilegios básicos:

* read - Solo lectura, este es el único privilegio que NO DEBE establecer explícitamente para que se permita al servidor responder contenido sin requerir autenticación.
* write - Escritura
* plus - Propósito general, usualmente empleado para elevar a otro privilegio, por ejemplo read+plus sería "casi" equivalente a write
* admin - Administrador del sistema (sin restricciones).

auth.dk únicamente verifica el privilegio 'read', la validación de los demás corre a cargo de la API FSO o se deja bajo la responsabilidad de otras capas de aplicación.

Por convención impuesta por la BWL y compatibilidad, si se definen privilegios adicionales para operaciones específicas, debe proporcionarse un *Mapa de resolución de privilegios* para poder resolver siempre cualquier privilegio personalizado definido por capas superiores en términos de los 4 privilegios básicos. Un ejemplo es FSO API que define privilegios propios, pero también a la función ```dklfso.authOp``` que contiene la lógica del mapa de resolución de privilegios.