Audit Log
Introduction
The Audit Log receives, stores, and returns logging information about important user actions and system events. Messages spawned by other services are automatically stored, and can be retrieved via a REST API.
Technologies used
MongoDB: MongoDB is used as the Audit Log’s storage solution.
How it works
The Audit Log serves as a persistent, immutable repository for pieces of information that are important to the operation of the Open Integration Hub. It receives this information through the Message Oriented Middleware, sent by the other services.
These messages are called events, and are saved as logs. Each event has a name, e.g. user.created, and a payload containing the relevant information. As each Service knows best what information would be relevant, the Audit Log makes no requirements as to the format of this payload, and instead simply accepts arbitrary JSON in its place.
The Audit Log maintains a list of event names it listens for. Each time an event with a name from the list is spawned somewhere in the Open Integration Hub, the Audit Log automatically saves it as a log. Events with names that are not on this list are ignored by the Audit Log.
List of listened-for events
The names of events generally follow the schema of [context].[object].[action]. This is the list of all event names that the Audit Log currently listens for:
'iam.user.created',
'iam.user.deleted',
'iam.user.modified',
'iam.user.removedFromTenant',
'iam.user.assignedToTenant',
'iam.user.loginFailed',
'iam.tenant.created',
'iam.tenant.deleted',
'iam.tenant.modified',
'iam.role.created',
'iam.role.deleted',
'iam.role.modified',
'iam.token.created',
'iam.token.deleted',
'iam.token.modified',
'iam.permission.created',
'iam.permission.deleted',
'iam.permission.modified',
'secret-service.secret.created',
'secret-service.secret.deleted',
'secret-service.token.get',
'metadata.domain.created',
'metadata.domain.deleted',
'metadata.domain.modified',
'metadata.schema.created',
'metadata.schema.deleted',
'metadata.schema.modified',
'flowrepo.flow.created',
'flowrepo.flow.modified',
'flowrepo.flow.deleted',
Log Schema
All logs are stored in this schema:
{
"headers": {
"serviceName": "string",
"createdAt": "string",
"name": "string"
},
"payload": {
"user": "string",
"tenant": "string"
}
}
The headers object is automatically generated by the Message Oriented Middleware. As mentioned before, the payload object can contain arbitrary JSON. However, two keys are reserved: user, containing the id of the user that caused this event, and tenant, containing the id of the tenant in which this event has taken place. Both of these keys are optional, as events are not necessarily associated with a user or a tenant.
Logs are immutable, and cannot be changed nor deleted by user input once they have been stored. The only time they are altered after the fact is when a user is deleted. In this case, the user’s id and username are anonymized in all logs that feature them.
Audit Log API
The Audit Log offers a REST API for viewing and manually storing logs.
For retrieving and viewing stored logs, the API offers a single endpoint GET /logs, which allows for detailed filtering of the results through query arguments. Regular users are limited to viewing logs that are directly associated with their own tenant, or with the user themselves. See the section “Ownership and Permissions” for further details.
Additionally, there is another endpoint POST /logs that allows a user to manually save a log in the Audit Log. Please note that this end point exists primarily for testing and debugging purposes. During standard operation in a production environment, all logs should be automatically created by listening to events on the Message Oriented Middleware.
For further information and examples about the API, please refer to the API Reference.
Ownership and Permissions
As the Audit Log stores information about system-wide events, regular users are heavily restricted in which logs they can view. They can only see logs whose user or tenant ids match their own. Furthermore, regular users are required to have the relevant permission to be able to view logs. For further information about permissions, please refer to the documentation of the Identity Management.
Open Integration Hub system administrators have neither of these restrictions, and can freely view all logs.
Interaction with other Services
The Audit Log can receive events from any service, but only directly interacts with two of them:
-
Message Oriented Middleware: The Audit Log receives all events it is supposed to store through the Message Oriented Middleware.
-
Identity Management: The Audit Log requires a bearer token created by the Identity Management to determine which logs the current user is allowed to view.