The online documentation is produced by a web publishing technology created by us to read the documents origins in OpenOffice Writer (ODT) and Microsoft Word (docx) formats and produces native web and PDF versions. In this way we maintain Louder project documentation update and in sync on each of its formats.
Las aplicaciones Web y Servicios Web creadas usando Kumbia Enterprise Framework pueden ser distribuidas e implementadas usando diferentes entornos dentro de una misma instancia. Cada aplicación puede constituir una arquitectura multicapa independiente con requerimientos de seguridad diferentes.
La seguridad de una aplicación puede ser implementada de 2 formas:
Declarativa Externa: Se definen los requerimientos de seguridad de una aplicación utilizando recursos externos a la misma sin intervenir de manera intrusiva en la lógica de la aplicación. La descripción de esta incluye detalles sobre como los roles acceden a los recursos de la aplicación y sus políticas.
Programacional Interna: Esta embebida en la aplicación y esta implementada en forma de decisiones de seguridad, es suficiente cuando los requerimientos de seguridad son simples y no cambian con frecuencia.
Características de Seguridad
Mecanismos adecuados de seguridad ofrecen la siguiente funcionalidad:
Previenen acceso inautorizado a información y procesos de negocio
Controlan que las actividades realizadas por un usuario no interfieran con las realizadas por otros impactando la integridad del sistema.
Protegen el los servicios del sistema de riesgos que puedan decaer la calidad del servicio proporcionada
La seguridad de aplicaciones basadas en Kumbia Enterprise Framework consiste en la implementación de componentes que ayuden a proteger los recursos de la misma. Los procesos de seguridad requieren de la implementación adecuada de autenticación, identificación, control de acceso, integridad de datos y calidad del servicio:
Autenticación: La aplicación ejecuta procesos que permiten confiar que quien hace uso de la misma es quien realmente se espera.
Autorización: Es el proceso de identificar a que conjunto de recursos puede utilizar/acceder con el propósito de establecer controles adecuados de integridad de datos y limitaciones.
Integridad de Datos: Permiten que solo usuarios ó roles autorizados alteren la información a la que se les ha permitido el acceso y que no intervengan con otros procesos de otros usuarios autenticados.
Confidencialidad ó Privacidad: Permite que la información solo esté disponible para el usuario adecuado y de la forma adecuada.
Calidad del Servicio (QoS): Permite que se ofrezca una mejor experiencia de usuario aprovechando diferentes tecnologías.
Auditoria: Permite almacenar un registro consistente que permita saber las actividades que un usuario realizo y bajo que condiciones se realizaron.
Mecanismos de Seguridad
Kumbia Enterprise Framework ofrece diferentes componentes para una adecuada implementación de seguridad tanto de aplicaciones Web como de Servicios Web empresariales:
Access Control List (ACL): Este componente permite crear listas en donde se establece a que recursos puede acceder determinados roles.
Auth: Permite realizar el proceso de autenticación utilizando diferentes adaptadores como Digest, LDAP, Bases de Datos, Kerberos5 y Radius.
AuditLogger: Permite crear registros de auditoria de las actividades realizadas en las aplicaciones.
Session: Mantiene la persistencia de sesión independiente entre aplicaciones y usuarios autenticados.
Security: Permite detectar ataques de negación de servicio ó bloquear el acceso a un cliente através de su dirección IP.
Seguridad a nivel de Capa de Aplicación
Los controladores en las aplicaciones son apropiados para establecer controles de seguridad en las aplicaciones, sin embargo, todos los requerimientos de seguridad no pueden ser controlados en profundidad desde este punto y generalmente es necesario apoyarse por firewalls u otras técnicas para aumentar la confiabilidad de un sistema.
Como cada aplicación maneja sus propios entornos de ejecución y de memoria la información de seguridad reside en forma independiente facilitando la administración de cada entorno. Cuando se utilizan servicios Web con múltiples intermediarios es posible que haya la necesidad de implementar mecanismos de seguridad compartidos y transferencia de identidad entre aplicaciones.
Las ventajas de la seguridad a nivel de aplicación incluyen:
La seguridad de cada aplicación se puede adaptar/generar de acuerdo a las necesidades de cada una.
La seguridad es optimizada con opciones especificas de cada una.
Las desventajas de este tipo de implementación son:
La aplicación es dependiente de atributos de seguridad que no pueden ser establecidos ó transferidos desde otra.
Se crea un único punto de vulnerabilidad que de ser violado expondría muchos aspectos de las aplicaciones.
Seguridad a nivel de Capa de Transporte
El uso de protocolos como HTTPS/SSL puede mejorar la seguridad desde otro punto de vista sin que pueda reemplazar la seguridad a nivel de aplicación. La seguridad a nivel de capa de transporte trata de mecanismos uno a uno en donde por medio de llaves criptográficas es posible implementar autenticación, integridad de mensajes y confidencialidad.
Certificados digitales son requeridos para implementar este tipo de seguridad. Estos están directamente asociados al servidor Web utilizado y suponen una capa de la cual el framework no puede tener control.
Las ventajas de la seguridad en la capa de transporte son:
Fácil de implementar.
Esta basado en estándares
Implementar Seguridad Declarativa
El componente de listas de control de Acceso de Kumbia Enterprise (ACL) esta integrado con el Core del framework interceptando cada petición y validando que su ejecución este permitida en el contexto actual. La seguridad declarativa está implementada usando listas de control de acceso definidas en la configuración de la aplicación mediante descriptores.
Los descriptores permiten definir la estructura de autorización de seguridad que incluye: roles, control de acceso y requerimientos de autenticación en forma externa a la aplicación.
La opción securityAccessList en la sección application del archivo config.ini permite establecer el tipo de lista de acceso que controlará la seguridad de la aplicación:
Ejemplo: Implementar seguridad declarativa desde config.ini
[application]
mode = production
name = "Project Name"
dbdate = Y-m-d
debug = Off
securityAccessList = "xml:filePath=%app-base%/security/security.xml"
Los descriptores ACL tienen el formato de un Data Source Name indicando primero el nombre del adaptador a utilizar y luego las opciones del mismo usando punto y comas para separar las mismas. Los descriptores deben ir entre comillas dobles con el fin de que ciertos caracteres no causen conflictos al leer el archivo .ini.
En el siguiente ejemplo de un descriptor de una lista de acceso basada en XML se muestra como definir los aspectos básicos de una lista. En el capítulo del componente Acl se detalla la implementación de cada parte del archivo XML.
Ejemplo: Lista ACL en XML para control de acceso
<?xml version="1.0" encoding="UTF-8" ?>
<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- ROLES DE LA APLICACION -->
<roles-collection>
<role>
<name>Public</name>
<description>Rol para usuarios no autenticados</description>
</role>
<role>
<name>EconomyCustomers</name>
<description>Usuarios con plan economico</description>
</role>
</roles-collection>
<!-- RECURSOS DE LA APLICACION -->
<resources-collection>
<resource>
<name>banking</name>
<description>Controlador para operaciones del cajero</description>
</resource>
<resource>
<name>login</name>
<description>Controlador para operaciones de inicio de sesión</description>
</resource>
</resources-collection>
<!-- CONSTRAINTS DE ACCESO -->
<access-constraint>
<role-name>Public</role-name>
<resource-name>*</resource-name>
<action-name>*</action-name>
<rule-type>deny</rule-type>
</access-constraint>
<access-constraint>
<role-name>Public</role-name>
<resource-name>login</resource-name>
<action-name>validateCredentials</action-name>
<rule-type>allow</rule-type>
</access-constraint>
<access-constraint>
<role-name>EconomyCustomers</role-name>
<resource-name>*</resource-name>
<action-name>*</action-name>
<rule-type>allow</rule-type>
</access-constraint>
<access-constraint>
<role-name>EconomyCustomers</role-name>
<resource-name>banking</resource-name>
<action-name>checkBalance</action-name>
<rule-type>deny</rule-type>
</access-constraint>
</security>
Los recursos de una aplicación para la seguridad declarativa son los controladores de la misma y sus nombres coinciden con estos en las opciones resource-name en el ejemplo. La asociación recurso-controlador ofrece un potente sistema de control para cada petición a la aplicación de forma transparente para el desarrollador.
El rol con el cual se realizan las validaciones de seguridad es el definido mediante el método del componente Security llamado setActiveRole(string $roleName), cuando el rol no se ha definido aún se usa la convención para el rol Public de tal forma que se asuma que la aplicación es pública ó no se ha definido identificación de quien usa la aplicación.
Los recursos que no se han mencionado en las listas de acceso tienen por defecto la política 'Allow' con lo que se hacen públicos con solo acceder a ellos.
Por cada petición a la aplicación el método Security::checkResourceAccess valida si el rol activo tiene acceso al recurso solicitado. Cuando se tiene acceso al recurso el proceso de negocio en la acción del controlador se ejecuta normalmente, cuando la validación falla, la aplicación trata de enrutar a la acción del controlador llamada unauthorizedAccessAction.
Implementar Seguridad Programacional
La seguridad programacional esta embebida en la aplicación y esta implementada en forma de decisiones de seguridad. Es más útil cuando la seguridad declarativa resulta muy básica y no se adapta a las necesidades de negocio.
En este punto los filtros de controladores y el punto de entrada a la aplicación ControllerBase resultan apropiados para definir las reglas de seguridad y aplicar el API de los componentes Acl y Auth para controlar los procesos requeridos.
Definir Realms, Usuarios y Grupos para Autenticación
Los Realms son colecciones de usuarios los cuales pueden o no pertenecer a un determinado grupo y son controlados mediante una misma política de autenticación. Normalmente una aplicación establece controles como un usuario y contraseña antes de proporcionar acceso a un recurso protegido, los datos proporcionados por un usuario se validan en forma de credenciales produciendo un resultado de éxito del proceso de autenticación. Kumbia Enterprise Framework ofrece diferentes adaptadores de autenticación usando el componente Auth.
En algunos casos los usuarios de las aplicaciones tienen asignados roles, esto indica que hacen parte de grupos con características se seguridad definidas en un dominio de aplicación.
Realms
Los realms son bases de datos de usuarios y grupos que contienen las credenciales necesarias para controlar una política de autenticación. Debido a la flexibilidad del componente de autenticación Auth es posible crear bases de datos de autenticación en varios formatos cada uno con características distintas.
Usuarios
Los usuarios son identidades individuales que son reconocidos por la aplicación. Un usuario puede tener roles asociados que permiten conocer que recursos pueden acceder de acuerdo a una política de seguridad.
Grupos
Los grupos representan una serie de características compartidas por uno o varios usuarios. Un grupo es un conjunto de usuarios que comparten los mismos accesos y controles de seguridad en la aplicación.
