actkit: a framework for the definition and enforcement of role, content and context-based access...

10
Abstract— This work describes a framework, called ACTkit, for the definition and enforcement of dynamic access control policies on (multi-tiered) information systems. ACTkit embodies a language for defining security policies built out of role-, context- and content-based access control rules and an access control module responsible for the policy enforcement. A model, which has been defined as an extension of Hierarchical RBAC to provide a precise semantics for the security policies, is also presented and discussed. Keywords— Authorization, RBAC, Application Security, Context-based and Content-based Access Control. I. INTRODUCCIÓN. L AVANCE en los sistemas informáticos en las últimas décadas ha incrementado la interacción entre los usuarios y las aplicaciones. En consecuencia las aplicaciones han aumentado el volumen, sensibilidad y tipo de la información que gestionan, generando requisitos críticos de seguridad y la necesidad de aplicar reglas dinámicas de control de acceso a la información, o más precisamente, reglas cuya satisfacción depende del estado del sistema. Este tipo de reglas de control de acceso, denominadas en la literatura content based y context based [13], son usualmente programadas en un módulo de seguridad, implementado como un componente del sistema de información, o alternativamente, la definición y aplicación de las mismas se distribuye entre los componentes del sistema. A continuación se provee una breve descripción de un framework que se ha desarrollado para la definición y aplicación (enforcement) de políticas de control de acceso en sistemas de información. Dicho framework extiende modelos ya existentes para poder satisfacer requerimientos de seguridad que dependan de condiciones dinámicas y además permitan una visualización controlada de la información. Por ejemplo, poder definir una política que indique que la ejecución de una funcionalidad de un sistema en un determinado horario sólo se realice si el usuario solicitó autorización a un supervisor y la misma fue aprobada, o que ciertos datos solo sean visibles a determinados usuarios. Este framework permite aplicar dichas políticas y se ha denominado ACTkit (Access Control Toolkit) proveyendo dos componentes básicos (ver Fig. 1): 1. Un lenguaje para la definición de políticas de control G. Betarte, Instituto de Computación, Facultad de Ingeniería, Universidad de la República, Uruguay, [email protected] A. Gatto, Tilsor S.A., Montevideo, Uruguay, [email protected] R. Martínez, Tilsor S.A., Montevideo, Uruguay, [email protected] F. Zipitría, Instituto de Computación, Facultad de Ingeniería, Universidad de la República, Uruguay, [email protected] de acceso (ACTkit-L), y su correspondiente intérprete (ACTkit-I), 2. Un módulo (ACTkit-ACM) para realizar el enforcement de las políticas definidas en ACTkit-L y para computar la validez de un intento de acceso a un recurso protegido. ACTkit-I Definición de políticas mediante el lenguaje Interpretación de las políticas expresadas en ACTkit-L lenguaje interpretado por ACTkit-L ACTkit- ACM Instanciación de las políticas en Enforcement de las políticas definidas en ACTkit-L Figura 1. Componentes del framework ACTkit. El lenguaje ACTkit-L permite definir políticas de control de acceso usando el paradigma (Hierarchical) RBAC [14][6][12], incorporando además la posibilidad de que las reglas puedan predicar sobre el dominio de información y valores contextuales definidos por el entorno de ejecución. Estos predicados constituyen lo que se denomina las condiciones de la regla. La definición de una política de seguridad en ACTkit-L es independiente de la plataforma tecnológica utilizada para la construcción y ejecución de las aplicaciones. El lenguaje permite definir reglas dinámicas basadas en información del dominio de la aplicación, así como también basadas en el contexto de ejecución. Las reglas de control de acceso que se pueden definir en el sistema son complementadas por lo que denominamos limitaciones. Las limitaciones se caracterizan por agregar verificaciones adicionales en la ejecución, permitiendo mayor control sobre la actividad de los usuarios. Por ejemplo, es posible definir una regla de control de acceso que autorice a un usuario a efectuar una determinada operación, y complementar dicha regla con una limitación que le exija solicitar una autorización a su supervisor. En dicho ejemplo la limitación exige que el usuario deba solicitar una autorización a su supervisor y sea aprobada. Luego de cumplida esta condición el usuario puede ejecutar la operación. Notar que la limitación está agregando una restricción adicional (que no puede ser representada por las reglas content based y context based) a la regla de control de acceso que autoriza a ejecutar una operación. El intérprete ACTkit-I es el componente que permite impactar una política dada sobre una plataforma tecnológica particular. Actualmente se cuenta con una implementación del intérprete que genera código para plataformas de ejecución que soportan E ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies G. Betarte, A. Gatto, R. Martínez and F. Zipitría 1742 IEEE LATIN AMERICA TRANSACTIONS, VOL. 10, NO. 3, APRIL 2012

Upload: gustavo

Post on 10-Mar-2017

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies

Abstract— This work describes a framework, called ACTkit, for the definition and enforcement of dynamic access control policies on (multi-tiered) information systems. ACTkit embodies a language for defining security policies built out of role-, context- and content-based access control rules and an access control module responsible for the policy enforcement. A model, which has been defined as an extension of Hierarchical RBAC to provide a precise semantics for the security policies, is also presented and discussed.

Keywords— Authorization, RBAC, Application Security, Context-based and Content-based Access Control.

I. INTRODUCCIÓN.

L AVANCE en los sistemas informáticos en las últimas décadas ha incrementado la interacción entre los usuarios

y las aplicaciones. En consecuencia las aplicaciones han aumentado el volumen, sensibilidad y tipo de la información que gestionan, generando requisitos críticos de seguridad y la necesidad de aplicar reglas dinámicas de control de acceso a la información, o más precisamente, reglas cuya satisfacción depende del estado del sistema. Este tipo de reglas de control de acceso, denominadas en la literatura content based y context based [13], son usualmente programadas en un módulo de seguridad, implementado como un componente del sistema de información, o alternativamente, la definición y aplicación de las mismas se distribuye entre los componentes del sistema. A continuación se provee una breve descripción de un framework que se ha desarrollado para la definición y aplicación (enforcement) de políticas de control de acceso en sistemas de información. Dicho framework extiende modelos ya existentes para poder satisfacer requerimientos de seguridad que dependan de condiciones dinámicas y además permitan una visualización controlada de la información. Por ejemplo, poder definir una política que indique que la ejecución de una funcionalidad de un sistema en un determinado horario sólo se realice si el usuario solicitó autorización a un supervisor y la misma fue aprobada, o que ciertos datos solo sean visibles a determinados usuarios. Este framework permite aplicar dichas políticas y se ha denominado ACTkit (Access Control Toolkit) proveyendo dos componentes básicos (ver Fig. 1):

1. Un lenguaje para la definición de políticas de control

G. Betarte, Instituto de Computación, Facultad de Ingeniería, Universidad

de la República, Uruguay, [email protected] A. Gatto, Tilsor S.A., Montevideo, Uruguay, [email protected] R. Martínez, Tilsor S.A., Montevideo, Uruguay, [email protected] F. Zipitría, Instituto de Computación, Facultad de Ingeniería, Universidad

