XML output elements

Edit online

Table 1 describes the XML output elements that are possible by using the default Verify Identity Access DTD elements. If you create your own DTD, each element must represent the events that you selected and extracted according to your own criteria.

Table 1. Names and descriptions for XML output elements
Output element name Description 
<event>
...
</event>

Auditing event. Each auditing event captures the result of an action. A principal attempts an action on a target object.

The event element can include the following elements:
  • iv-correlation-id
  • date
  • outcome
  • originator
  • accessor
  • target
  • resource_access (for resource access events)
  • authntype (for authentication events)
  • terminationinfo (for authentication terminate events)
  • data

Because Verify Identity Access auditing uses a standard record format, not all elements are relevant to each event that is recorded. Fields that are not relevant for a particular event might contain a default value.

The event element can include the following attribute:
  • rev
Example: 
<event rev="1.2">
  <date>2003-11-14-16:25:08.341+00:00I-----</date>
  <outcome status="0">0</outcome>
  ...
</event>
 
<iv-correlation-id>
...
</iv-correlation-id>
 Correlation identifier. This identifier can be used to correlate events related to a single HTTP request across WebSEAL, the runtime and other junctioned applications. This element is omitted for events that cannot be correlated. 
<date>
...
</date>
Current date and timestamp. The date element has the following format: 
yyyy-mm-dd-hh:mm:ss.xxx-xx:xxI-----
Where:
yyyy-mm-dd
Relates to the year (yyyy), the month (mm), and the day (dd).
hh:mm:ss
Relates to hours (hh), minutes (mm), and seconds (ss).
xxx-xx:xxI
Refers to the time zone.

Example:

<event rev="1.2">
<date>2005-11-14-16:25:08.341+00-----</date>
...
</event>
 
<outcome>
...
</outcome>
Outcome of the event. The outcome element can be one of the following values:
0
Success
1
Failure
2
Pending
3
Unknown
The following information is captured in a common format header of the audit record:
  • The outcome.
  • The action.
  • The credentials for the principal.
  • The target object.
This element can include the following attributes:
  • status
  • reason
Example of a failed event: 
<outcome status="320938184" reason="authenticationFailure">
  1
</outcome>

For information about the contents of the status attribute, use the errtext command. The command provides the error message that is associated with the status code (320938184) of a failed event. If the error is not identified by the errtext command, the error did not originate in Verify Identity Access. See your third-party documentation for more status code definitions.

For information about the contents of the reason attribute, see Outcome output for failures.

Example of a successful event:

<event rev="1.2">
...
<outcome status="0">0</outcome>
...
</event>
 
<originator>
...
</originator>
Server that originated the event being logged. The originator element can include the following elements:
  • component
  • event_id
  • action
  • location
The originator element can include the following attributes:
  • blade
  • instance
The blade attributes represents the server that originated the event. For example, pdmgrd is the Verify Identity Access policy server, webseald is the Verify Identity Access WebSEAL server. The instance attribute applies to WebSEAL and represents the name of the instance.
Example: 
<event rev="1.2">
...
<originator blade="webseald">
   <component rev="1.4">authn</component>
   <event_id>101</event_id>
   <action>0</action>
   <location>cmd.wma.ibm.com</location>
</originator>
...
</event>
 
<component>
...
</component>

Audit events, categorized by the server functionality that generates them. Some functionality is common across Verify Identity Access servers while other functionality is server-specific.

The component element can be one of the following values:
authz or azn
Captures authorization events.
authn
Captures authentication events.
mgmt
Captures management events.
http
Captures WebSEAL HTTP events. See the Configuring topics in the Knowledge Center for more information about this value.

The component element can contain the rev attribute.

Example: 
<originator blade="webseald">
   <component rev="1.4">authn</component>
   <event_id>101</event_id>
   <action>0</action>
   <location>cmd.wma.ibm.com</location>
</originator>
 
<event_id>
...
</event_id>
The category of the event ID. The event_id element can be one of the following values:
101
Login
102
Password change
103
Logout
104
Authenticate
105
Step-up
106
Re-authentication
107
Credentials refresh
108
Authorization check
109
Resource access
110
Get credentials
111
Modify credentials/combine credentials
112
Get credentials from pac
113
Get pac
114
Get entitlements
115
Runtime start
116
Runtime stop
117
Runtime audit start
118
Runtime audit stop
119
Runtime audit level change
120
Runtime statistic
121
Runtime heartbeat up
122
Runtime heartbeat down
123
Runtime lost contact
124
Runtime contact restored
125
Runtime monitor
126
Switch-user login
127
Switch-user logout
128
A certificate with unknown OCSP revocation status was rejected
129
A certificate with unknown OCSP status was permitted
Example: 
<originator blade="webseald">
   <component rev="1.4">authn</component>
   <event_id>101</event_id>
   <action>0</action>
   <location>cmd.wma.ibm.com</location>
