#Control de acceso

Hace unos días, publique una pregunta respecto a este tema pero la respuesta era algo mas compleja de lo que esperaba, así que para futura referencia de otras personas que tengan la misma duda he preferido documentar el proceso en un articulo. 
La premisa era la siguiente, hemos comenzado a utilizar el paquete Restforms2 para tener una api CRUD que nos permita almacenar y consultar datos en la base de datos de IRIS. Pero esto no nos permite hacer todo lo que necesitamos, ni aun empleando custom querys. Por lo tanto necesitábamos emplear métodos personalizados implementados en una integración.

Buenas a todos,

en capítulos anteriores, vimos como "Como controlar el acceso a tus recursos con OAuth2". En este primer artículo explicábamos como preparar un acceso seguro a nuestros recursos utilizando la potente herramienta que nos ofrece Intersytems del servidor de Autenticación. Al finalizar el mismo, comentábamos que si quisiéramos podríamos aplicar un control extra a este acceso y esto nos lleva a este artículo, por lo que seguiremos el siguiente índice:

1.- Introducción

   1.1..- De donde venimos

2.- Problema

   2.1.- ¿Cómo funciona la llave (Token)?

   2.

Tengo algunos modelos analíticos y numerosos paneles de control, y estoy listo para implementarlos en nuestros usuarios finales y administradores. ¿Cómo configurar DeepSee para que los usuarios no alteren las áreas de los demás y se les restrinja el uso de funciones específicas para los desarrolladores?

En la Parte 1 empezamos a trabajar en un modelo de seguridad para DeepSee y creamos un tipo de usuario con los privilegios habituales de los usuarios finales. En esta parte, crearemos un segundo tipo de usuario con permiso para editar y crear tablas dinámicas y paneles de control en DeepSee. 

Las rutinas con privilegios te permiten elevar los roles de un usuario mientras las utiliza. Estas rutinas con privilegios (Privileged Routine Application) pueden utilizarse con rutinas y también con clases / métodos.

Cuando las utilices, es importante asegurarse de incluir new $ROLES, antes de elevar los privilegios con AddRoles(). Por ejemplo:

 new $ROLES
 set status=$System.Security.AddRoles("MyPrivilegedRoutineApplication")

Por qué he decidido escribir esto

Recientemente tuve el reto de crear un método de autenticación seguro para autorizar el acceso a algunos datos, pero desafortunadamente no tenía ninguna experiencia con esas configuraciones de seguridad y sentí que me faltaban algunos conceptos básicos para entender mejor la documentación oficial.

Después de estudiar y lograr entregar las clases que me pidieron hacer, me gustaría compartir un poco de mi nuevo conocimiento, que me ayudó a seguir los temas de la documentación.

Empezando por lo básico: la santísima trinidad de los servidores

Primero, es importante entender de qué estamos hablandoexactamente. En general, tenemos datos que pueden ser sensibles, o por cualquier razón necesitan protección. Hay personas (usuarios) que podrán verlos, otras podrán cambiarlos y otras no tendrán ningún tipo de acceso. Para ocuparse de los usuarios, el acceso y los datos, tendremos tres servidores: el del cliente, el de recursos y el de autorización.

Este artículo, y los dos siguientes de la serie, se conciben como una guía para los usuarios, los desarrolladores o para los administradores de sistemas que necesiten trabajar con la estructura de OAuth 2.0 (conocido también por simplicidad como OAUTH) en aplicaciones que estén basadas en los productos de InterSystems.