de la República, Uruguay, [email protected]

de acceso (ACTkit-L), y su correspondiente intérprete (ACTkit-I),

2. Un módulo (ACTkit-ACM) para realizar el enforcement de las políticas definidas en ACTkit-L y para computar la validez de un intento de acceso a un recurso protegido.

ACTkit-I

Definición de políticas mediante el lenguaje

Interpretación de las políticas expresadas en ACTkit-L

lenguaje interpretado porACTkit-L

ACTkit-ACM

Instanciación de las políticas en

Enforcement de las políticas definidas en ACTkit-L

Figura 1. Componentes del framework ACTkit.

El lenguaje ACTkit-L permite definir políticas de control

de acceso usando el paradigma (Hierarchical) RBAC [14][6][12], incorporando además la posibilidad de que las reglas puedan predicar sobre el dominio de información y valores contextuales definidos por el entorno de ejecución. Estos predicados constituyen lo que se denomina las condiciones de la regla. La definición de una política de seguridad en ACTkit-L es independiente de la plataforma tecnológica utilizada para la construcción y ejecución de las aplicaciones. El lenguaje permite definir reglas dinámicas basadas en información del dominio de la aplicación, así como también basadas en el contexto de ejecución. Las reglas de control de acceso que se pueden definir en el sistema son complementadas por lo que denominamos limitaciones. Las limitaciones se caracterizan por agregar verificaciones adicionales en la ejecución, permitiendo mayor control sobre la actividad de los usuarios. Por ejemplo, es posible definir una regla de control de acceso que autorice a un usuario a efectuar una determinada operación, y complementar dicha regla con una limitación que le exija solicitar una autorización a su supervisor. En dicho ejemplo la limitación exige que el usuario deba solicitar una autorización a su supervisor y sea aprobada. Luego de cumplida esta condición el usuario puede ejecutar la operación. Notar que la limitación está agregando una restricción adicional (que no puede ser representada por las reglas content based y context based) a la regla de control de acceso que autoriza a ejecutar una operación. El intérprete ACTkit-I es el componente que permite impactar una política dada sobre una plataforma tecnológica particular. Actualmente se cuenta con una implementación del intérprete que genera código para plataformas de ejecución que soportan

E

ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based

Access Control PoliciesG. Betarte, A. Gatto, R. Martínez and F. Zipitría

1742 IEEE LATIN AMERICA TRANSACTIONS, VOL. 10, NO. 3, APRIL 2012

Page 2: ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies

el lenguaje Java [10]. El módulo ACTkit-ACM expone, en primer lugar,

funciones de control de acceso a las aplicaciones, basados en las políticas previamente definidas. El servicio básico a brindar es, naturalmente, el de controlar el acceso a las funcionalidades de una aplicación. Más precisamente, en determinar si una entidad que ha sido autenticada está autorizada o no a la ejecución de una operación del sistema. Esta autorización contempla los mecanismos definidos por el modelo RBAC, verificando la existencia de un rol que habilite al usuario a ejecutar la operación, así como los valores de variables de un cierto contexto y que los argumentos de la operación dependan de los datos de la transacción en cuestión.

ACTkit-ACM también provee mecanismos para implementar visualización controlada de la información. Esto consiste en asegurar que a los usuarios de las aplicaciones solamente se le haga (visualmente) disponible información a la que está autorizado a acceder de acuerdo a sus privilegios. En este contexto, por información se entiende las funcionalidades (operaciones de la aplicación) que pueden ser invocadas y los datos del sistema.

Las funciones de seguridad provistas por el módulo pueden ser consumidas por aplicaciones que desean controlar el acceso a sus recursos. Para lograr esto, en primer lugar, se deben determinar los requerimientos de control de acceso de la aplicación. Luego definir usando ACTkit-L la política de control de acceso que los exprese y finalmente generar el código compilado utilizando el intérprete ACTkit-I. Para poder efectivamente aplicar una política, el sistema debe ser integrado con el módulo de control de acceso. La integración se debe realizar a nivel de presentación (interfaz gráfica) y a nivel lógico. La integración del módulo de control de acceso con la presentación de las aplicaciones es para controlar las funcionalidades que pueden visualizar los usuarios. Es decir, a cada usuario se le debe desplegar sólo las funcionalidades a las cuales puede acceder. Para realizar esta integración el módulo de control de acceso brinda un conjunto de servicios que en forma dinámica y dependiendo del usuario le indican a las aplicaciones qué funcionalidades puede o no acceder. La integración a nivel lógico permite realizar el enforcement de las políticas a través de un PEP (Policy Enforcement Point). Usualmente, en aplicaciones cuya arquitectura es de múltiples capas, el PEP se sitúa entre la capa de Presentación y la capa Lógica, interceptando los llamados, aplicando los controles, y en caso de que la invocación sea autorizada permitiendo que la misma sea efectivamente ejecutada. El PEP consume las funciones de seguridad a través de una API (Application Programming Interface) que brinda ACTkit-ACM.

El resto de este artículo está estructurado de la siguiente manera. La sección II describe las extensiones realizadas al modelo RBAC para poder expresar políticas basadas en roles, contenidos e información contextual. Las secciones III y IV describen en mayor profundidad los componentes ACTkit-L y ACTkit-ACM, respectivamente. En la sección V se presenta los detalles de una implementación de referencia de ACTkit y los mecanismos que permiten su integración con un sistema de información. La sección VI presenta y discute un caso de éxito

donde se utiliza el framework de control de acceso en un sistema de información de alta complejidad. Finalmente la sección VII discute trabajo relacionado y la sección VIII concluye.

II. EXTENSIÓN DE RBAC PARA MODELAR CONTROL DE ACCESO

BASADO EN CONTENIDOS E INFORMACIÓN CONTEXTUAL.

El modelo que ha sido definido para proveer la semántica de las políticas de control de acceso de interés, de aquí en más referenciado como E-RBAC, es una extensión del modelo Hierarchical RBAC (también conocido como RBAC1 en la literatura [14]). Esta extensión de RBAC1, además de proveer los mecanismos para la definición de reglas de control de acceso basadas en roles y jerarquías de éstos, incorpora la posibilidad de poder predicar sobre el contexto del usuario, típicamente los datos actuales en una sesión de ejecución, y sobre el dominio de datos del sistema de información. Una característica importante de E-RBAC es que las reglas que permite definir controlan las invocaciones a las operaciones de una aplicación. En la Fig. 2 se observan los principales componentes del modelo propuesto y sus relaciones. Estos componentes se pueden dividir en dos grupos: aquellos definidos en el modelo RBAC estándar y las extensiones realizadas.

Figura 2. Modelo RBAC extendido (E-RBAC).

A. Primitivas de RBAC

En particular, los conceptos de Sesión, Usuario, Rol y Privilegio, así como sus relaciones están basados en las definiciones del modelo RBAC1 estándar: Una Sesión se corresponde a un único usuario y

