La gran mayoría de las aplicaciones modernas necesitan un esquema de login, para que solo

puedan ingresar los usuarios permitidos y también autorizar o restringir el acceso a partes de la
aplicación, según los permisos asignados al usuario.
Esto significa asegurar que todos los usuarios que ingresen estén debidamente autenticados (es
decir, que el usuario sea quien dice ser); y autorizados (es decir, una vez que el usuario se
autentica, se le permita el acceso o no a ciertas partes de la aplicación).
En el caso de las aplicaciones Web, como estas aplicaciones tienen varios puntos de entrada,
cualquier objeto accesible por URL debe chequear permisos de autenticación.

Eso implica que cada uno de estos objetos tienen que tener incorporado el chequeo de seguridad
para hacer la verificación correspondiente.
Tradicionalmente se programa un procedimiento que contiene la lógica de control de acceso.
Este procedimiento debe verificar los roles y permisos de cada usuario que ingresa a la
aplicación.

En cada objeto accesible por URL, deberá escribirse el código que invoque a este procedimiento,
de modo de verificar la autenticación antes de que se abra el objeto.

Cuantos más roles y permisos se tengan y más complejas se hacen las políticas de seguridad de
las empresas, el código crece y se hace más complicada la verificación de permisos.
En el caso de la aplicaciones para Smart Devices, al ser aplicaciones distribuidas, una parte de
ellas se ejecuta en el propio dispositivo y la capa de negocios de la aplicación se resuelve a
través de servicios Rest que tienen una URL de acceso, por lo que están expuestos a accesos
indeseados.

Al igual que para las aplicaciones web, lo que se hace es verificar que solamente usuarios
debidamente autenticados y autorizados puedan acceder a la aplicación, evitando la ejecución de
usuarios que no cumplan con esto.
Para cubrir estas necesidades, GeneXus ofrece un módulo de seguridad, llamado GeneXus
Access Manager (GAM) que resuelve las funcionalidades de autenticación y autorización, tanto
para aplicaciones Web como para aplicaciones para Smart Devices.

El GAM está desarrollado en GeneXus por lo que se integra fácilmente a la KB de la aplicación y

permite resolver de manera centralizada todo lo referente a la Seguridad de la misma. El objetivo
es que la solución de Seguridad se utilice lo más declarativamente posible dentro de la
aplicación, sin crear complejidad adicional.

El GAM también provee un backend que permite definir usuarios, permisos, políticas de
seguridad y acceso a objetos, entre otras cosas.

Además provee una API para poder acceder a muchas de estas funcionalidades en forma
programática.

Más información: //http://wiki.genexus.com/commwiki/servlet/wiki?24746

Para habilitar el GAM se debe ir a nivel de la versión activa de la KB y configurar la propiedad
Enable Integrated Security en el valor True.

Existe otra propiedad cuando habilitamos el GAM, a nivel de version, llamada Integrated
Security Level que permite indicar el valor por defecto de la seguridad de los objetos de la KB.

Esta propiedad se encuentra también a nivel de objeto por lo que será posible personalizar la
forma en que se implementará la seguridad en ese objeto.

Hay tres valores posibles:

• None: indica que el objeto será publico, es decir no tendrá seguridad.

• Authentication: indica que sólo usuarios autenticados podran ejecutarlo.
• Authorization: indica que el usuario además de haberse autenticado, tendra que estar
autorizado para ejecutar dicho objeto, es decir tener el rol adecuado para ejecutarlo.

Una vez que tengamos las propiedades de seguridad configuradas debemos hacer un Rebuild All
de la KB. Al hacerlo, se abrirá un cuadro de diálogo que nos avisa que se instalará el módulo
GAM en nuestra KB, con la solución pronta tanto para web como para smart devices.
Para resolver la Autenticación, internamente se usa:
- Web sessions para la seguridad de aplicaciones Web
- Oauth para resolver la seguridad en el caso de aplicaciones para SD

En el caso de la Autorización, su implementación está basada en Roles utilizando el modelo Role

Based Access Control mediante el cual se encapsulan los métodos, propiedades y todo lo
necesario para el manejo de autorización en la aplicación.
El GAM provee diferentes Tipos de Autenticación, los tipos disponibles son:

Autenticación local: donde los usuarios y todas sus credenciales son almacenados en una base
de datos de la cual somos propietarios

Facebook, Twitter y Google+: aquí se utilizan los mecanismos de autenticación de estas

aplicaciones. No hay necesidad de definir usuarios locales. La autenticación se realiza en el sitio
de Facebook, Twitter o Google respectivamente.

En muchas ocasiones es necesario integrar mi aplicación con otras con las que tengo que
intercambiar información y es necesario asegurar la autenticación de mis usuarios mediante una
autenticación externa a mi aplicación.
Una forma de autenticación externa es utilizar un web service SOAP que provee la otra
aplicación y configurar al GAM para que consuma ese web service.

Custom. Puede ser posible que la otra aplicación provee un programa externo para resolver la
autenticación, pero que no necesariamente es un web service. En ese caso configuro el GAM
para aceptar una autenticación del tipo Custom.

Remote. Una aplicación que use GAM puede ser convertirse en proveedor de identidades como
Facebook, Tweeter o Google. En este caso, otras aplicaciones con GAM pueden conectarse
remotamente a este server y obtener la autenticación desde allí.

Más información:
http://wiki.gxtechnical.com/commwiki/servlet/hwikibypageid?15937
http://wiki.gxtechnical.com/commwiki/servlet/hwikibypageid?18456
Con la Autorización, definimos los permisos ejecución de los objetos y los permisos sobre los
modos de operación de las transacciones.

La definición se hace otorgando para cada objeto, permisos a cada rol y en función de cuál sea el
rol que tenga asignado el usuario, serán los permisos efectivos sobre el objeto.

