Chapitre 10 Journalisation d'audit

Ce chapitre explique la façon dont le système d'audit enregistre les événements.

Les informations sont organisées dans les rubriques suivantes :

• Présentation de la journalisation d'audit ;

• Rôle de l'audit dans Identity Manager ;

• Création d'événements de contrôle à partir des flux de travaux ;

• Configuration d'audit ;

• Schéma de la base de données ;

• Configuration du journal d'audit ;

• Suppression d'enregistrements dans le journal d'audit ;

• Utilisation d'éditeurs d'audit personnalisés ;

• Développement d'éditeurs d'audit personnalisés.

Présentation de la journalisation d'audit

L'objectif de l'audit d'Identity Manager est d'enregistrer qui a fait quoi sur quel objet Identity Manager et pour quelle raison.

Les événements de contrôle ou d'audit sont gérés par un ou plusieurs éditeurs. Par défaut, Identity Manager enregistre les événements de contrôle dans le référentiel en utilisant l'éditeur du référentiel. Le filtrage, avec l'aide de groupes d'audit, permet à l'administrateur de sélectionner un sous-ensemble d'événements de contrôle pour les enregistrer. Chaque éditeur peut se voir assigner un ou plusieurs groupes d'audit activés au départ.

Pour plus d'informations sur le contrôle et la gestion des violations commises par les utilisateurs, voir le Chapitre 13Audit des identités : principes de base.

Rôle de l'audit dans Identity Manager

La plupart de l'audit par défaut est effectué par les composants internes d'Identity Manager. Certaines interfaces permettent toutefois de générer des événements à partir de flux de travaux ou de code Java.

L'instrumentation d'audit par défaut d'Identity Manager est concentrée sur quatre zones principales :

• L'approvisionneur. Un composant interne connu sous le nom d'approvisionneur peut gérer des événements de contrôle.

• Les gestionnaires de vues. Dans l'architecture de type vue, le gestionnaire de vues génère des enregistrement d'audit. Un gestionnaire de vues doit toujours contrôler quand des objets sont créés ou modifiés.

• La session. Les méthodes de session (par exemple checkinObject, createObject, runTask, login et logout) créent un enregistrement d'audit après avoir terminé une opération auditable. La plupart de l'instrumentation est poussée dans les gestionnaires de vues.

• Le flux de travaux. Par défaut, seuls les flux de travaux d'approbation sont instrumentés pour générer des enregistrements d'audit. Ils génèrent un événement de contrôle lorsque les demandes sont approuvées ou rejetées. L'interfaçage avec la fonctionnalité de flux de travaux du journal d'audit se fait au travers de l'application com.waveset.session.WorkflowServices. Pour plus d'informations, voir la section suivante.

Création d'événements de contrôle à partir des flux de travaux

Par défaut, seuls les flux de travaux d'approbation sont instrumentés pour générer des enregistrements d'audit. Cette section décrit l'utilisation de l'application com.waveset.session.WorkflowServices pour générer des événements de contrôle supplémentaires à partir de tout processus de flux de travaux.

Des événements de contrôle supplémentaires peuvent être nécessaires si vous devez effectuer des rapports sur des flux de travaux personnalisés. Pour toute information sur l'ajout d'événements de contrôle aux flux de travaux, voir Modification des flux de travaux pour consigner les événements de contrôle standard.

Des événements de contrôle spéciaux peuvent aussi être ajoutés aux flux de travaux en appui des rapports de flux de travaux (Rapports de flux de travaux). Les rapports de flux de travaux rapportent le temps employé par les flux de travaux pour se compléter. Des événements de contrôle spéciaux sont requis pour stocker les données nécessaires au calcul de cette durée. Pour toute information sur l'ajout d'événements de contrôle de synchronisation aux flux de travaux, voir Modification des flux de travaux pour consigner les événements de synchronisation standard.

L'application com.waveset.session.WorkflowServices

L'application com.waveset.session.WorkflowServices génère des événements de contrôle à partir de tout processus de flux de travaux. Le Tableau 10–1 détaille les arguments disponibles pour cette application.

Modification des flux de travaux pour consigner les événements de contrôle standard

Pour créer un événement d'audit standard dans un flux de travaux, ajoutez l'élément <Activity> suivant à ce flux de travaux.

<Activity name=’createEvent’>

Ensuite, imbriqué dans l'élément <Activity>, incluez un élément <Action> qui référencie l'application com.waveset.session.WorkflowServices :

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

Imbriqué dans l'élément <Action>, incluez les éléments <Argument> obligatoires et optionnels. Pour la liste des arguments, voir le Tableau 10–1.

Pour consigner les événements de contrôle standard, l'argument op doit être sur défini sur audit.

Les Exemples de flux de travaux montrent le code minimum requis pour créer un événement de contrôle standard.

Exemples de flux de travaux

L'exemple suivant illustre une activité de flux de travaux simple et montre la génération d'un événement qui enregistrera une activité de suppression de ressource nommée ADSIResource1, effectuée par ResourceAdministrator.

Exemple 10–1 Activité de flux de travaux 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>

Les exemples suivants illustrent la façon dont vous pouvez ajouter des attributs spécifiques à un flux de travaux qui suit les modifications appliquées par chaque utilisateur dans un processus d'approbation à un niveau granulaire. Cette addition suivra normalement une ManualAction sollicitant une saisie d'un utilisateur.