mantiene información de contexto, como por ejemplo la hora de inicio, etc.

Los usuarios representan a los usuarios finales de las aplicaciones clientes y al igual que en el modelo RBAC1, los mismos pueden tener asignado un conjunto de roles. Los privilegios de un usuario se derivan de los roles asignados explícitamente y los roles implícitos derivados a partir de la relación Jerarquía de Roles. La relación Usuario Aprobador representa a los usuarios que aprueban o rechazan las solicitudes de autorización. Posteriormente se detallarán estos conceptos.

El concepto de rol es el definido en RBAC1, su función

MARTÍNEZ AND BETARTE : ACTKIT: A FRAMEWORK FOR THE DEFINITION 1743

Page 3: ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies

es la de agrupar privilegios y definir jerarquías a través de la relación Jerarquía de Roles, que en general será un orden parcial definido sobre el conjunto de roles.

En el modelo estándar, los privilegios modelan las acciones que se pueden realizar sobre los recursos del sistema. En E-RBAC el concepto de privilegio se refinó para contemplar específicamente las invocaciones a las operaciones que brindan las aplicaciones. A continuación se extiende la definición de este concepto.

B. Extensiones al modelo RBAC

Las extensiones realizadas al modelo RBAC consisten en 1) un enriquecimiento de la noción de privilegio, 2) la introducción de la noción de autorización y 3) la incorporación de una relación de subordinación entre usuarios.

Figura 3. Extensiones al Modelo RBAC.

Como se observa en la Fig. 3, los privilegios en E-RBAC

tienen como principal objetivo modelar los recursos que se están protegiendo (las invocaciones a las operaciones) y sobre estos recursos particulares poder definir diferentes tipos de restricciones (limitaciones, proyecciones y predicados). El concepto operación representa la invocación de una

operación de la aplicación. Una operación es especificada por una tripleta conformada por un nombre, los argumentos y el valor de retorno de la operación.

Las limitaciones pueden ser de uno de los siguientes tipos: auditado, sensibilidad y confirmación. Un privilegio que tenga asociado una limitación del primer tipo indica que la ejecución de la operación debe ser auditada. Una limitación de sensibilidad indica que existen advertencias que deben ser transmitidas al usuario antes de continuar con la ejecución de la operación. Una limitación de confirmación indica que se debe contar con una autorización, concedida por un usuario aprobador, por ejemplo, para ejecutar la operación.

Las proyecciones permiten filtrar un atributo del valor de retorno de una operación. En caso de que el valor de retorno sea un objeto complejo, permite filtrar un atributo del mismo, si es una lista de objetos complejos, la proyección filtra un atributo específico de cada uno de los objetos que conforman la lista. Para determinar si el atributo se debe filtrar o no, la

proyección tiene asociado un predicado, que como se observa a continuación determina si se debe o no filtrar dicho atributo.

Los predicados son condiciones lógicas que pueden estar asociadas al privilegio, las limitaciones y a las proyecciones. Los predicados asociados al privilegio se denominan predicados de pre-condición o de post-condición dependiendo si predican sobre los argumentos o el valor de retorno de la operación. Estos predicados deben satisfacerse para que el usuario pueda invocar la operación u obtener el resultado. Los predicados asociados a las limitaciones sólo pueden predicar sobre los argumentos de la operación, y estos son evaluados antes de la invocación de la misma para determinar si es necesario o no aplicar la limitación asociada. Las condiciones que se pueden definir están expresadas en cálculo de primer orden con igualdad (en particular, se considera el fragmento implementado por SQL [8]). Los predicados asociados a las proyecciones predican sobre el valor de retorno de la operación, y su evaluación determina si el atributo asociado es o no desplegado. Además de predicar sobre los argumentos o valores de retorno dependiendo del predicado, también pueden predicar sobre valores de contexto (por ej.: el usuario asociado a la sesión, la fecha y hora actual, etc.).

Una autorización representa la solicitud de ejecutar cierta

operación a través del ejercicio de un privilegio dado. Es decir, una autorización se asocia a un usuario (el solicitante), a un privilegio y mantiene un atributo (un estado de decisión) que puede ser modificado sólo por el usuario aprobador asociado al usuario solicitante (modelado por la relación Usuario Aprobador). Un atributo de decisión positiva da lugar a que la operación pueda ser invocada (una sola vez) siempre y cuando se cumplan los predicados de contexto y contenido asociados al privilegio.

C. Resolución de conflictos

La resolución de una decisión de requerimiento de acceso (Access Decision Request) implica, ante la invocación de una operación controlada, determinar que exista un privilegio asignado al usuario que está intentando ejecutar la operación que lo habilite a ejecutar la misma. Para esto deben ser, en primer lugar, derivados los privilegios asociados a los roles asignados al usuario, ya sea explícitamente o implícitamente a partir de la jerarquía de roles definida. Si este proceso determina que el usuario posee más de un privilegio para la operación, se está en la presencia de un potencial conflicto de privilegios. Un conflicto de privilegios genera la ambigüedad de qué privilegio utilizar para resolver la decisión de acceso. Por ejemplo, se puede dar la situación en la que el usuario u está autorizado a ejecutar la operación o a través de un privilegio p1, pero a su vez el privilegio p2 no le permite ejecutar la misma sin tener una autorización del supervisor.

Para realizar un planteo formal del problema utilizamos la notación utilizada en [6][15]. En la Fig. 4 se definen las

Operación

Predicado

Limitación

Proyección

Privilegio

Pre-condición

Post-condición

Restricción

RBAC 1

E-RBAC

1744 IEEE LATIN AMERICA TRANSACTIONS, VOL. 10, NO. 3, APRIL 2012

Page 4: ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies

funciones basadas en los conceptos del modelo RBAC:

