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.