Capítulo 10 Registro de auditoría

En este capítulo se explica cómo registra los eventos el sistema de auditoría.

Esta información se ha dividido en los temas siguientes:

• El proceso de registro de auditoría

• ¿Qué audita Identity Manager?

• Creación de eventos de auditoría a partir de flujos de trabajo

• Configuración de auditoría

• Esquema de la base de datos

• Configuración del registro de auditoría

• Supresión de registros del registro de auditoría

• Uso de publicadores de auditoría personalizados

• Desarrollo de publicadores de auditoría personalizados

El proceso de registro de auditoría

El proceso de auditoría de Identity Manager tiene como finalidad registrar quién ha hecho qué con cuáles objetos de Identity Manager y cuándo lo ha hecho.

Los eventos de auditoría están controlados por uno o varios publicadores. De manera predeterminada, Identity Manager utiliza el publicador del depósito para registrar los eventos de auditoría en el depósito. Con la ayuda de los grupos de auditoría, el filtrado permite al administrador seleccionar un subconjunto de eventos de auditoría para registrarlos. A cada publicador se le puede asignar uno o varios grupos de auditoría que se habilitan inicialmente.

Encontrará información sobre la supervisión y administración de infracciones de usuario en el Capítulo 13Auditoría de identidades: Conceptos básicos.

¿Qué audita Identity Manager?

La mayoría de la auditoría predeterminada la realizan los componentes internos de Identity Manager. Sin embargo, hay interfaces que permiten generar eventos a partir de flujos de trabajo o código Java.

La instrumentación de auditoría de Identity Manager se centra en cuatro áreas principales:

• Abastecedor. Un componente interno denominado abastecedor puede generar eventos de auditoría.

• Controladores de vista. En la arquitectura de la vista, el controlador de la vista genera registros de auditoría. Un controlador de vista siempre debe auditar cuándo se crean o modifican los objetos.

• Sesión. Los métodos de sesión (como checkinObject, createObject, runTask, login y logout) crean un registro de auditoría tras completar una operación auditable. La mayoría de la instrumentación recae en los controladores de vista.

• Flujo de trabajo. De manera predeterminada, sólo los flujos de trabajo de aprobación se instrumentan para generar registros de auditoría. Generan un evento de auditoría cuando se aprueban o rechazan solicitudes. La conexión entre la función del flujo de trabajo y el registrador de auditoría se produce mediante la aplicación com.waveset.session.WorkflowServices. Para obtener más información, consulte la próxima sección.

Creación de eventos de auditoría a partir de flujos de trabajo

De manera predeterminada, sólo los flujos de trabajo de aprobación se instrumentan para generar registros de auditoría. En esta sección se explica cómo utilizar la aplicación com.waveset.session.WorkflowServices para generar eventos de auditoría adicionales a partir de cualquier proceso de flujo de trabajo.

Quizá necesite más eventos de auditoría si debe producir informes sobre los flujos de trabajo personalizados. En Modificación de flujos de trabajo para registrar eventos de auditoría estándar se explica cómo agregar eventos de auditoría a los flujos de trabajo.

También es posible agregar eventos de auditoría especiales a los flujos de trabajo para los informes de flujo de trabajo (Informes de flujo de trabajo). Los informes de flujo de trabajo indican cuánto tiempo duran los flujos de trabajo completos. Para almacenar los datos que se utilizan en los cálculos de tiempo se necesitan eventos de auditoría especiales. En Modificación de flujos de trabajo para registrar eventos de auditoría de temporización se explica cómo agregar eventos de auditoría de temporización a los flujos de trabajo.

La aplicación com.waveset.session.WorkflowServices

La aplicación com.waveset.session.WorkflowServices genera eventos de auditoría a partir de cualquier proceso de flujo de trabajo. En la Tabla 10–1 se describen los argumentos disponibles para esta aplicación.

Modificación de flujos de trabajo para registrar eventos de auditoría estándar

Para crear un evento de auditoría estándar en un flujo de trabajo, agréguele el siguiente elemento <Activity>:

<Activity name=’createEvent’>

A continuación, anide en <Activity> un elemento <Action> que referencie la aplicación com.waveset.session.WorkflowServices:

<Action class=’com.waveset.session.WorkflowServices’>

Anide en <Action> los elementos <Argument> requeridos y opcionales. La Tabla 10–1 contiene la lista de argumentos.

Para registrar eventos de auditoría estándar, el argumento op debe configurarse en audit.

Ejemplos de flujo de trabajo contiene el código mínimo requerido hasta para crear un evento de auditoría.

Ejemplos de flujo de trabajo

El ejemplo siguiente muestra una actividad de flujo de trabajo sencilla y la generación de un evento que generará una actividad de eliminación de recursos denominada ADSIResource1, realizada por ResourceAdministrator.

Ejemplo 10–1 Actividad de flujo de trabajo simple

<Activity name=’createEvent’> <Action class=’com.waveset.session.WorkflowServices’> 
<Argument name=’op’ value=’audit’/> <Argument name=’type’ value=’Resource’/> 
<Argument name=’action’ value=’Delete’/> <Argument name=’status’ value=’Success’/> 
<Argument name=’subject’ value=’ResourceAdministrator’/> 
<Argument name=’name’ value=’ADSIResource1’/> </Action> <Transition to=’end’/> </Activity>

El siguiente ejemplo muestra cómo agregar atributos específicos a un flujo de trabajo que rastrea los cambios aplicados por cada usuario en un proceso de aprobación hasta un nivel detallado. Esta adición suele seguir a una acción ManualAction que solicita entrada al usuario.