oPOp =)(p (1)

},...,{)( 1*

nrrroles =u (2)

},...,{)( 1 nppspermission =r (3) Figura 4. Roles, privilegios y operaciones.

La ecuación (1) determina la operación asociada a un

privilegio. La ecuación (2) presenta la función roles*, la cual determina los roles de un usuario (tanto los asociados directamente, como los asociados indirectamente a través de la jerarquía de roles). La ecuación (3) introduce la función permissions, la cual determina los privilegios asociados a un determinado rol. Se dice que existe un conflicto de privilegios para el usuario u si existe la operación o y al menos dos privilegios distintos p1 y p2 que cumplen la condición presentada en la Fig. 5.

))(( ,

)(

)(

*21 urolesspermissionpp

POp

POp

∧=∧=

op

op

2

1

Figura 5. Definición de Conflictos.

El enfoque seguido para la resolución de conflictos está

basado en el uso de restricciones estáticas de separación de tareas (Static Separation of Duties) utilizando la restricción conocida en la literatura como SSOD-CP [15]. En la definición de SSOD-CP se restringe la relación entre los usuarios y sus privilegios, definiendo que un usuario no puede estar asignado a dos privilegios que son conflictivos entre sí. En nuestro caso, la instanciación de dicha restricción define que dos privilegios son conflictivos entre sí si están asociados a la misma operación. Para la resolución de estos conflictos E-RBAC incluye una relación entre los usuarios y los privilegios. Como se observa en la Fig. 2, dicha relación se denomina Privilegios Prioritarios. Esta relación almacena por cada usuario el privilegio que tiene prioridad entre los privilegios conflictivos. La elección del privilegio prioritario se realiza cada vez que de una forma u otra se modifican los privilegios de los usuarios. En la implementación actual de ACTkit la elección de dicho privilegio es realizada por el administrador de seguridad.

III. ACTkit-L: UN LENGUAJE PARA LA DEFINICIÓN DE

POLÍTICAS DE SEGURIDAD

En esta sección se presenta ACTkit-L, el lenguaje mediante el cual se pueden definir políticas de control de acceso soportadas por el modelo E-RBAC y se describe brevemente el intérprete que permite incorporar las políticas al motor de decisión implementado en ACTkit-ACM.

A. Sintaxis concreta de ACTkit-L

A continuación se presenta, usando EBNF (Extended Backus–Naur Form), las principales construcciones del lenguaje.

ACTkitLeng = (RBAC1 | ERBAC)*; La regla ACTkitLeng expresa que toda construcción del

lenguaje es en definitiva una cadena válida del lenguaje de RBAC1 o en caso contrario representa una construcción propia a la extensión E-RBAC presentada en la sección II.

La regla RBAC1 específica la sintaxis concreta de las construcciones que permiten definir los usuarios, roles, privilegios y sus relaciones.

RBAC1 =

| usuario | rol | privilegio | 'agregarRolUsu' (idRol idUsuario conflictos ) | 'quitarRolUsu' (idRol idUsuario conflictos ) | 'agregarPrivRol' (idPriv idRol conflictos) | 'quitarPrivRol' (idPriv idRol conflictos) |

'agregarSubRol' (idRol idRol conflictos) | 'quitarSubRol' (idRol idRol conflictos);

usuario = 'usuario' (usu nombre email); rol = 'rol' (nombre descr efeDesde efeHasta ); privilegio =

'privilegio' (nombre descripcion idOperacion idLimitacion* idProyeccion* idPredicado*);

La regla usuario determina la información necesaria para definir un usuario del sistema, que se compone de: identificador, nombre y email. A través de la regla rol es posible definir los roles del modelo RBAC, los cuales tienen la siguiente información: nombre, descripción, fecha de inicio y fecha de expiración. Los privilegios se pueden crear a través de la regla privilegio, que define por cada uno de los privilegios los siguientes datos: nombre, descripción, operación, conjunto de limitaciones, conjunto de proyecciones y conjunto de predicados. Finalmente, las reglas agregarRolUsu, quitarRolUsu, agregarPrivRol, quitarPrivRol, agregarSubRol y quitarSubRol permiten realizar el mantenimiento de las relaciones entre los conceptos anteriores. Como se observa en la definición de dichas reglas, todas reciben los identificadores de los conceptos a relacionar y un atributo denominado conflictos. Este último es una colección que indica para cada conflicto que se genera al modificar la relación cuál es el privilegio prioritario.

La sintaxis concreta de las construcciones del lenguaje que permiten representar conceptos introducidos en la extensión del modelo (operación, limitación, proyección y predicado) son especificadas por la siguiente regla:

E-RBAC = operacion | limitacion | proyeccion | predicado;

operacion ='oper' (nombre tipo descr valorRetorno); limitacion = 'lim' (nombre descr idPredicado* tipo); predicado = 'pred' (nombre descr expresion); proyeccion = 'proy' (nombre descr expresion); En el caso de las reglas de predicado y proyeccion, la

MARTÍNEZ AND BETARTE : ACTKIT: A FRAMEWORK FOR THE DEFINITION 1745

Page 5: ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies

expresión es un predicado cuya definición se basa en una extensión del cálculo de primer orden con igualdad, más precisamente, en un dialecto de SQL (Standard Query Language) [8]. Una de las extensiones implica la definición de variables y la otra la aplicación de funciones. La definición de variables en los predicados permite que en tiempo de ejecución las mismas sean sustituidas por los valores correspondientes. Las variables permiten obtener la información que se encuentran en los argumentos y los valores de retorno de la operación que se está ejecutando, así como también valores del contexto. Por otro lado las funciones permiten invocar procesos escritos en Java para poder extender el lenguaje definido. La Fig. 6 ilustra la definición de los conceptos básicos del modelo RBAC y de un predicado E-RBAC usando ACTkit-L. En dicha figura se define un usuario (líneas 3 a 4), un rol (líneas 6 a 8), un predicado que permite restringir a los usuarios a ejecutar las operaciones solamente de lunes a viernes (líneas 10 a 14) y un privilegio (líneas 16 a 20). En la línea 22 se define la relación entre el privilegio y el rol. Finalmente en la línea 24 se asigna el rol admin al usuario jvarni.

Figura 6. Ejemplo de utilización del lenguaje ACTkit-L.

B. Interpretación de políticas

Para facilitar la administración de las políticas de control de acceso, se definió un módulo intérprete denominado ACTkit-I. La función de este módulo es interpretar una política expresada en ACTkit-L e instanciarla en el modelo utilizado por el módulo de control de acceso.

Como se observa en la Fig. 7, para cumplir con dichas funciones, el intérprete recibe como entrada un archivo XML [5] que contiene la política definida en ACTkit-L, y lo procesa a través de las siguientes etapas:

1. Validación de sintaxis: en esta etapa se valida que el archivo de entrada cumpla con la sintaxis definida por ACTkit-L.

2. Validación semántica: esta etapa se encarga de validar la buena formación de las sentencias aceptadas por la etapa anterior. Por ejemplo, en la sentencia de asignación de un rol a un usuario de la Fig. 6, primero se valida que el usuario jvarni y el rol admin existan, y luego se verifica que la asignación no genere conflictos.

3. Instanciación de la política: en esta etapa ACTkit-I incrementa las reglas de control de acceso en el repositorio de reglas. En la siguiente sección se describe como ACTkit-ACM utiliza dicho repositorio para brindar las funcionalidades de control de acceso. Continuando con el ejemplo anterior, en esta etapa ACTkit-I obtiene el usuario y el rol del repositorio de reglas y agrega al repositorio la correspondiente asociación entre los mismos.

ACTkit-I

Validación de Sintaxis

Validación Semántica

Entrada ACTkit-ACM

Instanciación

1

2 3

Figura 7. Funcionamiento del intérprete.

IV. FUNCIONAMIENTO DEL MÓDULO DE CONTROL DE ACCESO.

Antes de proceder a describir en mayor detalle las funciones de seguridad que brinda el módulo de control de acceso se define explícitamente el significado de algunos conceptos básicos: Sesión: Cada vez que un usuario se autentica ante un

sistema ingresando sus credenciales se le crea una sesión, la que identifica y representa al usuario dentro de ACTkit-ACM. Sólo se permite mantener una sesión establecida por usuario.

Access Request (AR): Solicitud o petición realizada por parte de la aplicación cliente cuando un usuario desea acceder a un recurso protegido.

Decisión: Resultado retornado por el módulo de control de acceso como respuesta a un AR. El mismo indica si el usuario está autorizado o no a acceder al recurso protegido.

Repositorio de reglas: Es el componente donde se almacenan las instancias de los conceptos del modelo E-RBAC. Las instancias almacenadas forman la política de control de acceso que aplica ACTkit-ACM para retornar una Decisión ante un AR.

A. Autenticación.

El mecanismo de control de acceso es disparado ante el intento de ejecución de una funcionalidad de la aplicación cliente. El módulo de control de acceso realiza en primer lugar la verificación de que el usuario esté autenticado, validando que exista la sesión asociada a dicho usuario. En caso que no lo esté, se solicita las credenciales, se procede a verificar las

1746 IEEE LATIN AMERICA TRANSACTIONS, VOL. 10, NO. 3, APRIL 2012

Page 6: ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies

mismas, y si las mismas son válidas se procede a crear e iniciar una sesión para el usuario. Esto es conocido como el proceso de autenticación.

B. Visualización controlada de la información.

Una vez que el usuario está autenticado, se le debe proveer acceso a las funcionalidades y a la información. Se distinguen dos tipos de acceso: 1) acceso a las operaciones de la aplicación, lo que permite desplegar al usuario el conjunto de funcionalidades que puede ejecutar, y 2) el acceso a la información. Este proceso se llama visualización controlada, tanto de la información crítica como de las funcionalidades que expone la aplicación. El módulo de control de acceso expone en su interfaz dos operaciones: operacionesVisibles, que determina el conjunto de funcionalidades a las que tiene acceso un usuario, y atributosVisibles, que determina para una funcionalidad que datos puede visualizar el usuario.