ACTUAL_APPROVER est défini dans le formulaire et dans le flux de travail (si l'approbation se fait depuis le tableau des approbations) sur la base de la personne qui a effectivement effectué l'approbation. APPROVER identifie la personne à qui l'approbation a été assignée.

Exemple 10–2 Attributs ajoutés pour suivre les changements dans un processus d'approbation

 
<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>

Modification des flux de travaux pour consigner les événements de synchronisation standard

Les flux de travaux peuvent être modifiés pour consigner des événements de contrôle en appui des rapports de flux de travaux (Rapports de flux de travaux). Les événements de contrôle standard se limitent à consigner qu'un événement s'est produit tandis que les événements de contrôle de synchronisation consignent le démarrage et l'arrêt d'un événement ce qui permet d'effectuer des calculs de durée. En plus des données des événements de synchronisation, la plupart des informations enregistrées par les événements de contrôle standard sont également enregistrées. Pour plus d'informations, voir Informations stockées par les événements de contrôle de synchronisation.

Pour consigner les événements de contrôle de synchronisation, vous devez commencer par activer le contrôle du flux de travaux pour chacun des types de flux de travaux que vous envisagez de contrôler.

• Pour les flux de travaux que vous pouvez configurer dans l'interface Administrateur en utilisant les modèles de tâches, commencez par activer le modèle de tâche correspondant au flux de travaux à contrôler. Pour les instructions, voir Activation des modèles de tâches.

  Activez ensuite le contrôle des flux de travaux en sélectionnant la case à cocher Contrôler l’intégralité du flux de travaux. Pour les instructions, voir Configuration de l'onglet Vérification informatique .

• Pour les flux de travaux qui n'ont pas de modèles de tâches, définissez une variable nommée auditWorkflow et définissez-en la valeur sur true.

Sachez toutefois que l'audit des flux de travaux dégrade la performance.

L'Exemple 10–3 indique le code nécessaire pour créer des événements de contrôle de synchronisation. Pour consigner les événements de contrôle de synchronisation, l'argument op doit être sur défini sur auditWorkflow.

L'argument action est également obligatoire et doit être défini sur l'une des valeurs suivantes :

• StartWorkflow

• EndWorkflow

• StartProcess

• EndProcess

• StartActivity

• EndActivity

Des arguments d'action supplémentaires peuvent être définis dans auditconfig.xml.

Exemples : Démarrage et arrêt des événements de contrôle dans un flux de travail

L'Exemple 10–3 illustre l'activation des événements de contrôle de synchronisation dans un flux de travaux. Pour instrumenter un flux de travaux, les événements auditWorkflow doivent être ajoutés au début et à la fin des flux de travaux, processus et activités.

L'opération auditWorkflow est définie dans com.waveset.session.WorkflowServices . Pour plus d'informations, voir la section L'application com.waveset.session.WorkflowServices.

Exemple 10–3 Démarrage des événements de contrôle de synchronisation dans un flux de travaux

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

Pour arrêter la consignation des événements de contrôle de synchronisation dans un flux de travaux, ajoutez le code de l'Exemple 10–4 à une activité pre-end près de la conclusion du flux de travaux. Sachez que lors de l'instrumentation d'un flux de travaux ou d'un processus, vous n'êtes pas autorisé à mettre quoi que soit dans une activité end. Vous devez créer une activité pre-end qui effectue l'événement auditWorkflow final et passe sans conditions à l'événement end.

Exemple 10–4 Arrêt des événements de contrôle de synchronisation dans un flux de travaux

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

Informations stockées par les événements de contrôle de synchronisation

Par défaut, les événements de contrôle de synchronisation consignent la plupart des informations stockées par les événements de contrôle standard, notamment les attributs suivants :

Les attributs ci-dessus sont stockés dans le tableau logattr et sont issus de auditableAttributesList. Identity Manager vérifie également si l'attribut workflowAuditAttrConds est défini.

Il est possible d'appeler plusieurs fois certaines activités au sein d'une unique instance de processus ou flux de travaux. Pour faire correspondre les événements de contrôle pour une instance d'activité donnée, Identity Manager stocke un identificateur unique au sein d'une instance de flux de travaux dans le tableau logattr.

Pour stocker des attributs supplémentaires dans le tableau logattr d'un flux de travaux, vous devez définir une liste workflowAuditAttrConds, que l'on assume être une liste de GenericObjects. Si vous définissez un attribut attrName dans la liste workflowAuditAttrConds, Identity Manager extrait attrName de l'objet dans le code, d'abord en utilisant attrName en tant que clé puis en stockant la valeur d'attrName. L'ensemble des clés et valeurs sont stockées sous forme de valeurs en majuscules.

Configuration d'audit

La configuration d'audit est composée de un ou plusieurs éditeurs et de plusieurs groupes prédéfinis.

Un groupe d'audit définit un sous-ensemble des événements de contrôle sur la base des types d'objets, actions et résultats des actions. Chaque éditeur se voit assigner un ou plusieurs groupes d'audit. Par défaut, l'éditeur du référentiel est assigné à tous les groupes d'audit.

Un éditeur d'audit délivre des événements de contrôle à une destination d'audit particulière. L'éditeur de référentiel par défaut écrit les enregistrements d'audit dans le référentiel. Tout éditeur d'audit peut avoir des options spécifiques à l'implémentation. Les éditeurs d'audit peuvent avoir un programme de formatage assigné (les programmes de formatage assurent la représentation textuelle des événements de contrôle).

L'objet Configuration d’audit (#ID#Configuration:AuditConfiguration) est défini dans le fichier sample/auditconfig.xml. Cet objet Configuration a une extension qui est un objet générique.

Au niveau supérieur, cet objet Configuration a les attributs suivants :

• Attribut filterConfiguration,

• L'attribut extendedTypes,

• L'attribut extendedActions,

• L'attribut extendedResults,

• L'attribut publishers.

Attribut filterConfiguration

L'attribut filterConfiguration liste les groupes d'événements, utilisés pour permettre à un ou plusieurs événements de passer à travers le filtre d'événements. Chacun des groupes listés dans l'attribut filterConfiguration contient les attributs listés dans le Tableau 10–2.

L'Exemple 10–5 illustre le groupe Gestion des ressources (Resource Management) par défaut.

Exemple 10–5 Le groupe Gestion des ressources (Resource Management) par défaut

<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 fournit des groupes d'événements de contrôle par défaut. Ces groupes et les événements qu'ils autorisent sont décrits dans les sections suivantes :

• Groupe Gestion des comptes,

• Groupe Modifications hors Identity System,

• Groupe Gestion de la conformité,

• Groupe Gestion de la configuration,

• Groupe Gestion d’événement,

• Groupe Connexions/Déconnexions,

• Groupe Gestion des mots de passe,

• Groupe Gestion des ressources,

• Groupe Gestion des rôles,

• Groupe Gestion de la sécurité,

• Groupe Service Provider,

• Groupe Gestion des tâches.

Vous pouvez configurer des groupes d'événements de contrôle à partir de la page Configuration d'audit de l'interface administrateur d'Identity Manager (Configurer > Vérification informatique). Pour les instructions, voir Configuration de groupes et d'événements d'audit.

Vous pouvez aussi configurer les événements de type réussite et échec pour chaque groupe toujours à partir de la page Configuration d'audit. L'interface ne prend pas en charge l'ajout ou la modification d'événements pour les groupes, mais vous pouvez le faire en utilisant les pages de débogage d'Identity Manager (Page de débogage d'Identity Manager).