ACTUAL_APPROVER se configura en el formulario y en el flujo de trabajo (en caso de aprobar desde la tabla de aprobaciones) en función de la persona que realmente ha dado la aprobación. APPROVER identifica la persona a la que se había asignado.

Ejemplo 10–2 Atributos agregados para llevar un seguimiento de los cambios en un proceso de aprobación

 
<Action name=’Audit the Approval’ application=’com.waveset.session.WorkflowServices’> 
<Argument name=’op’ value=’audit’/> <Argument name=’type’ value=’User’/> 
<Argument name=’name’ value=’$(CUSTOM_DESCRIPTION)’/> <Argument name=’action’ value=’approve’/> 
<Argument name=’accountId’ value=’$(accountId)’/> <Argument name=’status’ value=’success’/> 
<Argument name=’resource’ value=’$(RESOURCE_IF_APPLICABLE)’/> 
<Argument name=’loginApplication’ value=’$(loginApplication)’/> 
<Argument name=’attributes’> <map> 
<s>fullname</s><ref>user.accounts[Lighthouse].fullname</ref> 
<s>jobTitle</s><ref>user.accounts[Lighthouse].jobTitle</ref> 
<s>location</s><ref>user.accounts[Lighthouse].location</ref> 
<s>team</s><ref>user.waveset.organization</ref> <s>agency</s>
<ref>user.accounts[Lighthouse].agency</ref> </map> </Argument> 
<Argument name=’originalAttributes’> <map> <s>fullname</s> <s>User’s previous fullname</s> 
<s>jobTitle</s> <s>User’s previous job title</s> <s>location</s> <s>User’s previous location</s> 
<s>team</s> <s>User’s previous team</s> <s>agency</s> <s>User’s previous agency</s> </map> 
</Argument> <Argument name=’attributes’> <map> <s>firstname</s> <s>Joe</s> <s>lastname</s> 
<s>New</s> </map> </Argument> <Argument name=’subject’> <or> <ref>ACTUAL_APPROVER</ref> 
<ref>APPROVER</ref> </or> 
</Argument> <Argument name=’approver’ value=’$(APPROVER)’/> </Action>

Modificación de flujos de trabajo para registrar eventos de auditoría de temporización

Es posible modificar los flujos de trabajo para registrar eventos de temporización que sirvan para los informes de flujo de trabajo (Informes de flujo de trabajo). Los eventos de auditoría estándar sólo registran que se ha producido un evento, mientras que los eventos de auditoría de temporización registran cuándo ha comenzado y terminado el evento, lo que permite efectuar cálculos de tiempo. Además de los datos del evento de temporización, también se almacena la mayoría de la información registrada por los eventos de auditoría estándar. Encontrará más información en ¿Qué información almacenan los eventos de auditoría de temporización?.

Para registrar eventos de auditoría de temporización, antes debe activar la auditoría del flujo de trabajo para cada tipo de flujo sobre el que quiera informar.

• En el caso de los flujos de trabajo que se pueden configurar en la interfaz de administración mediante plantillas de tarea, habilite primero la plantilla de tarea correspondiente al flujo de trabajo que desea auditar. Consulte las instrucciones en Habilitación de las plantillas de tarea.

  A continuación, active la auditoría del flujo de trabajo marcando la casilla de verificación Auditar todo el flujo de trabajo. Consulte las instrucciones en Configuración de la ficha Auditoría.

• Si son flujos de trabajo carentes de plantillas de tarea, defina una variable llamada auditWorkflow y configure su valor en true .

Tenga en cuenta que la auditoría del flujo de trabajo baja el rendimiento.

El Ejemplo 10–3 ilustra el código necesario para crear eventos de auditoría de temporización. Para registrar eventos de auditoría de temporización, el argumento op debe configurarse en auditWorkflow.

El argumento action también es obligatorio y debe definirse en uno de estos valores:

• StartWorkflow

• EndWorkflow

• StartProcess

• EndProcess

• StartActivity

• EndActivity

En el archivo auditconfig.xml se pueden definir otros argumentos de acción.

Ejemplos: Comienzo y terminación de eventos de auditoría en un flujo de trabajo

El Ejemplo 10–3 ilustra la habilitación de eventos de auditoría de temporización en un flujo de trabajo. Para instrumentar un flujo de trabajo, se deben agregar eventos auditWorkflow al principio y al final de los flujos de trabajo, procesos y actividades.

La operación auditWorkflow se define en com.waveset.session.WorkflowServices . Consulte La aplicación com.waveset.session.WorkflowServices para obtener más información.

Ejemplo 10–3 Comienzo de eventos de auditoría de temporización en un flujo de trabajo

<Action application=’com.waveset.session.WorkflowServices’> 
<Argument name=’op’ value=’auditWorkflow’/> 
<Argument name=’action’ value=’StartWorkflow’/> 
</Action>

Para detener el registro de eventos de auditoría de temporización en un flujo de trabajo, incluya el código del Ejemplo 10–4 en una actividad pre-end cerca del final del flujo de trabajo. Observe que, al instrumentar un proceso o flujo de trabajo, no se permite incluir nada en una actividad end. Hay que crear una actividad pre-end que lleve a cabo el evento auditWorkflow final y después realizar una transición incondicional al evento end.

Ejemplo 10–4 Terminación de eventos de auditoría de temporización en un flujo de trabajo

<Action application=’com.waveset.session.WorkflowServices’> 
<Argument name=’op’ value=’auditWorkflow’/> <Argument name=’action’ value=’EndWorkflow’/> 
</Action>