C. Procedimiento de Autorización.

Como se puede observar en la Fig. 9, el procedimiento de autorización a la utilización de un recurso protegido, lo que se representa en un AR, se compone de dos fases: La fase de decisión es la primera en ser ejecutada y

determina si el usuario está autorizado a acceder a un recurso protegido. La resolución de la decisión se determina a partir de la ejecución de las siguientes etapas:

i. Verificar E-RBAC: esta etapa consiste, según especificado en la Fig. 8, en determinar el conjunto de privilegios asignados al usuario que lo habilitan a ejecutar la operación del AR. Ante la existencia de más de un privilegio habilitante, se debe seleccionar el privilegio prioritario (ver Resolución de conflictos). Si el usuario no posee un privilegio para ejecutar la operación finaliza la fase de decisión retornando el valor No Autorizado.

})(

))(({

),(*

oppPOp

urolesspermissionpp

opusprivilegio

=∧∈

= |

Figura 8. Privilegios que autorizan al usuario u a ejecutar la operación op.

ii. Evaluar Pre-condición: esta etapa tiene como

entrada el privilegio determinado en la etapa anterior. En caso de que dicho privilegio tenga asociado un predicado de Pre-condición, esta etapa se encarga de evaluarlo. La salida de esta etapa puede ser algunos de estos valores {Autorizado, No Autorizado} dependiendo del resultado de la evaluación del predicado.

En caso de que el resultado de la primera fase sea Autorizado, se ejecuta la fase de limitación. Esta fase evalúa las restricciones impuestas a la operación. Hay tres tipos de restricciones que se pueden imponer a una operación:

i. La primera de ellas es denominada restricción de

confirmación, que evalúa si el usuario debe solicitar a un supervisor autorización para ejecutar.

ii. Luego se determina si la operación debe ser auditada o no, conocida como restricción de auditado.

iii. La última restricción determina si el usuario debe ser alertado ante el intento de ejecución de la operación. Esto significa que si el usuario intenta ejecutar una operación para la cual existe una restricción de alerta, el módulo enviara en su decisión las advertencias correspondientes, para que el usuario determine si desea continuar con la ejecución de la operación. El usuario podrá optar por continuar o cancelar la ejecución de la operación.

Etapa de Decisión

Etapa de Limitación

[Autorizado]

Control de Acceso

d.decisión=No Autorizado

[No Autorizado]

Verificar existencia Autorización

[Confirmación]

Verificar Auditar[Tiene]

d.auditar=Si

[Auditado]

Verificar Avisos

[No Auditado]

d.alertar=Si

d.decisión=Autorizado

[No Sensible]

[Sensible]

[No Tiene]

[Sin Confirmación]

Figura 9. Diagrama de actividad de las etapas del procedimiento de autorización.

D. Filtrado de la Información

Si la decisión del procedimiento de autorización es autorizado, el PEP ejecuta la operación, pero antes de retornar filtra el resultado de la operación ejecutada. Esto implica aplicar los predicados de post-condición definidos en el privilegio sobre el resultado de la operación. Por ejemplo, una aplicación que tenga una operación de búsqueda de Personas para la cual exista un privilegio con un predicado de post-condición debe realizar el filtrado en tiempo de acceso del resultado. Supongamos que el predicado restringe la búsqueda a retornar solamente las personas que fueron ingresadas por el

MARTÍNEZ AND BETARTE : ACTKIT: A FRAMEWORK FOR THE DEFINITION 1747

Page 7: ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies

usuario conectado. El filtrado de la información hace que ACTkit-ACM filtre en tiempo de acceso y devuelva aquellas personas que cumplan con la condición.

V. IMPLEMENTACIÓN REFERENCIA DE ACTKIT.

La implementación de referencia de ACTkit se desarrolló utilizando tecnología JEE [16] y una base de datos relacional para almacenar las políticas. ACTkit expone los servicios brindados a través de interfaces EJB (Enterprise Java Beans) [16] remotas y/o Web Services [19] . Estos servicios pueden ser consumidos por diferentes aplicaciones, tanto para forzar la aplicación de las reglas de control de acceso como para implementar la visualización controlada de los datos y operaciones de la aplicación.

La integración de una aplicación con ACTkit se debe realizar en dos capas diferentes: la capa de presentación y la capa lógica. A continuación se describen alternativas posibles para la integración del framework con cada capa.

A. Integración con la capa de Presentación de la aplicación.

La integración de la presentación de las aplicaciones con el módulo de control de acceso es de carácter funcional más que del punto de vista de la seguridad. Es decir, a cada usuario se le debe desplegar sólo las funcionalidades a las cuales puede acceder. Para realizar esta integración el módulo de control de acceso brinda un conjunto de servicios que en forma dinámica y dependiendo del usuario le indican a las aplicaciones qué funcionalidades puede o no acceder. Es responsabilidad de las aplicaciones modificar la interfaz de usuario en forma dinámica en función del resultado a la invocación.

Los servicios expuestos a las aplicaciones por el módulo de control de acceso está dado por las funciones operacionesVisibles y datosVisibles. La primera es la responsable de determinar el conjunto de operaciones que puede visualizar el usuario u. En la Fig. 10 se brinda una definición de la misma. La segunda (datosVisibles) determina dado un usuario y una operación el conjunto de datos que pueden ser visualizados por dicho usuario.

))}((

)(,|{

)(

* urolesspermissionp

opPOppo

usVisiblesoperacione

∈∧=∃

=

Figura 10. Operaciones que puede visualizar el usuario u.

B. Integración con la capa Lógica de la aplicación.

La integración con la capa lógica es la más crítica, ya que es aquí donde se van a forzar las políticas de control de acceso que van a restringir la invocación a las diferentes operaciones, aplicar las limitaciones y filtrar los valores de retorno, si corresponde.

En XACML [4] (eXtensible Access Control Markup Language) se define una arquitectura para la aplicación de las reglas de control de acceso, donde toda invocación a la lógica de la aplicación se realiza a través de un PEP (Policy Enforcement Point). El PEP es quien intercepta las

invocaciones y fuerza las políticas de control de acceso consumiendo las interfaces EJB o los Web Services expuestos por ACTkit. Es decir, para integrar una aplicación con el módulo de control de acceso, se debe implementar un PEP como una capa intermedia de las aplicaciones e invocar las funcionalidades brindadas por el módulo de control de acceso.

Para facilitar la integración y minimizar los cambios en la arquitectura de las aplicaciones, ACTkit brinda un PEP que mediante la utilización de técnicas de AOP (Aspect-Oriented Programming) [11] y Reflection [18] intercepta las llamadas a la lógica y fuerza las políticas definidas. La implementación de dicho PEP es específica para la utilización en aplicaciones implementadas con la tecnología JEE y que la lógica de la misma se encuentre implementada utilizando EJB. En la Fig. 11 se presenta un pseudocódigo del PEP, donde se muestra el método que intercepta las llamadas (actkitSeguridadInterceptor) y cómo interactúa éste con el módulo de control de acceso.

Figura 11. Pseudocódigo del PEP que brinda ACTkit.

En la Fig. 12 se muestra un ejemplo de utilización del PEP para la intercepción de las llamadas a la lógica de una aplicación cliente.

En el ejemplo, la clase Logica es un EJB y es la que brinda las diferentes operaciones de la aplicación cliente que son invocadas desde la capa de Presentación. La anotación @Interceptors, indica al servidor de aplicaciones que antes de la invocación a un método del EJB Logica, se invoque el método actkitSeguridadInterceptor de la clase ACTkitInterceptor. Al invocar este método, mediante técnicas de reflection se obtienen la operación que se está invocando, los argumentos y se invoca al módulo de control de acceso para verificar si es una invocación válida. En caso de que el usuario no esté autorizado a invocar dicha operación, el

1748 IEEE LATIN AMERICA TRANSACTIONS, VOL. 10, NO. 3, APRIL 2012

Page 8: ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies

módulo de control de acceso levanta una excepción que interrumpe la ejecución. En caso de que esté autorizado, el PEP invoca la operación, obtiene el resultado y los filtra utilizando la operación autorizarPost del módulo de control de acceso. El resultado luego de ser filtrado es retornado a quien realizó la invocación.

Figura 12. Ejemplo del uso del PEP.

VI. UNA IMPLEMENTACIÓN OPERATIVA DE ACTKIT.

Una implementación particular de ACTkit ha sido desarrollada por la empresa Tilsor S.A. para la resolución de control de acceso de los recursos sensibles del sistema de gestión de información de niños utilizado por el INAU (Instituto del Niño y Adolescente del Uruguay). Éste es el organismo gubernamental uruguayo cuya misión es “Garantizar el ejercicio efectivo de la ciudadanía a todos los niños, niñas y adolescentes del Uruguay, como corresponde a su calidad de sujeto pleno de derecho” [9]. El sistema, denominado SIPI (Sistema de Información para la Infancia), que actualmente se encuentra en producción y accesible a través de Internet, gestiona toda la información de los niños, niñas y adolescentes que han tenido alguna vinculación con INAU. La información gestionada por este sistema abarca un espectro amplio de la vida de cada uno de estos niños, destacando los siguientes grupos de información: Datos de identificación Datos de su familia y vivienda Datos educativos Datos de salud (enfermedades, tratamientos, consumo

de sustancias psicoactivas, etc.) Datos de situaciones de violencia Datos de adopción

Esta información es de naturaleza sensible, y por lo tanto,

los datos deben ser protegidos para que solamente puedan ser accedidos y modificados por usuarios autorizados. A continuación se listan algunos de los requerimientos de seguridad más relevantes del sistema: Control de acceso a las operaciones: se debe controlar

el acceso a las operaciones del sistema permitiendo determinar qué usuarios están autorizados a ejecutar cada operación.

Agrupación de permisos: dado que muchos usuarios realizan las mismas funciones, los permisos que se les otorguen deben ser los mismos. La agrupación de estos permisos facilita la administración de la seguridad.

Acceso a la información según su lugar de trabajo: los usuarios del sistema trabajan en ciertas dependencias del instituto, y cada una de estas dependencias se encarga de gestionar una determinada población de

niños y de adolescentes. En general los usuarios solamente pueden acceder a la información de un niño o adolescente de la dependencia para la cual trabaja dicho usuario. Además existen usuarios con mayores privilegios que pueden ver información de niños o adolescentes de cualquier dependencia.

Visualización controlada de la información: la sensibilidad de los datos gestionados determina que solamente algunos usuarios puedan ver cierto tipo de información. Por ejemplo para el caso de niños adoptados, solamente algunos usuarios pueden ver los datos de los padres biológicos.

Solicitud de autorización: para efectuar determinadas acciones sensibles, es necesario que algunos usuarios soliciten autorización a su supervisor. Una vez que solicitan la autorización, el sistema permitirá continuar con la operación siempre y cuando el usuario supervisor la autorice.

Advertencias a los usuarios: el sistema debe alertar a los usuarios cuando intentan modificar información de carácter sensible. Esto hace que cuando un usuario intente modificar ciertos datos, el sistema lo advierta y sea el usuario quien decida si continuar o no con la acción.

Auditoría de las operaciones: todas las acciones realizadas por los usuarios deben ser auditadas.

Los mecanismos provistos por el framework permiten

satisfacer cada uno de estos requerimientos El requerimiento de control de acceso a las operaciones

y el requerimiento de agrupación de permisos se resolvieron utilizando roles y jerarquías.

El requerimiento de acceso a la información según el lugar de trabajo se resuelve definiendo un predicado basado en el resultado de la operación y el contexto del usuario. El predicado utiliza información del contexto para obtener la dependencia para la cual trabaja el usuario y por otro lado filtra el resultado de la operación permitiendo obtener solamente la información de los niños que el usuario puede consultar.

Para el requerimiento de visualización controlada de la información se utilizaron proyecciones. En el ejemplo citado, se crea una proyección sobre los datos de los padres biológicos de un niño, que permite solamente a ciertos usuarios consultar estos datos.

Para el requerimiento de solicitud de autorización se creó un privilegio con una limitación de confirmación.

Para las advertencias a los usuarios se hace uso de las limitaciones de sensibilidad, que indican que bajo ciertas condiciones definidas a través de predicados se envían advertencias a los usuarios.

Para el requerimiento de auditoría de las operaciones fueron utilizadas las limitaciones de auditoría.

El módulo de control de acceso del SIPI provee las

funcionalidades necesarias para implementar todos los requerimientos antes mencionados. La implementación e implantación del mismo permitió verificar que los mecanismos provistos por ACTkit que aquí se han presentado

MARTÍNEZ AND BETARTE : ACTKIT: A FRAMEWORK FOR THE DEFINITION 1749

Page 9: ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies

permiten definir y aplicar políticas de seguridad no triviales en un sistema de información de alta complejidad.

VII. TRABAJOS RELACIONADOS.

El modelo RBAC constituye una clara alternativa a los modelos clásicos de control de acceso y ha sido adoptado por el NIST como un estándar [6]. El modelo RBAC fue diseñado para facilitar la administración teniendo principalmente en cuenta la asignación de los privilegios a los usuarios. La formulación original de este modelo no provee mecanismos para la definición de reglas de control de acceso basado en el contexto y contenido de la información protegida.

En [20] se presentan extensiones al modelo para poder contemplar políticas basadas en el contexto de ejecución de un sistema de información. Al igual que en ACTkit, las reglas de control de acceso basado en el contexto están asociadas a los privilegios. Las extensiones presentadas en [20] sólo incorporan la noción de reglas basadas en el contexto, pero no incluyen las reglas basadas en el contenido, ya que están específica y exclusivamente orientadas a resolver la protección de contenido digital.

En [7] se presentan extensiones a RBAC que mejoran su poder de expresividad permitiendo la definición de roles paramétricos a partir de propiedades de los objetos de negocios del sistema. Esta extensión llamada ORBAC está orientada a proteger sistemas implementados en lenguajes orientados a objetos al igual que en ACTkit. ORBAC protege las operaciones a través de anotaciones. Dichas anotaciones definen qué roles están autorizados a ejecutar la operación y los parámetros que recibe el rol. Este conjunto de parámetros permite definir condiciones dinámicas para evaluar la autorización a la operación. A su vez las operaciones que retornan un objeto se pueden marcar con una anotación para agregar condiciones al resultado. El caso de ejemplo presentado en [7] se basa en un sistema que gestiona la información de un hospital. Dicho sistema cuenta con una operación que devuelve la historia clínica de un paciente. Con RBAC se puede definir un rol pacientes, y todo usuario que tenga asignado dicho rol estará autorizado a ejecutar la operación, pero no es posible definir la condición de que solamente vea los datos correspondientes a su historia. Para esto ORBAC define anotaciones que permiten agregar condiciones al resultado, resolviendo así este problema. A diferencia de ACTkit, para realizar el control de acceso en ORBAC es necesario modificar el código fuente del sistema que se protege, agregando las anotaciones correspondientes ante la definición de la operación, por ejemplo si se desea cambiar los parámetros que recibe el rol es necesario modificar la anotación donde se utilizan. El diseño de ACTkit tuvo como premisa impactar lo menos posible el diseño y la implementación del aplicativo protegido. En ACTkit las políticas son definidas en el framework y los cambios en la misma no afectan la integración con la aplicación cliente. Por otro lado el filtrado del resultado en ACTkit se puede definir sobre un objeto, un atributo del objeto o la lista de objetos devueltos por una operación. En ORBAC solamente se puede filtrar en el caso de que el retorno de la operación sea un

objeto. Otros trabajos se enfocan en complementar el modelo

RBAC enriqueciendo la decisión de acceso con otros atributos. En [1] se complementa el modelo RBAC con la utilización de Resource Access Decision facility (RAD). En este caso se plantea complementar la decisión obtenida del modelo RBAC con el uso de las relaciones de los objetos de negocio de la aplicación cliente, lo que en este trabajo se ha denominado políticas basadas en el contenido.

En el área de los lenguajes de control de acceso el comité de OASIS ha especificado XACML [4] como un lenguaje genérico para definir políticas de control de acceso. Dicho lenguaje permite expresar políticas para proteger recursos. En este lenguaje los recursos son objetos genéricos que deben definirse, luego de definido el recurso se deben definir las acciones que impactan sobre él. Por ejemplo si el recurso a proteger es un archivo, las acciones que se pueden definir sobre el recurso pueden ser: lectura, escritura, etc. Para el caso de ACTkit los recursos que se protegen son las funcionalidades de un sistema o aplicativo. Si bien XACML está orientado a la definición de políticas de control de acceso, y permitiría expresar los componentes modelados en E-RBAC, la complejidad para expresar las políticas concluyó en definir ACTkit-L. El diseño de este lenguaje fue específico para expresar los conceptos definidos en el modelo E-RBAC de forma directa e intuitiva para facilitar la definición de las políticas por parte de los administradores de seguridad. A continuación se define como trabajo futuro la construcción de un componente para traducir las políticas definidas en ACTkit a XACML.

VIII. CONCLUSIONES Y TRABAJO FUTURO.

En este artículo se ha presentado el diseño e implementación de un framework de control de acceso orientado a la protección de las funcionalidades expuestas por los sistemas de información permitiendo definir y aplicar políticas dinámicas de control de acceso. Para definir este tipo de políticas se presenta una extensión del modelo RBAC (denominada E-RBAC) que, entre otras propiedades, permite el modelado de reglas de control de acceso context based y content based.

Los compontes principales de ACTkit son un lenguaje (ACTkit-L), junto con su intérprete (ACTkit-I), para definir políticas de control de acceso soportadas por E-RBAC y un módulo de control de acceso (ACTkit-ACM), que es el componente que brinda las funcionalidades de: autenticación, visualización controlada de la información y autorización a la utilización de un recurso protegido.

También se ha presentado y discutido un caso de éxito donde se ha utilizado una implementación particular de ACTkit para definir y aplicar políticas de seguridad no triviales en un sistema de información de alta complejidad y que se encuentra actualmente en producción.

Un trabajo futuro identificado es integrar el módulo de control de acceso con un directorio LDAP (Lightweight Directory Access Protocol) [17]. Esto permitiría delegar la gestión de los usuarios al directorio incorporando

1750 IEEE LATIN AMERICA TRANSACTIONS, VOL. 10, NO. 3, APRIL 2012

Page 10: ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies

funcionalidades que actualmente no son soportadas, como por ejemplo políticas de contraseñas. Es de interés también poder darle un tratamiento formal a una optimización realizada en la implementación del SIPI, donde se ha utilizado la noción de vistas (sobre una base de datos relacional) para implementar algunos de los mecanismos definidos en E-RBAC. Más precisamente, para implementar el filtrado que se realiza a los valores de retorno asociados a la invocación de una operación de acuerdo a los predicados de post-condición definidos en la política.

Otra extensión para incorporar al framework es la aplicación de post-condiciones sobre las excepciones que lanzan las operaciones. Notar que cuando la ejecución de una operación es interrumpida por una excepción, la misma puede acarrear información sensible que podría ser visualizada por el usuario. Parece interesante estudiar el incorporar al módulo de control de acceso un filtrado sobre los datos que pueden incluir las excepciones, de manera de controlar todos los flujos de datos que se presenten al usuario. Dotar al framework de un componente que permita traducir las políticas definidas en ACTkit desde y hacia XACML brindaría una interacción con un lenguaje estándar. Este nuevo componente debe brindar las funcionalidades para permitir importar y exportar políticas de XACML al modelo definido en ACTkit y viceversa.

IX. AGRADECIMIENTOS

Los autores desean agradecer los precisos y detallados comentarios y sugerencias de un evaluador anónimo, y a la Prof. Cristina Alayón, Directora del SIPI, por el apoyo brindado.

REFERENCIAS. [1] J. Barkley, C. Beznosov, Uppal, "Supporting Relationships in Access

Control using Role Based Access Control", Fourth ACM Workshop on Role-Based Access Control, 1999.

[2] E. Bertino, P. A. Bonatti, E. Ferrari, Trbac: “A temporal role-based access control model”. ACM Transactions on Information and System Security, Vol. 4, No. 3, pp 191–223, August 2001.

[3] R. Chandramouli, “Business Process Driven Framework for defining an Access Control Service based on Roles and Rules”, 23rd National Information Systems Security Conference, October 2000.

[4] eXtensible Access Control Markup Language (XACML), Version 3.0 Committee Specification 01, 10 August 2010. http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf, (último acceso: 30 de abril de 2011).

[5] eXtensible Markup Language (XML). http://www.w3.org/XML/, (último acceso: 30 de abril de 2011).

[6] D. Ferraiolo, J. Barkley, D. Kuhn, "A Role Based Access Control Model and Reference Implementation within a Corporate Intranet", ACM Transactions on Information Systems Security, Vol. 1, No. 2, 1999.

[7] J. Fischer, D. Marino, R. Majumdar, T. Millstein, “Fine-Grained Access Control with Object-Sensitive Roles”, European Conference on Object-Oriented Programming, July 2009.

[8] Information Technology - Database Language SQL, http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt, (último acceso: 30 de abril de 2011).

[9] Instituto del Niño y del Adolescente del Uruguay – Misión y Visión, http://www.inau.gub.uy/inicio/mision-y-vision.html, (último acceso: 30 de abril de 2011).

[10] Java SE 6 documentation. http://download.oracle.com/javase/6/docs/, (último acceso: 30 de abril de 2011).

[11] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Videira, J. Loingtier, J. Irwin, Aspect-Oriented Programming, 11th European Conference on Object-Oriented Programming, Mehmet Aksit, Vol. 1241, pp. 220-242, June 1997.

[12] N. Li, Z. Mao, “Administration in role based access control”, ACM Symposium on Information, Computer and Communications, Security, March 2007.

[13] P. Samarati, S. Capitani, “Access Control: Policies, Models, and Mechanisms”, Foundations of Security Analysis and Design (Tutorial Lectures), Lecture Notes in Computer Science, Vol. 2171, pp. 137-196, 2001.

[14] R. Sandhu, D. Ferraiolo, D. Kuhn, "The NIST Model for Role Based Access Control: Toward a Unified Standard", in Proc. 5th ACM Workshop on Role Based Access Control, pp.47-63, 2000.

[15] R. Sandhu, G. Joon, “The RSL99 language for role-based separation of duty constraints”, in Proc. RBAC '99 Proceedings of the fourth ACM workshop on Role-based access control, pp. 43-54, 1999.

[16] The Java EE 5 Tutorial, September 2010 (originally published 2007). http://download.oracle.com/javaee/5/tutorial/doc/, (último acceso: 30 de abril de 2011).

[17] The website of the X.500 Directory standard, http://www.x500standard.com/, (último acceso: 30 de abril de 2011).

[18] Using Java Reflection, January 1998. http://java.sun.com/developer/technicalArticles/ALT/Reflection/, (último acceso: 30 de abril de 2011).

[19] Web Services Architecture, February 2004. http://www.w3.org/TR/ws-arch/, (último acceso: 30 de abril de 2011).

[20] M. Wu, Y. Chen, C. Ke, “Design and implementation of a context and role-based access control model for digital content”, In Proc. of IET International Conference on Frontier Computing - Theory, Technologies and Applications, pp.253-257, 2010.

Gustavo Betarte es Ingeniero de Sistemas en Computación de la Facultad de Ingeniería de la Universidad de la República (FING – UDELAR). Obtuvo un MSc y un PhD en Ciencia de la Computación de la Universidad de Gotemburgo, Suecia. . Es Profesor Titular (Gr. 5) efectivo del Instituto de Computación (InCo) y es el responsable científico del Grupo de Seguridad Informática (GSI) de

FING– UDELAR. Tiene varias publicaciones en el área de Seguridad Informática en revistas y conferencias internacionales arbitradas. Desde noviembre de 2004 dirige el equipo de Consultoría Tecnológica de la empresa uruguaya Tilsor SA.

Andrés Gatto es Ingeniero en Computación de la Facultad de Ingeniería de la Universidad de la República (FING - UDELAR). Desde agosto de 2005 integra el equipo de Consultoría Tecnológica de la empresa uruguaya Tilsor SA, trabajando en el área de consultoría en tecnologías Oracle. Temas de interés: bases de datos, seguridad en bases de datos.

Rodrigo Martínez es Ingeniero en Computación de la Facultad de Ingeniería de la Universidad de la República (FING - UDELAR). Actualmente es miembro y docente del Grupo de Seguridad Informática de la FING - UDELAR. Desde agosto de 2005 integra el equipo de Consultoría Tecnológica de la empresa uruguaya Tilsor SA, trabajando en el área de consultoría de seguridad y tecnologías Oracle.

Temas de interés: seguridad en aplicaciones.

Felipe Zipitría es Ingeniero en Computación de la Facultad de Ingeniería de la Universidad de la República (FING – UDELAR). Obtuvo un Msc. en Informática del PEDECIBA Informática. Es Profesor Agregado (Gr. 3) del Instituto de Computación en FING – UDELAR. En la actualidad pertenece al Grupo de Seguridad Informática de la Facultad, y participa del dictado de cursos de Fundamentos de la

Seguridad Informática y Seguridad en Aplicaciones. Desempeña actividad profesional dentro de la Facultad, en la Unidad de Recursos Informáticos, como Administrador de Sistemas Senior.

MARTÍNEZ AND BETARTE : ACTKIT: A FRAMEWORK FOR THE DEFINITION 1751