</originator>
 
<action>
...
</action>
Audit record action code, which can be for one of the following groups of events:
Authentication or authorization events
Audit records for authentication or authorization events contain one of the following event action codes:
0
Authentication or authorization events
1
Change password events
2
WebSEAL events
Management events
Audit records for management events contain an action code that identifies the pdadmin utility. For example, the <action>13702</action> action code relates to the POP_MODIFY action for the pop modify command. See Action codes for management commands, which relates the action code reference number for each command.
A common format header of the audit record captures information about:
  • The action.
  • The credentials of the principal.
  • The target object.
  • The outcome.
Example: 
<originator blade="webseald">
   <component rev="1.4">authn</component>
   <event_id>101</event_id>
   <action>0</action>
   <location>cmd.wma.ibm.com</location>
</originator>
 
<location>
...
</location>

The host name (location) of the machine. If there is no host name specified, a notation of location not specified is substituted in the location element.

Example: 
<originator blade="webseald">
   <component rev="1.4">authn</component>
   <event_id>101</event_id>
   <action>0</action>
   <location>cmd.wma.ibm.com</location>
</originator>
 
<accessor>
...
</accessor>

The name of the user that caused the event. If there is no user name specified, a notation of name="user not specified" or name="" is substituted in the accessor element.

The accessor element can include the following elements:
  • principal
  • name_in_rgy (for authenticated users)
  • session_id (for authenticated users)
  • principal
  • user_location
  • user_location_type

The accessor element includes the name attribute.

The following example shown the accessor element for an unauthenticated user: 
<event rev="1.2>
  ...
  <accessor name="unauthenticated">
    <principal auth="IV_UNAUTH_V3.0" domain="Default">
      testuser2
    </principal>
    <user_location>9.65.85.162</user_location>
    <user_location_type>IPV4</user_location_type>
  </accessor>
  ...
</event>
The following example shown the accessor element for an authenticated user: 
<event rev="1.2>
  ...
  <accessor name="">
    <principal auth="IV_LDAP_V3.0" domain="Default">
      testuser2
    </principal>
    <name_in_rgy>
      cn=testuser1,dc=ibm,dc=com
    </name_in_rgy>
    <session_id>
      e005ba3-34ed-11da-a016-00096bc369d
    </session_id>
    <user_location>9.65.85.162</user_location>
    <user_location_type>IPV4</user_location_type>
  </accessor>
  ...
</event>
 
<principal>
...
</principal>

User authorization credentials. Generally each event captures the result of an action that a user (principal) attempts on a target object. If there is no user name specified, a notation of auth="invalid" is substituted in the principal element.

The principal element can contain the following attributes:
  • auth
  • domain
To determine the actual authentication method, use the data in the authntype element.
A common format header of the audit record captures information about:
  • The credentials of the principal.
  • The action.
  • The target object.
  • The outcome.
Example: 
<accessor name="">
  <principal auth="IV_LDAP_V3.0" domain="Default">
    testuser2
  </principal>
  <name_in_rgy>
    cn=testuser1,dc=ibm,dc=com
  </name_in_rgy>
  <session_id>
    e005ba3-34ed-11da-a016-00096bc369d
  </session_id>
  <user_location>9.65.85.162</user_location>
  <user_location_type>IPV4</user_location_type>
  </accessor>
 
<name_in_rgy>
...
</name_in_rgy>

The name in the registry for the user.

Example: 
<accessor name="">
  <principal auth="IV_LDAP_V3.0" domain="Default">
    testuser2
  </principal>
  <name_in_rgy>
    cn=testuser1,dc=ibm,dc=com
  </name_in_rgy>
  <session_id>
    e005ba3-34ed-11da-a016-00096bc369d
  </session_id>
  <user_location>9.65.85.162</user_location>
  <user_location_type>IPV4</user_location_type>
</accessor>
 
<session_id>
...
</session_id>

The session ID that is associated with this session. This ID can be used to trace a series of events back to the authentication data that was initially provided by the user. For example, the data in the session_id element could be used to determine when a user logged in and when a user logged out.

Example: 
<accessor name="">
  <principal auth="IV_LDAP_V3.0" domain="Default">
    testuser2
  </principal>
  <name_in_rgy>
    cn=testuser1,dc=ibm,dc=com
  </name_in_rgy>
  <session_id>
    e005ba3-34ed-11da-a016-00096bc369d
  </session_id>
  <user_location>9.65.85.162</user_location>
  <user_location_type>IPV4</user_location_type>