Certaines actions que vous pouvez choisir pour un audit ne génèrent pas d'enregistrement de journal.. De même, sélectionner l'option « All Actions » (Toutes les actions) ne signifie pas que toutes les actions listées sont disponibles ou possibles pour tous les groupes d'événements de contrôle.

Groupe Gestion des comptes

Ce groupe est activé par défaut.

Groupe Modifications hors Identity System

Ce groupe est désactivé par défaut.

Groupe Gestion de la conformité

Ce groupe est activé par défaut.

Groupe Gestion de la configuration

Ce groupe est activé par défaut.

Groupe Gestion d’événement

Ce groupe est activé par défaut.

Groupe Connexions/Déconnexions

Ce groupe est activé par défaut.

Groupe Gestion des mots de passe

Ce groupe est activé par défaut.

Groupe Gestion des ressources

Ce groupe est activé par défaut.

Groupe Gestion des rôles

Ce groupe est désactivé par défaut.

Groupe Gestion de la sécurité

Ce groupe est activé par défaut.

Groupe Service Provider

Ce groupe est activé par défaut.

Groupe Gestion des tâches

Ce groupe est désactivé par défaut.

L'attribut extendedTypes

Tout nouveau type ajouté à la classe com.waveset.object.Type peut être contrôlé. Une clé de base de données unique composée de deux caractères et stockée dans la base de données doit être assignée à tout nouveau type. Tous les nouveaux types sont ajoutés aux diverses interfaces de génération de rapports d'audit. Tout nouveau type devant être consigné dans la base de données sans être filtré doit être ajouté à l'attribut enabledEvents d'un groupe d'événements de contrôle (comme décrit dans la section relative à l'attribut enabledEvents).

Vous pouvez dans certains cas vouloir contrôler un élément associé à aucun com.waveset.object.Type ou représenter un type existant avec une granularité plus poussée.

Par exemple, l'objet WSUser stocke l'ensemble des informations de compte de l'utilisateur dans le référentiel. Au lieu de marquer chaque événement comme de type USER, le processus d'audit scinde l'objet WSUser en deux types d'audit différents (Compte de ressource et Compte Identity Manager). Scinder l'objet de cette façon facilite la recherche d'informations de compte spécifiques dans le journal d'audit.

Ajoutez des types d'audit étendus en les ajoutant à l'attribut extendedObjects. Chaque objet étendu doit avoir les attributs listés dans le tableau suivant.

Toutes les clés spécifiques au client doivent commencer par le symbole # pour éviter tout doublon en cas d'ajout de nouvelles clés internes.

L'Exemple 10–6 illustre le type étendu Compte Identity Manager.

Exemple 10–6 Type étendu Compte 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>

L'attribut extendedActions

Les actions d'audit mappent normalement vers des objets com.waveset.security.Right. Lorsque vous ajoutez de nouveaux objets Right (droit), vous devez spécifier une logDbKey de deux caractères, qui sera stockée dans la base de données. Vous pouvez rencontrer des cas de figure dans lesquels il n'y a pas de droit correspondant à une action particulière devant être contrôlée. Vous pouvez étendre les actions en les ajoutant à la liste d'objets de l'attribut extendedActions.

Chaque objet extendedActions doit comprendre les attributs listés dans le Tableau 10–16.

Toutes les clés spécifiques au client doivent commencer par le symbole # pour empêcher tout doublon en cas d'ajout de nouvelles clés internes.

Le Tableau 10–16 illustre l'ajout d'une action pour Fermer la session.

Exemple 10–7 Ajout d'une action pour Fermer la session

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

L'attribut extendedResults

En plus d'étendre les types et les actions d'audit, vous pouvez ajouter des résultats. Par défaut, il y a deux résultats : Réussite et Échec. Vous pouvez étendre les résultats en en ajoutant à la liste d'objets de l'attribut extendedResults.

Chaque objet extendedResults doit comprendre les attributs listés dans le Tableau 10–17.

Toutes les clés spécifiques au client doivent commencer par la plage 0–9 pour empêcher tout doublon en cas d'ajout de nouvelles clés internes.

L'attribut publishers

Tous les éléments de la liste publishers sont des objets génériques. Chaque objet publishers a les attributs suivants.

Schéma de la base de données

Deux tables du référentiel d'Identity Manager sont utilisées pour stocker les données d'audit :

• waveset.log stocke les détails des événements ;

• waveset.logattr stocke les ID des organisations auxquelles appartiennent les différents événements.

Ces tables sont examinées au début de cette section.

Lorsque les données du journal d'audit dépassent les limites de longueur de colonne spécifiées pour les tables ci-dessus, Identity Manager tronque les données pour respecter ces limites. La troncature du journal d'audit fait l'objet de la section Troncation du journal d'audit.

Certaines colonnes du journal d'audit ont des limites de longueur configurables. Pour savoir quelles sont ces colonnes et apprendre à en changer la longueur limite, voir Configuration du journal d'audit.

Table waveset.log

Cette section décrit les différents noms de colonnes et types de données figurant dans la table waveset.log. Les types de données sont issus de la définition de la base de données Oracle et varient légèrement d'une base de données à l'autre. Pour la liste des valeurs de schéma pour toutes les bases de données prises en charge, voir l'Annexe BSchéma de la base de données du journal d'audit

Quelques-unes des valeurs des colonnes sont stockées sous forme de clés dans la base de données pour optimiser l'espace. Pour la définition des clés, voir la section intitulée Mappages de la base de données du journal d'audit.

• objectType CHAR(2) : clé de deux caractères représentant le type d'objets qui est contrôlé.

• action CHAR(2) : clé de deux caractères représentant l'action qui a été effectuée.

• actionStatus CHAR(1) : clé de un caractère représentant le résultat de l'action qui a été effectuée.

• reason CHAR(2) : clé de deux caractères décrivant l'objet ReasonDenied en cas d'échec. ReasonDenied est une classe qui enveloppe une entrée du catalogue de messages et est utilisée pour les échecs courants tels que des informations d'authentification non valables et des privilèges insuffisants.

• actionDateTimeVARCHAR(21) : date et heure auxquelles l'action ci-dessus a eu lieu. La valeur est stockée en heure GMT.

• objectName VARCHAR(128) : nom de l'objet qui fait l'objet d'une action pendant une opération.

• resourceName VARCHAR(128) : nom de la ressource qui a été utilisée pendant une opération, le cas échéant. Certains événements ne référencient pas les ressources ; cependant, dans de nombreux cas, cet élément donne davantage de détails pour consigner la ressource où une opération a été effectuée.

• accountName VARCHAR(255) : ID du compte objet de l'action en cours, le cas échéant.

• server VARCHAR(128) : serveur sur lequel l'action a été effectuée (automatiquement assigné par le journal d'événements).