Esta validación se realiza sobre los siguientes objetos Web:

- Web Panels
- Web Components con la propiedad URL Access=Yes
- Transacciones
Además, se verifican los permisos sobre los modos Insert, Update, Delete y Display de las
Transacciones Web

Y para Smart Devices de los objetos:

- Work With for Smart Devices
- Panels for Smart Devices.
Y las acciones de Insert, Update y Delete sobre los Work With for Smart Devices.

La propiedad Integrated Security Level también puede configurarse a nivel de los objetos, de
modo que pueda restringirse el acceso a sólo algunos objetos de la aplicación. En este caso
también se dispone de la propiedad Permission Prefix que determina que sobre el objeto se
realice el chequeo de seguridad de manera automática, mediante un código de seguridad que lo
agrega automáticamente el generador cuando crea el código fuente del objeto.

Más información:
http://wiki.gxtechnical.com/commwiki/servlet/hwikibypageid?17583
http://wiki.gxtechnical.com/commwiki/servlet/hwikibypageid?17918
http://wiki.gxtechnical.com/commwiki/servlet/hwikibypageid?17916
El GAM también expone una API (Application Program Interface) para acceder a sus métodos y
propiedades en caso de que sea necesario hacerlo desde nuestra aplicación.
El acceso a las propiedades y métodos de la API se realiza a través de external objects que se
importan al habilitar el GAM en nuestra aplicación, y podemos realizar varias acciones, como ser:
• Obtener el usuario que está logueado en caso que necesitemos utilizarlo dentro de la
aplicación
• O en lugar del nombre, podríamos necesitar su dirección de correo o algún otro dato
relacionado con el usuario
• También podríamos necesitar los tipos de autenticación configurados en nuestra aplicación
• O podríamos necesitar los permisos asociados a un rol, para realizar alguna acción con ellos
dentro de la aplicación

Más información: http://wiki.gxtechnical.com/commwiki/servlet/hwikibypageid?16535

Una vez que finalizamos de desarrollar y probar nuestra aplicación, es necesario ponerla en
producción. Para eso debemos seguir algunos procesos y disponemos de varias herramientas
para hacerlo.

Veamos cada caso.

Para que la aplicación ejecute en un servidor de producción es necesario transferir los archivos
resultantes de la compilación (p.ej. .class para java, o dlls de .Net, además de librerías y otros
recursos) de los objetos de nuestra aplicación y también de los objetos del GAM.
Para eso se utiliza la Application Deploy Tool (en el menú Build / Deploy application) donde se
seleccionan los objetos main que se desea desplegar y el servidor de destino, que puede ser a un
servidor local o un servidor en la nube como Amazon Web Services, Windows Azure, IBM
Bluemix y otros.
Más información: http://wiki.gxtechnical.com/commwiki/servlet/hwikibypageid?21219

Además de los datos de la aplicación (base de datos de la aplicación) se debe llevar la base de
datos del GAM.
Para eso contamos con una herramienta llamada GAM Deploy Tool. Esta herramienta puede
ejecutarse desde GeneXus o como herramienta independiente. Permite exportar desde un
repositorio o importar datos desde otro repositorio, inicializar (crear) la base de datos del GAM,
actualizar el esquema de la base de datos, etc.
Más información: http://wiki.gxtechnical.com/commwiki/servlet/hwikibypageid?18608

A fin de reducir riesgos que puedan compromenter la seguridad de la aplicación, está disponible
una checklist que sugerimos revisar cuando se pone en producción una aplicación con GAM.
Ejemplos de estas verificaciones pueden ser, Por ej. Setear el servidor web con el protocolo
HTTPS, cambiar la contraseña del administrador, borrar usuarios usados en test, revisar
permisos de acceso a usuarios, etc.
Más información: http://wiki.gxtechnical.com/commwiki/servlet/hwikibypageid?18574
Una funcionalidad que vemos cada vez más en las aplicaciones web, es la posibilidad de
autenticarse una sola vez para todas las aplicaciones que estamos usando.

El Single Sign On (o autenticación única) es el procedimiento mediante el cual un usuario se

autentica en una aplicación WEB y ya queda autenticado en el resto de las aplicaciones que
ejecuten en distintas solapas de la misma ventana del browser.

Esto puede hacerse debido a que una aplicación con GAM puede ser proveedora de identidad,
como lo hace Facebook o Google+ y otras aplicaciones con GAM pueden autenticarse a través
de la misma.

Con SSO, si todas estas aplicaciones se ejecutan en una misma instancia del brower (en
diferentes tabs), alcanza con loguearse una única vez.

Todo esto es configurable en tiempo de instalación, no requiere programación, solo configuración

del módulo de seguridad GAM.

El mecanismo de Single Sign On usado en GeneXus se basa en el estandar Oauth 2.0.

Si estoy logueado por Single Sign on y quiero desloguearme existen 3 posibilidades:

• Client Side Only – Me deslogueo de una aplicación y el resto de las aplicaciones siguen
conectadas al proveedor de identidades.
• Identity Provider & Client – Se finaliza la sesión en el cliente y también en el proveedor de
identidades. El resto de las aplicaciones van a estar vivas mientras su sesión local esté viva,
pero cuando se requiera se va a pedir login de nuevo.
• Identity Provider & All Clients – Finalizar la sesión en todos los clientes y en el provedor
de identidades.

Mas información: http://wiki.genexus.com/commwiki/servlet/wiki?25385

En este video vimos los beneficios del GeneXus Access Manager para proveernos una solución
completa de seguridad para nuestra aplicación.

Hay mucha más información sobre este tema. Para saber más, los invitamos a visitar el siguiente
link del Wiki.