</accessor>
 
<user_location>
...
</user_location>

The IP address in IPv4 or IPv6 format.

Example: 
<accessor name="">
  <principal auth="IV_LDAP_V3.0" domain="Default">
    testuser2
  </principal>
  <name_in_rgy>
    cn=testuser1,dc=ibm,dc=com
  </name_in_rgy>
  <session_id>
    e005ba3-34ed-11da-a016-00096bc369d
  </session_id>
  <user_location>9.65.85.162</user_location>
  <user_location_type>IPV4</user_location_type>
</accessor>
 
<user_location_type>
...
</user_location_type>
The format of the data in the user_location element. Values are:
  • IPV4
  • IPV6
Example: 
<accessor name="">
  <principal auth="IV_LDAP_V3.0" domain="Default">
    testuser2
  </principal>
  <name_in_rgy>
    cn=testuser1,dc=ibm,dc=com
  </name_in_rgy>
  <session_id>
    e005ba3-34ed-11da-a016-00096bc369d
  </session_id>
  <user_location>9.65.85.162</user_location>
  <user_location_type>IPV4</user_location_type>
</accessor>
 
<target>
...
</target>
Target information. The target element can include the following elements:
  • object
  • object_nameinapp
  • process
  • azn
  • url
The target element includes the resource attribute, which represents a broad categorization of the target object: The resource attribute can be one of the following values:
0
AUTHORIZATION
1
PROCESS
2
TCB
3
CREDENTIAL
5
GENERAL
6
APPLICATION
7
AUTHENTICATION
Examples: 
<target resource="7">
  <object></object>
</target>
<target resource="3">
  <object>IV_LDAP_V3.0:sec_master</object>
</target>
 
<object>
...
</object>
Target object. Authorization audit records can be captured when a target object in the policy database (protected object space) has a POP attached to it. The POP must enable audit functionality. For example: 
<object>/Management</object>
A common format header of the audit record captures information about:
  • The target object.
  • The action.
  • The user credentials.
  • The outcome.
Example: 
<target resource="3">
  <object>IV_LDAP_V3.0:sec_master</object>
</target>
 
<url>
…
</url>
 The URL which was accessed to cause the authentication event.
Example: 
<target resource="3">
  <url>https://www.ibm.com/security-verify-access</url>
</target>
 
<azn>
...
</azn>
Authorization service information. The authorization service:
  • Checks the access permissions on the target requested object.
  • Compares these access permissions with the capabilities of the requesting user.
The azn element can include the following elements:
  • perm
  • result
  • qualifier
<target resource="3">
  ...
  <azn>
    <perm>64</perm> 
    <result>0</result>
    <qualifier>0</qualifier>
  </azn>
  ...
</target>
 
<perm>
...
</perm>

Set of controls (permissions) that specifies the conditions necessary to complete certain operations on that resource. The permission can be specified in this element by using either the binary number such as <perm>64</perm> or the letters for the specified action permissions such as <perm>Tr</perm>.

Example: 
<target resource="3">
  ...
  <azn> 
    <perm>64</perm>
    <result>0</result>
    <qualifier>0</qualifier>
  </azn>
  ...
</target>
 
<result>
...
</result>

Results of the authorization service check.

Example: 
<target resource="3">
  ...
  <azn> 
    <perm>64</perm> 
    <result>0</result>
    <qualifier>0</qualifier>
  </azn>
  ...
</target>
 
<qualifier>
...
</qualifier>

Qualifier information.

Example: 
<target resource="3">
  ...
  <azn> 
    <perm>64</perm> 
    <result>0</result>
    <qualifier>0</qualifier>
  </azn>
  ...
</target>
 
<process>
...
</process>
Type of process. The process element can include the following elements:
  • pid (process ID)
  • uid (user ID)
  • eid (effective user ID)
  • gid (group ID)
  • egid (effective group ID)
The process element includes the architecture attribute, which is one of the following values:
0
For AIX, Linux, and Solaris operating systems.
1
For Windows operating systems.
Example: 
<process architecture="0">
  ...
  <pid></pid>
</process>
 
<pid></pid>
<eid></eid>
<uid></uid>
<gid></gid>
<egid></egid>
The identifier of the process, which is contained in one of the following elements:
pid
Process ID
eid
Effective user ID
uid
User ID
gid
Group ID
egid
Effective group ID
Example: 
<process architecture="0">
  ...
  <pid>3899</pid>