• message VARCHAR(255*)ou CLOB : tout message localisé associé à une action incluant des éléments tels que des messages d'erreur. Le texte est stocké localisé et ne sera donc pas internationalisé. La limite de longueur de cette colonne est configurable. Le type de données par défaut est VARCHAR et la limite de taille par défaut est 255. Pour plus d'informations sur le réglage de la taille limite, voir Configuration du journal d'audit.

• interface VARCHAR(50) : interface d'Identity Manager (par exemple l'interface administrateur, utilisateur, IVR ou SOAP) depuis laquelle l'opération a été effectuée.

• acctAttrChanges VARCHAR(4000) à CLOB : stocke les attributs de compte qui ont changé au cours d'une création et d'une mise à jour. Le champ des changements d'attributs est toujours rempli lors d'une création ou d'une mise à jour pour un objet compte de ressource ou compte Identity Manager. Tous les attributs modifiés pendant une action sont stockés dans ce champ sous la forme d'une chaîne. Les données adoptent le format NAME=VALUE NAME2=VALUE2. Ce champ peut être interrogé en exécutant des instructions SQL « contains » (contient) portant sur le nom ou la valeur.

  L'exemple de code suivant illustre une valeur dans la colonne 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"

  ---

  Remarque –

  Si votre installation d'Identity Manager utilise un référentiel Oracle et que vous remarquez des erreurs de troncature dans le journal d'audit, vous pouvez convertir le champ accountAttrChanges de la table du journal d'audit de VARCHAR(4000) à CLOB. Identity Manager fournit un exemple de script DDL, dans le répertoire /web/sample , qui convertit log.acctAttrChanges de VARCHAR(4000) en CLOB. Le script convert_log_acctAttrChangesCHAR2CLOB.oracle.sql préserve les données existantes et autorise plus de 4000 caractères dans le champ accountAttrChanges.

  Cette conversion est optionnelle et ne doit être effectuée que si vous remarquez des erreurs de troncature. Veillez par ailleurs à sauvegarder les tables concernées avant de lancer le script de conversion.

  Après avoir exécuté le script de conversion, arrêtez et redémarrez votre serveur d'application Web. Tout nouveau rapport exécuté devrait s'afficher correctement.

  ---