¿Qué información almacenan los eventos de auditoría de temporización?

De manera predeterminada, los eventos de auditoría de temporización registran la mayoría de la información almacenada por los eventos de auditoría estándar, incluidos los atributos siguientes:

Los atributos anteriores se almacenan en la tabla logattr y proceden de auditableAttributesList. Identity Manager también verifica si está definido el atributo workflowAuditAttrConds.

Es posible llamar algunas actividades varias veces dentro de una misma instancia de un proceso o un flujo de trabajo. Para lograr la coincidencia de los eventos de auditoría en una determinada instancia de actividad, Identity Manager almacena un identificador único dentro de una instancia de flujo de trabajo en la tabla logattr.

Si quiere almacenar otros atributos en la tabla logattr para un flujo de trabajo, debe definir una lista workflowAuditAttrConds, que se considera una lista de objetos genéricos (GenericObjects). Si define un atributo attrName dentro de la lista workflowAuditAttrConds , Identity Manager extrae attrName del objeto dentro del código, utilizando primero attrName como clave y almacenando después el valor attrName. Todas las claves y valores se almacenan como valores en mayúsculas.

Configuración de auditoría

La configuración de auditoría consta de uno o varios publicadores y varios grupos predefinidos.

Un grupo de auditoría define un subconjunto de todos los eventos de auditoría basados en tipos de objeto, acciones y resultados de acción. A cada publicador se le asigna uno o varios grupos de auditoría. El publicador del depósito se asigna de manera predeterminada a todos los grupos de auditoría.

Un publicador de auditoría entrega eventos de auditoría a un destino de auditoría concreto. El publicador del depósito predeterminado escribe registros de auditoría en el depósito. Cada publicador de auditoría puede tener opciones de implementación específicas. A los publicadores de auditoría se les puede asignar un formateador de texto. (Los formateadores de texto aportan una representación textual de los eventos de auditoría.)