</process>
 
<policy>
...
</policy>
The security policy information. The policy element can include the following elements:
  • name
  • type
  • descr
Example of name element for policy element: 
<policy>
  <name>real-traders-only</name>
  <type>rule</type>
</policy>
 
<name>
...
</name>

Name of the policy attribute that you want to audit. The name matches the name that you specified in a list of attributes in the [aznapi-configuration] stanza of the appropriate configuration file. For example:

[aznapi-configuration] 
audit-attribute = real-traders-only
Example: 
<policy>
  <name>real-traders-only</name>
  <type>rule</type>
</policy>
 
<type>
...
</type>
Type of security policy being audited. The type element can contain the following values:
  • ACL
  • POP
  • rule
Example: 
<policy>
  <name>traders-pop</name>
  <type>POP</type>
</policy>
 
<descr>
...
</descr>

Description of the security policy. This element is empty if no description was created for the policy.

Example: 
<policy><name>traders-acl</name> 
  <type>ACL</type>
  <descr>traders that have ACL security policies</descr>
</policy>
 
<attribute>
...
</attribute>

The container for the characteristics of the access decision information (ADI) attribute to audit. An attribute can establish accountability by providing information to help identify potentially inappropriate access of assets. You can grant or deny access based on rules applied to attributes.

The attribute element can include the following elements:
  • name
  • source
  • type
  • value
Example: 
<attribute>
  <name>tagvalue_su-admin</name> 
  <source>cred</source> 
  <type>string</type>
  <value>test_customer_service_rep_1</value> 
</attribute>
 
<name>
...
</name>

Name of the ADI to audit. This ADI can be for auditing either a user credential if for the authn component or an app_context if for an azn component.

The name of the authorization attribute matches the name that you specified in a list of attributes in the [aznapi-configuration] stanza of the appropriate configuration file. For example: 
[aznapi-configuration] 
audit-attribute = AZN_CRED_AUTH_METHOD
Example of name element for the attribute element: 
<attribute>
  <name>AZN_CRED_AUTH_METHOD</name>
  <source>credADI</source>
  <type>string</type> 
  <value>su-forms</value>
</attribute>
 
<source>
...
</source>
The source event. The source element can contain one of the following values:
cred
Applies to any Verify Identity Access component.
app
Applies only to an authorization (azn) component.
credADI
Applies only to the authorization (azn) component when evaluating a Boolean rule.
appADI
Applies only to the authorization (azn) component when evaluating a Boolean rule.
engineADI
Applies only to the authorization (azn) component when evaluating a Boolean rule.
dynADI
Applies only to the authorization (azn) component when evaluating a Boolean rule.

If the ADI attribute is multi-valued, a separate attribute element is written for each value.

Example: 
<attribute> 
  <name>AZN_CRED_AUTH_METHOD</name> 
  <source>credADI</source>
  <type>string</type> 
  <value>su-forms</value>
</attribute>
 
<type>
...
</type>
Type of security policy that is being audited. The type element can contain one of the following values:
  • string
  • ulong
  • pobj

If <type>pobj</type>, the value is the name of the protected object.

Example: 
<attribute>
  <name>AZN_CRED_AUTH_METHOD</name>
  <source>credADI</source>
  <type>string</type>
  <value>su-forms</value>
</attribute>
 
<value>
...
</value>

Value for the aznAPI attribute. If the ADI attribute is multi-valued, then a separate attribute element is written for each value.

Example: 
<attribute>
  <name>AZN_CRED_AUTH_METHOD</name>
  <source>credADI</source>
  <type>string</type>
  <value>su-forms</value>
</attribute>
 
<resource_access>
...
</resource_access>
Example: 
<event rev="1.2">
  ...
  <resource_access>
    <action>httpRequest</action>
    <httpurl>HTTP://cmd.wma.ibm.com:80/</httpurl>
    <httpmethod>GET</httpmethod>
    <httpresponse>200</httpresponse>
  </resource_access>
  ...
</event>
 
<action>
...
</action>
Example: 
<event rev="1.2">
  ...
  <resource_access>
    <action>httpRequest</action>
    <httpurl>HTTP://cmd.wma.ibm.com:80/</httpurl>
    <httpmethod>GET</httpmethod>
    <httpresponse>200</httpresponse>
  </resource_access>  ...
</event>
 
<httpurl>
...
</httpurl>
Example: 
<event rev="1.2">
  ...
  <resource_access>
    <action>httpRequest</action>
    <httpurl>HTTP://cmd.wma.ibm.com:80/</httpurl>
    <httpmethod>GET</httpmethod>
    <httpresponse>200</httpresponse>
  </resource_access>  ...