• acctAttr01label-acctAttr05label VARCHAR(50) : ces cinq emplacements NAME supplémentaires sont des colonnes pouvant promouvoir jusqu'à cinq noms d'attributs stockés chacun dans une colonne propre au lieu de l'être dans le grand blob. Vous pouvez promouvoir un attribut depuis la page Resource Schema Configuration (Configuration du schéma des ressources) en utilisant le réglage « Vérification informatique ? » : l'attribut sera alors disponible pour l'exploration de données.

• acctAttr01value-acctAttr05value VARCHAR(128) : ces cinq emplacements VALUE supplémentaires peuvent promouvoir jusqu'à cinq valeurs d'attributs stockées chacune dans une colonne propre au lieu de l'être dans le grand blob.

• parm01label-parm05label VARCHAR(50) : cinq emplacements utilisés pour stocker des paramètres associés à un événement. Des exemples de ces paramètres sont les noms IP du client et ID de la session.

• parm01value-parm05value VARCHAR(128*) ou CLOB : cinq emplacements utilisés pour stocker les paramètres associés à un événement. Par exemple, les valeurs d'IP du client et ID de la session. La limite de longueur de ces colonnes est configurable. Le type de données par défaut est VARCHAR et la limite de taille par défaut est 128. Pour plus d'informations sur le réglage de la taille limite, voir Configuration du journal d'audit.

• id VARCHAR(50) : ID unique assigné à chaque enregistrement par le référentiel référencé dans la table waveset.logattr.

• name VARCHAR(128) : nom généré assigné à chaque enregistrement.

• xml BLOB : est utilisé en interne par Identity Manager.

La table waveset.logattr

La table waveset.logattr est utilisée pour stocker les ID d'appartenance organisationnelle pour chaque événement, élément utilisé pour établir l'étendue du journal d'audit par organisation.

• id VARCHAR(50) : ID de l'enregistrement waveset.log.

• attrname VARCHAR(50) : actuellement, toujours MEMBEROBJECTGROUPS.

• attrval VARCHAR(255) : ID du groupe MemberObject auquel l'événement appartient.

Troncation du journal d'audit

Lorsqu'une ou plusieurs colonnes de données du journal d'audit dépassent les limites de longueur de colonne spécifiées, les données de la ou des colonnes concernées sont tronquées. Plus précisément, les données sont tronquées à la limite indiquée moins trois caractères. Une ellipse (...) est ensuite ajoutée aux données de la colonne pour indiquer qu'une troncature a été effectuée.

De plus, la colonne NAME de l'enregistrement d'audit en question est précédée de la chaîne #TRUNCATED# pour faciliter l'interrogation des enregistrements tronqués.

Identity Manager part du principe que le codage UTF–8 est employé lorsqu'il calcule où tronquer les messages. Si votre configuration utilise un codage autre que l'UTF–8, il est possible que les données tronquées dépassent encore la taille de colonne effective dans votre base de données. Si tel est le cas, le message tronqué ne s'affiche pas dans le journal d'audit et une erreur est écrite dans le journal système.

Configuration du journal d'audit

Certaines colonnes du journal d'audit peuvent être configurées pour stocker de grandes quantités de données dans le référentiel.

Redimensionnement des limites de longueur des colonnes

Plusieurs colonnes du journal d'audit ont des limites de longueur configurables. Ces colonnes sont les suivantes :

• la colonne message ;

• les colonnes parmNNvalue (où NN = 01, 02, 03, 04 ou 05) ;

• la colonne xml.

Pour la description des colonnes du journal d'audit, voir Schéma de la base de données.

Les limites de longueur des colonnes peuvent être modifiées en éditant l'objet RepositoryConfiguration. Pour les instructions à suivre pour éditer l'objet RepositoryConfiguration, voir Édition des objets Configuration Identity Manager.

• Pour changer la limite de longueur de la colonne message, modifiez la valeur maxLogMessageLength.