El objeto de configuración de auditoría (#ID#Configuration:AuditConfiguration) se define en el archivo sample/auditconfig.xml. Este objeto de configuración tiene una extensión que es un objeto genérico.

En el nivel superior, este objeto de configuración tiene los siguientes atributos:

• El atributo filterConfiguration

• El atributo extendedTypes

• El atributo extendedActions

• El atributo extendedResults

• El atributo publishers

El atributo filterConfiguration

El atributo filterConfiguration ofrece una lista de grupos de eventos, que sirven para habilitar la transferencia de uno o más eventos al filtro de eventos. Cada grupo de la lista del atributo filterConfiguration contiene los atributos indicados en la Tabla 10–2.

El Ejemplo 10–5 ilustra el grupo de administración de recursos predeterminado.

Ejemplo 10–5 Grupo de administración de recursos predeterminado

<Object name=’Resource Management’> <Attribute name=’enabled’ value=’true’/> 
<Attribute name=’displayName’ value=’UI_RESOURCE_MGMT_GROUP_DISPLAYNAME’/> 
<Attribute name=’enabledEvents’> <List> <Object> <Attribute name=’objectType’ value=’Resource’/> 
<Attribute name=’actions’ value=’ALL’/> <Attribute name=’results’ value=’ALL’/> </Object> <Object> 
<Attribute name=’objectType’ value=’ResourceObject’/> <Attribute name=’actions’ value=’ALL’/> 
<Attribute name=’results’ value=’ALL’/> </Object> </List> </Attribute> </Object>

Identity Manager proporciona grupos de eventos de auditoría predeterminados. Estos grupos y los eventos que habilitan se describen en las próximas secciones:

• Grupo de administración de cuentas

• Grupo de cambios fuera de Identity System

• Grupo de administración del cumplimiento

• Grupo de administración de la configuración

• Grupo de administración de eventos

• Grupo de inicios/cierres de sesión

• Grupo de administración de contraseñas

• Grupo de administración de recursos

• Grupo de administración de roles

• Grupo de administración de la seguridad

• Grupo de Service Provider

• Grupo de administración de tareas

Puede configurar grupos de eventos de auditoría en la página Configuración de auditoría de la interfaz de administración de Identity Manager (Configurar > Auditoría). Consulte las instrucciones en Configuración de grupos y eventos de auditoría.

También es posible configurar eventos satisfactorios o fallidos para cada grupo en la página Configuración de auditoría. La interfaz no permite agregar o modificar eventos habilitados para grupos, pero para ello puede utilizar las páginas de depuración de Identity Manager (Página de depuración de Identity Manager).

No todas las acciones seleccionables para un grupo de eventos de auditoría producen un registro. Además, la opción con la que se eligen todas las acciones no significa que todas las acciones de la lista estén disponibles o sean factibles para todos los grupos de eventos de auditoría.

Grupo de administración de cuentas

Este grupo está habilitado de manera predeterminada.

Grupo de cambios fuera de Identity System

Este grupo está inhabilitado de manera predeterminada.

Grupo de administración del cumplimiento

Este grupo está habilitado de manera predeterminada.

Grupo de administración de la configuración

Este grupo está habilitado de manera predeterminada.

Grupo de administración de eventos

Este grupo está habilitado de manera predeterminada.

Grupo de inicios/cierres de sesión

Este grupo está habilitado de manera predeterminada.

Grupo de administración de contraseñas

Este grupo está habilitado de manera predeterminada.

Grupo de administración de recursos

Este grupo está habilitado de manera predeterminada.

Grupo de administración de roles

Este grupo está inhabilitado de manera predeterminada.

Grupo de administración de la seguridad

Este grupo está habilitado de manera predeterminada.

Grupo de Service Provider

Este grupo está habilitado de manera predeterminada.

Grupo de administración de tareas

Este grupo está inhabilitado de manera predeterminada.

El atributo extendedTypes

Es posible auditar cada tipo nuevo que se agrega a la clase com.waveset.object.Type. A un tipo nuevo se le debe asignar una clave de base de datos única formada por dos caracteres, que se almacena en la base de datos. Todos los tipos nuevos se agregan a las distintas interfaces de informes de auditoría. Cada tipo nuevo que se deba registrar en la base de datos sin filtrar ha de añadirse a un atributo enabledEvents de grupos de eventos de auditoría (como se describe con el atributo enabledEvents).

A veces interesa auditar algo que no tiene asociada una clase com.waveset.object.Type, o representar un tipo existente con más detalles.

Por ejemplo, el objeto WSUser almacena toda la información de la cuenta del usuario en el depósito. En lugar de marcar cada evento con el tipo USER, el proceso de auditoría divide el objeto WSUser en dos tipos de auditoría distintos (cuenta de recursos y cuenta de Identity Manager). Al dividir así el objeto, resulta más fácil buscar información de cuenta específica en el registro de auditoría.

Para agregar tipos de auditoría extendidos, inclúyalos en el atributo . Cada objeto extendido debe tener los atributos indicados en la tabla siguiente.

Todas las claves específicas del cliente deben empezar por el símbolo # para evitar la duplicación de claves al añadir nuevas claves internas.

El Ejemplo 10–6 ilustra el tipo extendido de cuenta de Identity Manager.

Ejemplo 10–6 Tipo extendido de cuenta de Identity Manager

<Object name=’LighthouseAccount’> <Attribute name=’displayName’ value=’LG_LIGHTHOUSE_ACCOUNT’/> 
<Attribute name=’logDbKey’ value=’LA’/> <Attribute name=’mapsToType’ value=’User’/> 
<Attribute name=’supportedActions’> <List> <String>Disable</String> <String>Enable</String> 
<String>Create</String> <String>Modify</String> <String>Delete</String> <String>Rename</String> 
</List> </Attribute> </Object>

El atributo extendedActions

Las acciones de auditoría suelen asignarse a objetos com.waveset.security.Right. Al agregar nuevos objetos de derechos (Right), debe especificar una clave única logDbKey de dos caracteres, que se almacenará en la base de datos. A veces no hay ningún derecho que corresponda a una acción concreta que debe auditarse. Puede extender las acciones incluyéndolas en la lista de objetos del atributo extendedActions.

Cada objeto de extendedActions debe tener los atributos enumerados en la Tabla 10–16.

Todas las claves específicas del cliente deben empezar por el símbolo # para evitar la duplicación de claves al añadir nuevas claves internas.

El Tabla 10–16 muestra la inclusión de una acción para el cierre de sesión.

Ejemplo 10–7 Inclusión de una acción para el cierre de sesión

<Object name=’Logout’> <Attribute name=’displayName’ value=’LG_LOGOUT’/> 
<Attribute name=’logDbKey’ value=’LO’/> </Object>

El atributo extendedResults

Además de extender tipos y acciones, puede añadir resultados. Hay dos resultados predeterminados: Satisfactorio y No satisfactorio. Puede extender los resultados incluyéndolos en la lista de objetos del atributo extendedResults.

Cada objeto de extendedResults debe tener los atributos descritos en la Tabla 10–17.

Todas las claves específicas del cliente deben tener cifras del 0 al 9 para evitar la duplicación de claves al añadir nuevas claves internas.

El atributo publishers

Cada elemento de la lista publishers es un objeto genérico. Cada objeto publishers tiene los atributos siguientes.

Esquema de la base de datos

En el depósito de Identity Manager hay dos tablas donde se almacenan los datos de auditoría:

• waveset.log: Almacena la mayoría de los detalles de los eventos.

• waveset.logattr: Almacena los ID de las organizaciones a las que pertenece cada evento.

Estas tablas se describen a continuación.

Cuando los datos del registro de auditoría exceden los límites de longitud de columna especificados para las tablas anteriores, Identity Manager trunca los datos para que quepan. El truncamiento del registro de auditoría se trata en Truncamiento del registro de auditoría.

Algunas columnas del registro de auditoría tienen límites de longitud de columna configurables. Encontrará información sobre esas columnas y cómo cambiar sus límites de longitud en Configuración del registro de auditoría.

La tabla waveset.log

A continuación se describen los distintos nombres de columna y tipos de datos de la tabla waveset.log. Los tipos de datos proceden de la definición de base de datos de Oracle y varían ligeramente entre las distintas bases de datos. Encontrará una lista de los valores de esquema de datos para todas las bases de datos compatibles en el Apéndice BEsquema de base de datos de registros de auditoría.

Para aprovechar el espacio, algunos valores de columna se almacenan como claves en la base de datos. Las definiciones de las claves se encuentran en la sección Asignaciones de base de datos de registros de auditoría.

• objectType CHAR(2): Una clave de dos caracteres que representa el tipo de objeto auditado.

• action CHAR(2): Una clave de dos caracteres que representa la acción realizada.

• actionStatus CHAR(1): Una clave de un carácter que representa el resultado de la acción realizada.

• reason CHAR(2): Una clave de base de datos formada por dos caracteres que sirve para describir un objeto ReasonDenied en caso de fallo. ReasonDenied es una clase que ajusta una entrada del catálogo de mensajes y se utiliza con fallos habituales, como credenciales no válidas o privilegios insuficientes.

• actionDateTimeVARCHAR(21): La fecha y la hora en que se produjo la acción antes indicada. Este valor se almacena en formato horario GMT.

• objectName VARCHAR(128): El nombre del objeto sobre el que se ha actuado durante una operación.

• resourceName VARCHAR(128): El nombre del recurso utilizado durante una operación, si procede. Algunos eventos no referencian recursos, pero a veces se consiguen más detalles registrando el recurso donde se ha efectuado una operación.

• accountName VARCHAR(255): El ID de cuenta sobre el que se actúa, si procede.

• server VARCHAR(128): El servidor donde se ha realizado la acción (lo asigna automáticamente el registrador de eventos).

• message VARCHAR(255*)o CLOB: Cualquier mensaje localizado asociado a una acción que incluya algo como mensaje de error. El texto se almacena para impedir que se internacionalice. El límite de longitud de esta columna es configurable. El tipo de datos predeterminado es VARCHAR, mientras que el límite de tamaño predeterminado es 255. Consulte Configuración del registro de auditoría para obtener información sobre cómo ajustar el límite de tamaño.

• interface VARCHAR(50): La interfaz de Identity Manager (por ejemplo, de administración, usuario, IVR o SOAP) desde la que se ha efectuado la operación.

• acctAttrChanges VARCHAR(4000) to CLOB: Almacena los atributos de la cuenta que han cambiado durante la creación y la actualización. El campo de los cambios de atributos siempre se rellena al crear o actualizar una cuenta de recursos o un objeto de cuenta de Identity Manager. Todos los atributos modificados durante una acción se almacenan en este campo como una cadena. Los datos adoptan el formato NOMBRE=VALOR NOMBRE2=VALOR2. Este campo se puede consultar ejecutando instrucciones SQL “contains” en el nombre o el valor.

  El siguiente código de ejemplo ilustra un valor de la columna acctAttrChanges.

  COMPANY="COMPANY" DEPARTMENT="DEPT" DESCRIPTION="DSMITH DESCRIPTION" FAX NUMBER="5122222222" HOME ADDRESS="12282 MOCKINGBIRD LANE" HOME CITY="AUSTIN" HOME PHONE="5122495555" HOME STATE="TX" HOME ZIP="78729" JOB TITLE="DEVELOPER" MOBILE PHONE="5125551212" WORK PHONE="5126855555" EMAIL="someone@somecompany.COM" EXPIREPASSWORD="TRUE" FIRSTNAME="DANIEL" FULLNAME="DANIEL SMITH" LASTNAME="SMITH"

  ---

  Nota –

  Si su instalación de Identity Manager utiliza un depósito de Oracle y percibe errores de truncamiento en el registro de auditoría, puede convertir el campo accountAttrChanges de VARCHAR(4000) a CLOB en la tabla del registro de auditoría. En el directorio /web/sample de Identity Manager hay un ejemplo de secuencia de comandos DDL que convierte log.acctAttrChanges de VARCHAR(4000) a CLOB. La secuencia de comandos convert_log_acctAttrChangesCHAR2CLOB.oracle.sql preserva los datos existentes y permite usar más 4.000 caracteres en el campo accountAttrChanges.

  Esta conversión es opcional y sólo debe realizarse si se aprecian errores de truncamiento. Asimismo, asegúrese de realizar una copia seguridad de las tablas afectadas antes de ejecutar la secuencia de comandos de conversión.

  Tras ejecutar la secuencia de comandos, detenga y reinicie el servidor de aplicaciones web. Deberá aparecer correctamente cuando ejecute un nuevo informe.

  ---

• acctAttr01label-acctAttr05label VARCHAR(50): Estas cinco celdas NAME adicionales son columnas que pueden propiciar el almacenamiento de hasta cinco nombres de atributo en sus propias columnas, en lugar de la columna blob grande. Un atributo puede ascenderse desde la página de configuración de esquemas de recursos mediante el parámetro "¿auditar?", con lo cual el atributo quedará disponible para minería de datos.

• acctAttr01value-acctAttr05value VARCHAR(128): Cinco celdas NAME adicionales que pueden propiciar el almacenamiento de hasta cinco valores de atributo en una columna distinta, en lugar de la columna blob.

• parm01label-parm05label VARCHAR(50): Cinco celdas donde se almacenan los parámetros asociados a un evento, por ejemplo, los nombres de IP de cliente y ID de sesión.

• parm01value-parm05value VARCHAR(128*) o CLOB: Cinco celdas donde se almacenan los parámetros asociados a un evento, por ejemplo, los valores de IP de cliente y ID de sesión. El límite de longitud de estas columnas es configurable. El tipo de datos predeterminado es VARCHAR, mientras que el límite de tamaño predeterminado es 128. Consulte Configuración del registro de auditoría para obtener información sobre cómo ajustar el límite de tamaño.

• id VARCHAR(50): ID único que asigna a cada registro el depósito referenciado en la tabla waveset.logattr.

• name VARCHAR(128): Nombre generado asignado a cada registro.

• xml BLOB: Para uso interno de Identity Manager.

La tabla waveset.logattr

La tabla waveset.logattr sirve para almacenar los ID de la afiliación organizativa correspondiente a cada evento, que se utiliza para determinar el ámbito del registro de auditoría por organización.

• id VARCHAR(50): ID del registro waveset.log .

• attrname VARCHAR(50): En la actualidad es siempre MEMBEROBJECTGROUPS.

• attrval VARCHAR(255): ID del grupo MemberObject al que pertenece el evento.

Truncamiento del registro de auditoría

Cuando una o varias columnas de datos del registro de auditoría exceden los límites de longitud de columna especificados, sus datos se truncan para que quepan. En concreto, los datos se truncan hasta el límite especificado menos tres caracteres. Para indicar que los datos se han truncado, se les añaden puntos suspensivos (...) al final de la columna.

Además, al principio de la columna NAME de ese registro de auditoría se añade la cadena #TRUNCATED# para facilitar la consulta de los registros truncados.

Identity Manager adopta la codificación UTF–8 cuando calcula dónde truncar los mensajes. Si su configuración utiliza otro tipo de codificación, es posible que los datos truncados sigan excediendo el tamaño de columna actual en la base de datos. En tal caso, el mensaje truncado no aparecerá en el registro de auditoría y se incluirá un error en el registro del sistema.

Configuración del registro de auditoría

Algunas columnas del registro de auditoría pueden configurarse para almacenar grandes cantidades de datos en el depósito.

Cambio de los límites de longitud de columna

Varias columnas del registro de auditoría tienen límites de longitud de columna configurables. Son:

• La columna message

• Las columnas parmNNvalue (donde NN = 01, 02, 03, 04 o 05)

• La columna xml

Las columnas del registro de auditoría se describen en Esquema de la base de datos.

Los límites de longitud de las columnas se pueden cambiar editando el objeto RepositoryConfiguration . Encontrará instrucciones para editar el objeto RepositoryConfiguration en Edición de objetos de configuración de Identity Manager.

• Para cambiar el límite de longitud de la columna message, modifique el valor de maxLogMessageLength.

• Para cambiar el límite de longitud de la columna parmNNvalue, modifique el valor de maxLogParmValueLength. El mismo valor límite se aplica a las cinco columnas. No es posible definir valores de longitud de columna distintos.

• Para cambiar el límite de longitud de la columna xml, modifique el valor de maxLogXmlLength.

Reinicie el servidor para que los nuevos valores surtan efecto.

Los valores de límite de longitud de columna indicados en el objeto RepositoryConfiguration determinan la cantidad máxima de datos que pueden almacenarse en una columna. Si los datos que se van a almacenar superan estos valores de configuración, Identity Manager trunca los datos. Para obtener más información, consulte Truncamiento del registro de auditoría.

Si aumenta el valor de longitud de columna en el objeto RepositoryConfiguration, compruebe también si el valor de tamaño de columna en la base de datos es al menos igual al tamaño configurado en dicho objeto.

Supresión de registros del registro de auditoría

Conviene truncar el registro del sistema periódicamente para evitar que alcance un tamaño excesivo. Utilice Tarea de mantenimiento de AuditLog para programar una tarea que suprima los registros viejos del registro de auditoría.

1. En la interfaz de administración, seleccione Tareas del servidor -> Administrar programación.

2. Dentro de la sección Tareas disponibles para programación, haga clic en Tarea de mantenimiento de AuditLog.

   Aparece la página Crear nueva programación de tareas Tarea de mantenimiento de AuditLog.

3. Rellene el formulario y pulse Guardar.

Uso de publicadores de auditoría personalizados

Identity Manager puede enviar eventos de auditoría a publicadores de auditoría personalizados.

Hay disponibles los siguientes publicadores personalizados:

• Consola. Imprime los eventos de auditoría en la salida estándar o el error estándar.

• Archivo. Escribe los eventos de auditoría en un archivo sin formato.

• JDBC. Graba los eventos de auditoría en un almacén de datos JDBC.

• JMS. Graba los eventos de auditoría en un tema o una cola de JMS.

• JMX. Publica los eventos de auditoría de manera que un cliente JMX (Java Management Extensions) pueda supervisar la actividad del registro de auditoría de Identity Manager.

• Secuencia de comandos. Permite usar secuencias de comandos personalizadas para almacenar eventos de auditoría.

Si prefiere crear su propio publicador, consulte Desarrollo de publicadores de auditoría personalizados.

En esta sección se tratan los temas siguientes:

• Para habilitar publicadores de auditoría personalizados

• Los tipos de publicadores de consola, archivo, JDBC y secuencia de comandos

• El tipo de publicador JMS

• El tipo de publicador JMX

Para habilitar publicadores de auditoría personalizados

Los publicadores de auditoría personalizados se habilitan en la página Configuración de auditoría.

1. En la interfaz de administración, seleccione Configurar en el menú principal y después Auditoría en el menú secundario.

   Aparece la página Configuración de auditoría.

2. Seleccione la opción Utilizar publicador personalizado al final de la página.

   Se abre una tabla con los publicadores de auditoría actualmente configurados.

3. Para configurar un publicador de auditoría nuevo, seleccione el tipo de publicador personalizado en el menú desplegable Nuevo publicador.

   Rellene el formulario Configurar nuevo publicador de auditoría. Pulse Aceptar.

4. Importante. Pulse Guardar para guardar el nuevo publicador de auditoría.

Los tipos de publicadores de consola, archivo, JDBC y secuencia de comandos

Para habilitar los publicadores de auditoría de consola, archivo, JDBC o secuencia de comandos, siga los pasos indicados en el apartado Para habilitar publicadores de auditoría personalizados. Seleccione el tipo de publicador adecuado en el menú desplegable Nuevo publicador.

Rellene el formulario Configurar nuevo publicador de auditoría. Para cualquier cuestión sobre el formulario, consulte los elementos i-Help y la ayuda en línea.

• El publicador de auditoría de consola imprime los eventos de auditoría en la salida estándar o en el error estándar.

• El publicador de auditoría de archivo escribe los eventos de auditoría en un archivo sin formato.

• El publicador de auditoría JDBC graba los eventos de auditoría en un almacén de datos JDBC.

• El publicador de auditoría de secuencia de comandos permite crear secuencias de comandos personalizadas en JavaScript o BeanShell para almacenar eventos de auditoría.

El tipo de publicador JMS

El publicador personalizado JMS de registro de auditoría permite publicar registros de eventos de auditoría en un tema o una cola de JMS (Java Message Service).

¿Por qué utilizar JMS?

Publicar en JMS ofrece más flexibilidad de correlación en los entornos con varios servidores de Identity Manager. Además, JMS puede utilizarse en los casos que presentan restricciones para utilizar el publicador de registro de auditoría en archivo, como los entornos de Windows que impiden que una herramienta de informes cliente acceda al registro mientras se está ejecutando el servidor.

JMS aporta diversas ventajas en los entornos con varios servidores:

• El almacén de mensajes de JMS centraliza (y simplifica) el almacenamiento y la recuperación de mensajes.

• La arquitectura de JMS no restringe el número de clientes que pueden acceder al servicio.

• El protocolo JMS es fácil de transmitir a través de servidores de seguridad y otra infraestructura de red.

¿Punto a punto o publicar y suscribir?

Java Message System ofrece dos modelos de mensajería: el modelo punto a punto o de cola y el modelo publicar y suscribir o de temas. Identity Manager admite ambos modelos.

En el modelo punto a punto, un productor envía los mensajes a una cola determinada y un consumidor lee los mensajes de la cola. En este caso, el productor conoce el destino del mensaje y lo envía directamente a la cola del consumidor.

El modelo punto a punto posee las características siguientes:

• El mensaje llega a un único consumidor.

• No es necesario que el productor se esté ejecutando en el momento en que el destinatario consume el mensaje, ni que el destinatario se esté ejecutando en el momento en que se envía el mensaje.

• El destinatario acusa recibo de cada mensaje procesado.

Por su parte, el modelo de publicar y suscribir permite publicar mensajes en un tema de mensaje específico. Ninguno o más suscriptores pueden registrar su interés en recibir mensajes sobre un tema determinado. Con este modelo, el publicador y el suscriptor se desconocen entre sí. Los tablones de anuncios anónimos son metáforas representativas de este modelo.

El modelo de publicar y suscribir posee las características siguientes:

• Pueden recibir los mensajes múltiples consumidores.

• Hay una dependencia temporal entre publicadores y suscriptores. El publicador debe crear una suscripción a la que puedan abonarse los clientes. Una vez abonados, los suscriptores han de permanecer activos continuamente para poder recibir los mensajes, salvo que se haya definido una suscripción duradera. Si la suscripción es duradera, los mensajes publicados mientras el suscriptor no está conectado se redistribuirán cuando vuelva a conectarse.

Encontrará información sobre JMS, en http://www.sun.com/software/products/message_queue/index.xml

Configuración del tipo de publicador JMS

El publicador de JMS asigna a los eventos de auditoría formato de mensajes de texto de JMS. Según la configuración, estos mensajes de texto se envían a una cola o a un tema. También según la configuración, los mensajes de texto pueden adoptar formato XML o formato de registro universal (UFL).

Para habilitar el tipo de publicador JMS, siga los pasos indicados Para habilitar publicadores de auditoría personalizados y seleccione JMS en el menú desplegable Nuevo publicador.

Para configurar el tipo de publicador JMS, rellene el formulario Configurar nuevo publicador de auditoría. Para cualquier cuestión sobre el formulario, consulte los elementos i-Help y la ayuda en línea.

El tipo de publicador JMX

El publicador de registro de auditoría JMX publica los eventos de auditoría de manera que un cliente JMX (Java Management Extensions) pueda supervisar la actividad del registro de auditoría de Identity Manager.

¿Qué es JMX?

Java Management Extensions (JMX) es una tecnología Java que permite administrar y/o supervisar aplicaciones, objetos del sistema, dispositivos y redes orientadas al servicio. La entidad administrada/supervisada se representa mediante objetos llamados MBean (del inglés "Managed Bean", bean administrado).

Implementación del publicador JMX de Identity Manager

El publicador de registro de auditoría JMX de Identity Manager supervisa los eventos del registro de auditoría. Cuando detecta un evento, el publicador JMX ajusta el registro de eventos de auditoría con un MBean y también actualiza un historial temporal (que se conserva en memoria). Por cada evento se envía una pequeña notificación específica al cliente de JMX. Si el evento interesa, el cliente de JMX puede consultar el MBean y ajustar el evento de auditoría para obtener más información.

Para obtener información sobre los registros de eventos de auditoría, consulte el Javadoc com.waveset.object.AuditEvent. El Javadoc está disponible en el kit REF, que se describen en Desarrollo de publicadores de auditoría personalizados.

Para recuperar información del MBean correcto, se necesita un número de secuencia del historial. Este número se incluye en la notificación del evento.

Cada notificación de evento contiene la siguiente información:

• Tipo. Una cadena descriptiva del tipo de evento. La cadena sigue el formato AuditEvent.<ObjectType>.<Action> donde ObjectType y Action se devuelven desde com.waveset.AuditEvent. Por ejemplo, si se envía un evento desbloqueado, el tipo sería AuditEvent.LighthouseAccount.Unlock .

• Número de secuencia. La clave de búfer del historial que se utiliza para consultar información del MBean.

Para configurar el tipo de publicador JMX

1. Para habilitar el tipo de publicador JMX, siga los pasos indicados Para habilitar publicadores de auditoría personalizados y seleccione JMX en el menú desplegable Nuevo publicador.

2. Para configurar el tipo de publicador JMX, rellene el formulario Configurar nuevo publicador de auditoría. Para cualquier cuestión sobre el formulario, consulte los elementos i-Help y la ayuda en línea.

   • Nombre de publicador. Escriba un nombre único para el publicador de eventos de auditoría JMX.

   • Límite de historial. Cambie el valor predeterminado para indicar el número de elementos de evento que el publicador debe conservar en la memoria. (El valor predeterminado es 100.)

3. Haga clic en Probar para asegurarse de que el nombre de publicador es aceptable.

4. Haga clic en Aceptar. El formulario Configurar nuevo publicador de auditoría se cierra.

5. Importante. Pulse Guardar.

Visualización de eventos de auditoría con un cliente de JMX

Use un cliente de JMX para ver le publicador JMX. Las capturas de pantalla siguientes se han generado con JConsole, que se incluye en JDK 1.5.

Si utiliza JConsole, elija "attach to process" para ver el MBean IDM:type=AuditLog . Encontrará información para configurar JConsole con el fin de usarlo como un cliente de JMX en la sección Viewing JMX Data de Sun Identity Manager 8.1 System Administrator’s Guide .

En JConsole, seleccione la ficha "Notifications" para ver los eventos de auditoría. Fíjese en el número de secuencia de la notificación. Necesitará el número de secuencia si quiere consultar más información en el MBean.

Figura 10–1 Visualización de notificaciones de eventos de auditoría JMX en JConsole

Consulta de información adicional en el MBean

En JConsole, seleccione la ficha "Operations". Use el número de secuencia de la notificación para consultar los detalles del evento en el MBean. Cada operación lleva el prefijo ’get’ y el único parámetro es el número de secuencia.

Figura 10–2 Consulta de información adicional en el MBean desde JConsole

El MBean es una asignación virtual de uno a uno a la clase com.waveset.object.AuditEvent . En la Tabla 10–19 se describe cada atributo/operación que ofrece el MBean.

En JConsole, seleccione la ficha "Attributes". Los atributos llevan el prefijo Current para indicar que contienen el último evento de auditoría enviado al sistema.

Figura 10–3 Visualización de atributos de MBean en JConsole

Desarrollo de publicadores de auditoría personalizados

En esta sección se explica cómo crear un publicador de auditoría personalizado nuevo en Java.

Los publicadores personalizados de consola, archivo y JDBC que se suministran con Identity Manager implementan la interfaz AuditLogPublisher. El código fuente de estos publicadores se halla en el kit REF. La documentación de las interfaces también está disponible en el kit REF en formato Javadoc. (Consulte los detalles de la interfaz en el Javadoc.)

El kit REF (Resource Extension Facility) se encuentra en el directorio /REF del CD del producto o en la imagen de instalación.

Animamos a los desarrolladores a que amplíen la clase AbstractAuditLogPublisher. Esta clase analiza la configuración y se asegura de que todas las opciones necesarias se hayan suministrado al publicador. (Consulte los publicadores de ejemplo en el kit REF.)

Los publicadores necesitan un constructor no-arg.

Ciclo de vida de los publicadores

Un publicador sigue el ciclo de vida siguiente:

1. Se instancia el objeto.

2. El Formateador (en su caso) se define con el método setFormatter() .

3. Se suministran las opciones con el método configure( Map).

4. Se publican los eventos con el método publish( Map, LoggingErrorHandler).

5. Se termina el publicador con el método shutdown().

Los pasos 1-3 se ejecutan cuando se inicia Identity Manager y siempre que se actualiza la configuración de auditoría. El paso 4 no se produce si no se genera ningún evento de auditoría antes de llamar al cierre.

El método configure(Map ) sólo se llama una vez en el mismo objeto de publicador. (No es necesario que el publicador se prepare para los cambios de configuración puntuales.) Una vez actualizada la configuración de auditoría, los publicadores actuales se cierran y se crean los nuevos.

El método configure() del paso 3 puede lanzar una excepción WavesetException . En tal caso, no se tendrá en cuenta el publicador ni se efectuarán más llamadas a él.

Configuración del publicador

Los publicadores pueden tener varias opciones o ninguna. El método getConfigurationOptions() devuelve la lista de opciones que admite el publicador. Las opciones se encapsulan mediante la clase PublisherOption (consulte los detalles de esta clase en el Javadoc). El visor de configuración de auditoría invoca este método cuando genera la interfaz de configuración para el publicador.

Identity Manager configura el publicador con el método configure( Map) al iniciarse el servidor y cuando se modifica la configuración de auditoría.

Desarrollo de formateadores

El kit REF incluye el código fuente de los siguientes formateadores:

• XmlFormatter. Asigna a los eventos de auditoría formato de cadenas XML.

• UlfFormatter. Asigna a los eventos de auditoría formato de registro universal (ULF). Sun Application Server utiliza este formato.

Los formateadores deben implementar la interfaz AuditRecordFormatter. Además, necesitan un constructor no-arg. Consulte los detalles en el Javadoc incluido con el kit REF.

Registro de publicadores/formateadores

El atributo de auditoría del objeto #ID#Configuration:SystemConfiguration ofrece una lista con todos los publicadores y formateadores registrados. En la interfaz de usuario de configuración de auditoría sólo están disponibles esos publicadores y formateadores.