|
| |
| Sun Java[tm] System Identity Manager 6.0 Audit Logging 2005Q4M3 | |
1
Identity Manager Auditing
This chapter describes how the Sun Java™ System Identity Manager auditing system records events. The information is organized as follows:
OverviewThe purpose of Identity Manager auditing is to record who did what, when, and to which Identity Manager objects. The interface has three main components:
- Logger – Events move from the logger to the handler.
- Handler – Calls the filter to prevent unwanted events from being written to the audit log.
- Filter – If the event passes the filter class, the handler then logs the record to the database using the repository interface.
Note For detailed information about using the auditing system user interface, see Sun Java™ System Identity Manager Administration.
What Does Identity Manager Audit?Most default auditing is carried out by internal Identity Manager components. However, there are interfaces that allow events to be generated from workflow or from Java code.
The default Identity Manager audit instrumentation focuses on four main areas:
- Provisioner – An internal component known as the provisioner may generate audit events.
- View Handlers – In the view architecture, the view handler needs to generate audit records. A view handler should always audit when objects are created or modified.
- Session – The session methods (such as checkinObject, createObject, runTask, login, and logout) create an audit record after completing an auditable operation. Most of the instrumentation is pushed into the view handlers.
- Workflow – By default, only the approval workflows are instrumented to generate audit records. These generate an audit event when requests are approved or rejected. The workflow feature’s interface to the audit logger is through the com.waveset.session.WorkflowServices application.
Creating EventsAlthough Identity Manager handles internal auditing, in some cases you may want to log audit events from custom workflows.
Auditing from Workflow
Use the com.waveset.session.WorkflowServices application to generate audit events from any workflow process. The following table describes the arguments available for this application.
Note Refer to the Object Types, Actions, and Results table on page 1-15 for default object, action, and status names.
Examples
The following example illustrates a simple workflow activity. It shows the generation of an event that will log a resource deletion activity named ADSIResource1, performed by ResourceAdministrator:
<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>
The next example shows how you can add specific attributes to a workflow that tracks the changes applied by each user in an approval process to a granular level. This addition typically will follow a ManualAction that solicits input from a user.
ACTUAL_APPROVER is set in the form and in the workflow (if approving from the approvals table) based on the person who actually performed the approval. APPROVER identifies the person to whom it was assigned.
<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>
Audit ConfigurationThe Audit Configuration (#ID#Configuration:AuditConfiguration) object is defined in the sample/auditconfig.xml file. This configuration object has an extension that is a generic object. At the top level, it has four attributes that are also generic objects:
filterConfiguration
The filterConfiguration attribute lists event groups, which are used to enable one or more events to pass through the event filter. Each group listed in the filterConfiguration attribute has the attributes listed in the following table:
The following example shows the default resource management group:
<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>There are eight default event groups:
You can configure each group from the Audit Events page of the Identity Manager administrative interface (configure/auditeventconfig.jsp). The page allows you to configure successful or failed events for each group. The interface does not support adding or modifying enabledEvents for groups, but you can do this by using the Identity Manager debug pages.
The following sections list the default event groups and the events they enable.
Account Management
This group is enabled by default.
Type
Actions
Resource Account
Create, Update, Delete, Enable, Disable, Reject, Approve, Rename
Identity Manager Account
Create, Update, Delete, Enable, Disable, Rename
Configuration Management
This group is enabled by default.
Type
Actions
Configuration
All Actions
UserForm
All Actions
Rule
All Actions
EmailTemplate
All Actions
LoginConfig
All Actions
Policy
All Actions
XMLData
Import
Log
All Actions
Identity Manager Login/Logoff
This group is enabled by default.
Type
Actions
User
Login, Logoff, Credentials Expired
Administrator
Login, Logoff, Credentials Expired
Password Management
This group is enabled by default.
Resource Management
This group is enabled by default.
Type
Actions
Resource
All Actions
Resource Object
All Actions
ResourceForm
All Actions
ResourceAction
All Actions
AttrParse
All Actions
Role Management
This group is disabled by default.
Security Management
This group is enabled by default.
Type
Actions
ObjectGroup
All Actions
AdminGroup
All Actions
Administrator
All Actions
EncryptionKey
All Actions
Task Management
This group is disabled by default.
Type
Actions
TaskInstance
All Actions
TaskDefinition
All Actions
TaskSchedule
All Actions
TaskResult
All Actions
ProvisioningTask
All Actions
Changes Outside Identity Manager
This group is disabled by default.
extendedTypes
Each new Type that you add to the com.waveset.object.Type class can be audited. A new Type must be assigned a unique two-character database key, which is stored in the database. All new Types are added to the various audit reporting interfaces. Each new Type to be logged to the database without being filtered must be added to an audit event groups enabledEvents attribute (as described with the enabledEvents attribute).
There may be situations in which you want to audit something that does not have an associated com.waveset.objectType, or where you want to represent an existing type more granularly.
For example, the WSUser object stores all of the user's account information in the repository. Instead of marking each event as a USER type, the auditing process splits the WSUser object into two different audit types (Resource Account and Identity Manager Account). Splitting the object in this way makes it easier to find specific account information in the audit log.
Add extended audit types by adding to the extendedObjects attribute. Each extended object must have the following attributes:
Argument
Type
Description
name
String
The name of the type, which is used when constructing AuditEvents and during event filtering.
displayName
String
A message catalog key that represents the name of the type.
logDbKey
String
Two-character database key to use when storing this object in the Log table. See Log Database Keys for reserved values.
supportedActions
List
Actions supported by the object type. This attribute will be used when creating audit queries from the user interface. If this value is null, all actions will be displayed as possible values to be queried for this object type.
mapsToType
String
(Optional) The name of the com.waveset.object.Type that maps to this type, if applicable. This attribute is used when attempting to resolve an object organizational membership if not already specified on the event.
organizationalMembership
List
(Optional) A default list of organization IDs where events of this type should be placed, if they do not already have assigned organizational membership.
Note All customer-specific keys should start with the # symbol to prevent duplicate keys when new internal keys are added.
The following example shows the extended type Identity Manager Account.
<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>extendedActions
Audit actions typically map to com.waveset.security.Right objects. When adding new Right objects, you must specify a unique two-character logDbKey, which will be stored in the database. You may encounter situations where there is no right to correspond to a particular action that must be audited. You can extend actions by adding them to the list of objects in the extendedActions attribute.
Each object must include the following attributes:
Attribute
Type
Description
name
String
The name of the action, which is used when constructing AuditEvents and during event filtering.
displayName
String
A message catalog key that represents the name of the action.
logDbKey
String
Two-character database key to use when storing this action in the Log table.
See Log Database Keys for reserved values.
Note All customer-specific keys should start with the # symbol to prevent duplicate keys when new internal keys are added.
This example shows adding an action for Logout.
<Object name='Logout'>
<Attribute name='displayName' value='LG_LOGOUT'/>
<Attribute name='logDbKey' value='LO'/>
</Object>extendedResults
In addition to extending audit types and actions, you can add results. By default, there are two results: Success and Failure. You can extend results by adding them to the list of objects in the extendedResults attribute.
Each object must include these attributes:
Note All customer-specific keys should use the range 0–9 to prevent duplicate keys when new internal keys are added.
Database SchemaThere are two tables in the Identity Manager database that are used to store audit data:
waveset.log
This section lists the various column names and data types found in the waveset.log table. The data types are taken from the Oracle database definition and will vary slightly from database to database. A few of the column values are stored as keys in the database for space optimization. For key definitions, see the section titled Log Database Keys.
- objectType CHAR(2) – A two-character key that represents the object type that is being audited.
- action CHAR(2) – A two-character key that represents the action that was performed.
- actionStatus CHAR(1) – A one-character key that represents the result of the action that was performed.
- reason CHAR(2) – A two-character database key to describe a ReasonDenied object if there was a failure. ReasonDenied is a class that wraps a message catalog entry and is used for common failures such as invalid credentials and insufficient privileges.
- actionDateTime VARCHAR(21) – The date and time in which the above action took place. This value is stored in GMT time.
- objectName VARCHAR(128) – The name of the object that was acted on during an operation.
- resourceName VARCHAR(128) – The resource name that was used during an operation, if applicable. Some events do not reference resources; however, in many situations it gives greater detail to log the resource where an operation has performed.
- accountName VARCHAR(255) – The account ID being acted on, if applicable.
- server VARCHAR(128) – The server where the action was performed (automatically assigned by the event logger).
- message VARCHAR(255) – Any localized messages associated with an action including things like error messages. The text is stored localized so it will not be internationalized.
- interface VARCHAR(50) – The Identity Manager interface (such as the Administrator, User, IVR, or SOAP interface) from which the operation was performed.
- acctAttrChanges VARCHAR(4000) – Stores the account attributes that have changed during a create and update. The attributes changes field is always populated during a create or update for a resource account or Identity Manager account object. All of the attributes changed during an action are stored in this field as a string. The data is in NAME=VALUE NAME2=VALUE2 format. This field can be queried by executing “contains” SQL statements against the name or value.
The following example shows what a value in the acctAttrChanges column looks like:
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"
- acctAttr01label-acctAttr05label VARCHAR(50) – These five additional NAME slots are columns that can promote up to five attributes to be stored in their own column instead of in the big blob. You can promote an attribute from the Resource Schema Configuration page using the "audit?" setting, and the attribute will be available for data mining.
- acctAttr01value-acctAttr05value VARCHAR(128) – Five additional VALUE slots that can promote up to five attributes to be stored in a separate column instead of in the blob column.
- parm01label-parm05label VARCHAR(50) – Five slots used to store parameters associated with an event. Examples of these are Client IP and Session ID.
- parm01value-parm05value VARCHAR(128) – Five slots used to store parameters associated with an event. Examples of these are Client IP and Session ID.
- id VARCHAR(50) – Unique ID assigned to each record by the repository referenced in the waveset.logattr table.
- name VARCHAR(128) – Generated name assigned to each record.
waveset.logattr
The waveset.logattr table is used to store IDs of the organizational membership for each event, which is used to scope the audit log by organization.
Log Database KeysThe objectType, action, actionStatus, and reason columns are stored in the database as keys to conserve space.
ObjectTypes, Actions, and Results
The following table describes the objectTypes, actions, and results that are stored in the database as keys:
Reasons
The following table describes the reasons that are stored in the database as keys:
Preventing Audit Log TamperingYou can configure Identity Manager to prevent the following forms of audit log tampering:
All Identity Manager audit log records have unique, per-server sequence numbers and encrypted hash of records and sequence numbers. When you create a Tamper Detection Report, it scans the audit logs per server for:
To configure tamper-resistant logging:
- Create a tampering report by selecting Reports > New > Audit Log Tampering Report.
- When the Define a Tampering Report page displays (as shown in the following figure), enter a title for the report and then Save it.
Figure 1. Configuring an Audit Log Tampering Report
Note You can also specify the following optional parameters:
- Report Summary – Enter a descriptive summary of the report.
- Starting sequence for server '<server_name>' – Enter the starting sequence number for the server.
This option enables you to delete old log entries without having them flagged as tampering and limits the report’s scope for performance reasons.
- Email Report – Enable to email report results to a specified email address.
When you select this option, the page refreshes and prompts you for email addresses. However, keep in mind that email is not safe for text content — sensitive information (such as account IDs or account history) may be exposed.
- Override default PDF options – Select to override the default PDF options for this report.
- Organizations – Select organizations that should have access to this report.
- Next, select Configure > Audit Events to open the Audit Events page (shown in the following figure).
Figure 2. Tamper-Resistant Audit Logs
- Select the Enable tamper-resistant audit logs box, and then click Save.
Note You can turn this option off again, but unsigned entries will be flagged as such in the Audit Log Tampering Report, and you must reconfigure the report to ignore these entries.