• Pour changer la limite de longueur de la colonne parmNNvalue, modifiez la valeur maxLogParmValueLength. La même valeur limite s'applique à l'ensemble des cinq colonnes (il n'est pas possible de définir de valeurs de longueur de colonne individuelles).

• Pour changer la limite de longueur de la colonne xml, modifiez la valeur maxLogXmlLength.

Un redémarrage du serveur est nécessaire pour que les nouvelles valeurs soient appliquées.

Les paramètres de limite de longueur des colonnes figurant dans l'objet RepositoryConfiguration déterminent la quantité maximale de données pouvant être stockée dans une colonne. Si les données à stocker dépassent ces paramètres, Identity Manager tronque les premières. Pour plus d’informations, voir Troncation du journal d'audit.

Si vous augmentez un paramètre de longueur de colonne dans l'objet RepositoryConfiguration, vérifiez également que le paramètre de taille de colonne de votre base de données est supérieur ou égal à la taille configurée dans l'objet RepositoryConfiguration.

Suppression d'enregistrements dans le journal d'audit

Le journal système doit être tronqué régulièrement afin de ne pas trop devenir trop volumineux. Utilisez la Tâche de maintenance AuditLog pour programmer une tâche qui supprime les anciens enregistrements du journal d'audit.

1. Dans l'interface administrateur, cliquez sur Tâches du serveur -> Gérer la planification.

2. Dans la section Tâches disponibles pour planification, cliquez sur Tâche de maintenance AuditLog.

   La page Créer un nouveau programme de tâches Tâche de maintenance AuditLog s'ouvre.

3. Remplissez le formulaire et cliquez sur Enregistrer.

Utilisation d'éditeurs d'audit personnalisés

Identity Manager peut envoyer des événements de contrôle à des éditeurs d'audit personnalisés.

Les éditeurs personnalisés suivants sont fournis :

• Console. Imprime les événements de contrôle sur la sortie ou l'erreur standard.

• Fichier. Écrit les événements de contrôle dans un fichier simple.

• JDBC. Enregistre les événements de contrôle dans un magasin de données JDBC.

• JMS. Enregistre les événements de contrôle dans une file d'attente ou une rubrique JMS.

• JMX. Publie les événements de contrôle de sorte qu'un client JMX (Java Management Extensions) peut contrôler l'activité du journal d'audit d'Identity Manager.

• Scripté. Permet aux scripts personnalisés de stocker les événements de contrôle.

Pour créer votre propre éditeur, voir Développement d'éditeurs d'audit personnalisés.

Cette section se compose des rubriques suivantes :

• Pour activer les éditeurs d'audit personnalisés ;

• Types d'éditeurs Console, Fichier, JDBC et Scripté ;

• Type d'éditeur JMS ;

• Type d'éditeur JMX.

Pour activer les éditeurs d'audit personnalisés

Les éditeurs d'audit personnalisés s'activent depuis la page Configuration d'audit.

1. Dans l'interface administrateur, cliquez sur Tâches du serveur dans le menu principal puis sur Audit dans le menu secondaire.

   La page Configuration d’audit s'ouvre.

2. Sélectionnez l'option Utiliser un éditeur personnalisé au bas de la page.

   Un tableau listant les éditeurs d'audit actuellement configurés s'ouvre.

3. Pour configurer un nouvel éditeur personnalisé, sélectionnez le type éditeur personnalisé dans le menu déroulant Nouvel éditeur.

   Complétez le formulaire Configurer le nouvel éditeur d’audit. Cliquez sur OK.

4. Important ! Cliquez sur Enregistrer pour enregistrer le nouvel éditeur.

Types d'éditeurs Console, Fichier, JDBC et Scripté

Pour activer les éditeurs d'audit Console, Fichier, JDBC ou Scripté, suivez les étapes de la section Pour activer les éditeurs d'audit personnalisés. Sélectionnez le type d'éditeur approprié dans le menu déroulant Nouvel éditeur.

Complétez le formulaire Configurer le nouvel éditeur d’audit. Pour toute question sur le formulaire, consultez les i-Helps et l'aide en ligne.

• L'éditeur d'audit Console imprime les événements de contrôle sur la sortie ou l'erreur standard.

• L'éditeur d'audit Fichier écrit les événements de contrôle dans un fichier simple.

• L'éditeur d'audit JDBC enregistre les événements de contrôle dans un magasin de données JDBC.

• L'éditeur d'audit Scripté autorise les scripts personnalisés écrits en JavaScript ou en BeanShell pour stocker les événements de contrôle.

Type d'éditeur JMS

Les éditeurs personnalisés de journal d'audit JMS permettent de publier des enregistrements d'événements de contrôle dans une file d'attente ou une rubrique JMS (Java Message Service).

Avantages de l'utilisation de JMS

Publier sur JMS augmente la flexibilité en matière de corrélation dans les environnements présentant plusieurs serveurs Identity Manager. De plus, JMS peut être utilisé dans des situations caractérisées par des restrictions concernant d'utilisation de l'éditeur de fichier d'audit Fichier, par exemple dans les environnements Windows où le journal peut ne pas être accessible à un outil de génération de rapports client pendant l'exécution du serveur.

JMS offre plusieurs avantages pour les environnements multiserveurs :

• Le magasin des messages JMS centralise (et simplifie) le stockage des messages et leur récupération.

• L'architecture JMS n'impose pas de restrictions quant au nombre de clients pouvant accéder au service.

• Le protocole JMS est facile à envoyer à travers les pare-feu et autres infrastructures réseau.

Point à point ou publication/inscription ?

Java Message System propose deux modèles pour la messagerie : le modèle point à point ou de mise en attente et le modèle publication/inscription ou à rubriques. Identity Manager prend en charge ces deux modèles.

Dans le modèle point à point, un producteur poste les messages dans une file d'attente donnée et un consommateur lit les messages dans cette file d'attente. Ici, le producteur connaît la destination du message qu'il poste directement dans la file d'attente du consommateur.

Le modèle point à point présente les caractéristiques suivantes :

• Un seul consommateur obtient le message.

• Le producteur n'a pas à être en cours d'exécution au moment où le récepteur consomme le message et le récepteur n'a besoin d'être en cours d'exécution au moment où le message est envoyé.

• Le récepteur accuse réception de tout message traité avec succès.

Le modèle publication/inscription, d'autre part, prend en charge la publication de messages dans une rubrique de messages donnée. Zéro abonnés ou plus peuvent se révéler intéressés par recevoir des messages sur une rubrique de messages donnée. Dans ce modèle, l'éditeur et l'abonné ignorent tout l'un de l'autre. Une bonne métaphore pour ce modèle est le panneau d'affichage anonyme.

Le modèle publication/inscription présente les caractéristiques suivantes :

• Plusieurs consommateurs peuvent recevoir les messages.

• Une dépendance de synchronisation existe entre éditeurs et abonnés. L'éditeur doit créer un abonnement pour que les clients puissent s'abonner. Une fois inscrits, les abonnés doivent rester actifs en permanence pour recevoir les messages à moins d'un abonnement durable n'ait été établi. Dans le cas d'un abonnement durable, les messages publiés alors que l'abonné n'est pas connecté sont distribués de nouveau quand ce dernier se reconnecte.

Pour plus d'informations sur JMS, voir http://www.sun.com/software/products/message_queue/index.xml

Configuration du type d'éditeur JMS

L'éditeur JMS formate les événements de contrôle en messages de texte TextMessages JMS. Ces TextMessages sont ensuite envoyés à une file d'attente ou une rubrique selon la configuration. Les messages de texte peuvent être formatés au format XML ou ULF (Universal Logging Format) selon la configuration.

Pour activer le type d'éditeur JMS, suivez les étapes de la section Pour activer les éditeurs d'audit personnalisés et sélectionnez JMS dans le menu déroulant Nouvel éditeur.

Pour configurer le type d'éditeur JMS, complétez le formulaire Configurer le nouvel éditeur d’audit. Pour toute question sur le formulaire, consultez les i-Helps et l'aide en ligne.

Type d'éditeur JMX

L'éditeur de journal d'audit JMX publie les événements de contrôle de sorte qu'un client JMX (Java Management Extensions) peut contrôler l'activité du journal d'audit d'Identity Manager.

Définition de JMX

Java Management Extensions (JMX) est une technologie Java qui permet la gestion et/ou le contrôle des applications, objets système, périphériques et réseaux orientés services. L'entité gérée/contrôlée est représentée par des objets appelés des MBeans (pour Managed Bean, bean géré).

Implémentation de l'éditeur JMX d'Identity Manager

L'éditeur de journal d'audit JMX d'Identity Manager contrôle le journal d'audit à la recherche d'événements. Lorsqu'un événement est détecté, l'éditeur JMX enveloppe l'enregistrement de l'événement de contrôle avec un MBean et met à jour un historique temporaire (qui est conservé en mémoire). Pour chaque événement, une petite notification séparée est envoyée au client JMX. Si l'événement est digne d'intérêt, le client JMX peut interroger le MBean enveloppant l'événement de contrôle pour obtenir des informations supplémentaires.

Pour toute information sur les enregistrements d'événements de contrôle, voir la javadoc com.waveset.object.AuditEvent. La javadoc est disponible dans le kit REF présenté dans la section Développement d'éditeurs d'audit personnalisés.

Pour récupérer les informations du MBean approprié, un numéro de séquence d'historique est nécessaire. Ce numéro figure dans la notification de l'événement.

Chaque notification d'événement inclut les informations suivantes :

• Type (Type). Chaîne décrivant le type de l'événement. Cette chaîne adopte le format AuditEvent.<ObjectType>.<Action> où ObjectType et Action sont retournés de com.waveset.AuditEvent. Par exemple, si un événement de déverrouillage est envoyé, le type est AuditEvent.LighthouseAccount.Unlock.

• SequenceNumber (Numéro de séquence). Clé du tampon d'historique utilisée pour demander des informations au MBean.

Pour configurer le type d'éditeur JMX

1. Pour activer le type d'éditeur JMX, suivez les étapes de la section Pour activer les éditeurs d'audit personnalisés et sélectionnez JMX dans le menu déroulant Nouvel éditeur.

2. Pour configurer le type d'éditeur JMX, complétez le formulaire Configurer le nouvel éditeur d’audit. Pour toute question sur le formulaire, consultez les i-Helps et l'aide en ligne.

   • Nom de l’éditeur. Saisissez un nom unique pour l'éditeur d'événements de contrôle JMX.

   • Limite de l’historique. Changez la valeur par défaut comme requis pour spécifier le nombre d'éléments événement que l'éditeur doit conserver en mémoire (la valeur par défaut est 100).

3. Cliquez sur Essai pour vérifier que le Nom de l’éditeur est acceptable.

4. Cliquez sur OK. Le formulaire Configurer le nouvel éditeur d’audit se ferme.

5. Important ! Cliquez sur Enregistrer.

Affichage des événements de contrôle avec un client JMX

Utilisez un client JMX pour afficher l'éditeur JMX. JConsole, qui est inclus dans le JDK 1.5, a été utilisé pour créer les captures d'écran suivantes.

Si vous utilisez JConsole, choisissez attach to process (joindre au processus) pour afficher le MBean IDM:type=AuditLog. Pour toute information sur la configuration de JConsole en vue de l'utiliser en tant que client JMX, voir Viewing JMX Data du Sun Identity Manager 8.1 System Administrator’s Guide.

Dans JConsole, cliquez sur l'onglet Notifications pour afficher les événements de contrôle. Notez le numéro de séquence figurant dans la notification. Un numéro de séquence est requis pour interroger le MBean afin d'obtenir des informations supplémentaires.

Figure 10–1 Affichage des notifications d'événement de contrôle de JMX dans JConsole

Interrogation du MBean afin d'obtenir des informations supplémentaires

Dans JConsole, cliquez sur l'onglet Operations (Opérations). Utilisez le numéro de séquence figurant dans la notification pour interroger le MBean afin d'obtenir les détails de l'événement. Toutes les opérations présentent le préfixe « get » et le seul paramètre est le numéro « sequence ».

Figure 10–2 Interrogation du MBean afin d'obtenir des informations supplémentaires dans JConsole

Le MBean est pratiquement un mappage biunivoque vers la classe com.waveset.object.AuditEvent . Le Tableau 10–19 contient la description des différentes paires attribut/opération fournies par MBean.

Dans JConsole, cliquez sur l'onglet Attributes (Attributs). Les attributs comportent le préfixe Current indiquant qu'ils contiennent le dernier événement de contrôle en date envoyé par le système.

Figure 10–3 Affichage des attributs de Mbeans dans JConsole

Développement d'éditeurs d'audit personnalisés

Cette section explique la création d'un nouvel éditeur d'audit personnalisé en Java.

Les éditeurs personnalisés de type Console, Fichier ou JDBC fournis avec Identity Manager implémentent l'interface AuditLogPublisher. Le code source de ces éditeurs figure dans le kit REF. La documentation des interfaces est également disponible dans le kit REF, au format javadoc (voir la javadoc pour les détails de l'interface).

