| <!-- vim: set syn=markdown : --> |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| #set($h1='#') |
| #set($h2='##') |
| #set($h3='###') |
| #set($h4='####') |
| |
| $h1 The Apache Log4j Audit Catalog |
| |
| Log4j-Audit uses a Catalog that describes the attributes and events that can be logged. The catalog is required |
| to generate the audit events and to validate events being logged. |
| |
| $h2 The Catalog and Catalog Editor |
| |
| Log4j Audit provides an AuditCatalog WAR that can be deployed to a servlet container for use in creating and |
| maintaining the catalog. Because the Catalog Editor requires the credentials to be configured on the machine |
| where the web application is running and it performs no other authentication of the user, it is recommended |
| that the Catalog Editor be run locally on the user's machine. |
| |
| The catalog provides screens to maintain the attributes, events, products, and categories defined in the catalog. |
| Changes made to these entities are stored in an in-memory database until the user elects to persist them, at which |
| time the catalog is exported as JSON and stored into the configured git repository. |
| |
| Because the editor can only edit the default catalog and the persistant storage is the JSON file in the Git |
| repository, the Catalog Editor is configured to only use the in memory database. |
| |
| $h3 Attributes |
| |
| Attributes are the discrete data elements to be captured in audit events. One of the goals of the audit catalog |
| is to avoid having what are essentially the same attributes with different names in various events. When creating |
| new events users are highly encouraged to scan the existing attributes for one that is already present. |
| |
| Attributes can have aliases and examples, however the Catalog Editor provides no way to edit these and Log4j Audit |
| currently doesn't do anything with these fields. |
| |
| The attribute edit screen allows attributes to be defined, modified or deleted. The fields that may be modified are: |
| <table> |
| <tr><th>Field</th><th>Description</th></tr> |
| <tr><td>Name</td><td>The name of the attribute as it will be known to Java. It is expected to be defined in camelCase.</td></tr> |
| <tr><td>Display Name</td><td>The text that should be used to display the field in an application</td></tr> |
| <tr><td>Description</td><td>The description of the attribute as it would appear in help text in a UI.</td></tr> |
| <tr><td>Data Type</td><td>The type of data contained in the field. Must be one of BIG_DECIMAL, BOOLEAN, DOUBLE, FLOAT, INT, LIST, LONG, MAP, STRING</td></tr> |
| <tr><td>Indexed</td><td>True if this field should be indexed when stored in a database.</td></tr> |
| <tr><td>Sortable</td><td>True if this field should be sortable when displayed in a UI.</td></tr> |
| <tr><td>Required</td><td>True if this field is required by default</td></tr> |
| <tr><td>Request Context</td><td>True if this attribute is provided in the RequestContext</td></tr> |
| <tr><td>Constraints</td><td>Rules to use to validate the value. Must be null or one of ANYCASEENUM, ENUM, MAXLENGTH, MAXVALUE, MINLENGTH, MINVALUE, PATTERN</td></tr> |
| </table> |
| |
| $h4 Data Types |
| |
| An attribute must be defined as being one of the supported data types. Log4j Audit will use this information when generating the |
| event Interfaces. By doing so, the data being logged will be guaranteed to be of the correct type at compile time. When |
| logging using the Audit Service the data will be validated for the correct type when the event is received. |
| |
| $h4 Constraints |
| |
| If a constraint is present on an attribute definition Log4j Audit will validate the value when the event is logged. The enum types must provide |
| a list of valid values. The min and max constraints must be configured with an appropriate value. The pattern constraints must be configured |
| with a regular expression to apply against the value. If the data fails to validate against a constraint the attempt to audit the event will fail. |
| Using constraints can prevent garbage data from being included in the audit database but at the cost of potentially having auditing fail. |
| |
| ![Attribute Editor](images/attributes.png "Attribute Editor") |
| |
| $h3 Events |
| |
| Events represent the aggregation of attributes to be collected when a specific action is performed. Event |
| names should identify what action took place and the associated attributes should identify the key characteristics |
| of who performed the action and what they did. |
| |
| Events can have aliases, however the Catalog UI provides no way to edit them and Log4j Audit |
| currently doesn't do anything with alias fields. |
| |
| The event edit screen allows events to be defined, modified, or deleted. The fields that may be modified are: |
| <table> |
| <tr><th>Field</th><th>Description</th></tr> |
| <tr><td>Name</td><td>The name of the event as it will be known in the catalog. It is expected to be defined in camelCase.</td></tr> |
| <tr><td>Display Name</td><td>The text that should be used to display the name of the event in an application</td></tr> |
| <tr><td>Description</td><td>The description of the event as it would appear in help text in a UI.</td></tr> |
| <tr><td>Assigned Attributes</td><td>The attributes to be associated with this event and whether they are required.</td></tr> |
| </table> |
| |
| RequestContext attributes are always part of audit events whether they are declared or not. Specifying a non-RequestContext |
| attribute is required for it to be associated with an event. Specifying a value of True or False for whether the |
| attribute is required to be present will override whatever definition was present when the attribute was defined. If |
| neither box is checked the attribute definition's required attribute will be honored. |
| |
| |
| ![Event Editor](images/events.png "Event Editor") |
| |
| $h3 Products and Categories |
| |
| Events may be grouped into products and categories, however it is not required that an event be included in a product or category. |
| Log4j Audit doesn't use the products or categories itself, however UI tools that display audit events may choose to filter based on |
| products or categories. |
| |