</event>
 
<httpmethod>
...
</httpmethod>
Example: 
<event rev="1.2">
  ...
  <resource_access>
    <action>httpRequest</action>
    <httpurl>HTTP://cmd.wma.ibm.com:80/</httpurl>
    <httpmethod>GET</httpmethod>
    <httpresponse>200</httpresponse>
  </resource_access>  ...
</event>
 
<httpresponse>
...
</httpresponse>
Example: 
<event rev="1.2">
  ...
  <resource_access>
    <action>httpRequest</action>
    <httpurl>HTTP://cmd.wma.ibm.com:80/</httpurl>
    <httpmethod>GET</httpmethod>
    <httpresponse>200</httpresponse>
  </resource_access>  ...
</event>
 
<authntype>
...
</authntype>

The type of authentication that the user completed. The following strings are authentication types that are associated with WebSEAL and Plug-in for Web Servers:

itamFailoverCookie
Failover cookie
itamCDSSO
WebSEAL or Plug-in for Web Servers authentication using cross domain single-sign on (CDSSO)
itamECSSO
WebSEAL or Plug-in for Web Servers authentication using e-Community single-sign on (ECSSO)
certificate
SSL certificate authentication
twoFactor
WebSEAL or Plug-in for Web Servers using token authentication
formsPassword
Password authentication using an HTML form
basicAuthRFC2617
Password authentication using HTTP Basic Authentication (BA)
passwordOther
Password authentication using an undetermined mechanism
itamHTTPHeader
WebSEAL or Plug-in for Web Servers using HTTP header authentication
itamIPAddress
WebSEAL or Plug-in for Web Servers using IP address-based authentication
kerberos
WebSEAL or Plug-in for Web Servers using SPNEGO authentication
itamEAI
WebSEAL or Plug-in for Web Servers using external authentication interface (EAI) authentication
itamIVCreds
Plug-in for Web Servers authentication using the IV_CREDS header
itamIVUser
Plug-in for Web Servers authentication using the IV_USER header
tokenLTPA
Plug-in for Web Servers authentication using a lightweight third-party authentication (LTPA) token
ntlm
Plug-in for Web Servers using NTLM authentication
itamWebServerAuthentication
Plug-in for Web Servers authentication that is provided by the hosting Web server
Example: 
<event rev="1.2">
  ...
  <authntype>formsPassword</authntype>
  ...
</event>
 
<terminateinfo>
...
</terminateinfo>

Contains information about why a session ended. The terminateinfo element contains the terminatereason element.

Example: 
<event rev="1.2">
  ...
  <terminateinfo>
    <terminatereason>userLoggedOut</terminatereason>
  </terminateinfo>
  ...
</event>
 
<terminatereason>
...
</terminatereason>
The reason why the session ended. The following values are possible:
idleTimeout
The session timed out because the user was inactive.
sessionExpired
The session timed out because the user was logged in for too long.
sessionDisplaced
The session ended because another user with the same user ID logged in.
sessionTerminatedByAdmin
The session ended because an administrator logged out the user.
userLoggedOut
The session ended because the user logged out.
reathLockOut
The session ended because the user did not authenticate again.
Example: 
<terminateinfo>
  <terminatereason>userLoggedOut</terminatereason>
</terminateinfo>
 
<data>
...
</data>

Event-specific data. The data element can contain the audit element.

Additional event-specific information is recorded in a free format data area at the end of the event record. For failed authentication attempts, Data output for errors provides details about the data information that is returned.

Note: Decoding the meaning of certain data values in the record might require an advanced knowledge of the Verify Identity Access code and architecture.
Command arguments are listed in the data element of the event record in their internal format. For example: 
<data>azn_id_get_creds</data>

Commands that do not result in an effective state change (list and show) are never captured.

Examples: 
  • <event>
  ...
  <data>
  POST /pkmspasswd.form HTTP/1.1 0 Mozilla/4.0 
  (compatible; MSIE 6.0; Windows NT 5.0)
  https://c03comcrit2.somecompany.com/pkmspasswd
  </data>
</event>
  • <data>
  "2019"
  "1002"
  "pop1"
  "0"
  ""
</data>
 
<audit/>
Beginning and ending of an audit event. The audit element can include the event attribute, which can be one of the following values:
  • Start
  • Stop
Example: 
<event rev="1.2">
  ...
  <data>
    <audit event="Start"/>
  </data>
</event>
...
<event rev="1.2">
  ...
  <data>
    <audit event="Stop"/>
  </data>
</event>