Le kit REF (Resource Extension Facility) figure dans le répertoire /REF du CD de votre produit ou a été fourni avec votre image d'installation.

Les développeurs sont encouragés à étendre la classe AbstractAuditLogPublisher. Cette classe analyse la configuration et contrôle que toutes les options obligatoires ont été fournies à l'éditeur (voir les exemples d'éditeurs du kit REF).

Les éditeurs doivent avoir un constructeur no-arg.

Cycle de vie des éditeurs

Les étapes suivantes illustrent le cycle de vie d'un éditeur.

1. L'objet est généré.

2. Le programme de formatage (le cas échéant) est défini en utilisant la méthode setFormatter().

3. Les options sont fournies en utilisant la méthode configure(Mappe).

4. Les événements sont publiés en utilisant la méthode publish(Mappe, GestionnaireErreursJournalisation).

5. L'éditeur est terminé en utilisant la méthode shutdown().

Les étapes 1 à 3 sont exécutées lorsqu'Identity Manager démarre et à chaque fois que la configuration d'audit est mise à jour. L'étape 4 n'a pas lieu si aucun événement de contrôle n'est généré avant l'appel de shutdown.

configure(Mappe ) n'est appelé qu'une fois sur le même objet d'éditeur (un éditeur n'a aucune préparation à effectuer pour les changements de configuration à la volée). Une fois la configuration d'audit mise à jour, les éditeurs courants sont arrêtés puis les nouveaux éditeurs sont créés.

