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.