La méthode configure() mentionnée à l'étape 3 peut émettre une WavesetException. Dans ce cas, l'éditeur sera ignoré et aucun autre appel ne sera effectué à l'adresse de l'éditeur.

Configuration des éditeurs

Les éditeurs peuvent avoir zéro options ou plus. La méthode getConfigurationOptions() retourne la liste des options prises en charge par l'éditeur. Les options sont encapsulées en utilisant la classe PublisherOption (voir la javadoc pour les détails de cette classe). L'afficheur de la configuration d'audit appelle cette méthode quand il compile l'interface de configuration pour l'éditeur.

Identity Manager configure l'éditeur en utilisant la méthode configure( Mappe) au démarrage du serveur et après les changements de configuration d'audit.

Développement de programmes de formatage

Le kit REF comprend le code source des programmes de formatage suivants :

• XmlFormatter. Formate les événements de contrôle sous forme de chaînes XML.

• UlfFormatter. Formate les événements de contrôle conformément au format ULF (Universal Logging Format, Format de journalisation universel). Il s'agit du format utilisé par Sun Application Server.

Les programmes de formatage doivent implémenter l'interface AuditRecordFormatter. De plus, ces programmes doivent avoir un constructeur no-arg. Pour de plus amples détails, consultez la javadoc incluse dans le kit REF.

Enregistrement des éditeurs/programmes de formatage

L'attribut d'audit de l'objet #ID#Configuration:SystemConfiguration liste l'ensemble des éditeurs et programmes de formatage enregistrés. Ces éditeurs et programmes de formatage sont les seuls disponibles dans l'interface utilisateur de configuration d'audit.