Contents
By default, logging is configured for a service with logging level of failure. You can also configure each filter in a policy to log its own message depending on whether it succeeds, fails, and/or throws an exception. Log messages can be stored in several locations, including a database, a file, or the system console. For more details on configuring logging destinations, see the topic on Audit Log Settings.
Logging levels apply to the following cases:
-
A filter succeeds if it returns a true result after carrying out its processing. For example, if an LDAP directory returns an
authorizedresult to an authorization filter, the filter succeeds. -
A filter fails if it returns a false result after performing its processing. For example, an authorization filter returns false if an LDAP directory returns a
not authorizedresult to the filter. -
A filter aborts when it can not make the decision it is configured to make. For example, if an LDAP-based authorization filter can not connect to the LDAP directory, it aborts because it can neither authorize nor refuse access. This is regarded as a fatal error.
You can access the Log Level and Message configuration screen by clicking the Next button on the main screen of all filters. This screen includes the following fields:
Logging Level:
Configure one of the following options:
| Use Service Level Settings | This option is selected by default. Logging is configured for the Web Service with logging level of Failure. |
| Override Logging Level for this Filter | Alternatively, select this option to configure log messages for this filter when it succeeds, fails, and/or aborts. Select Success, Failure, and/or Fatal to configure this filter to log at the respective levels. |
Log Messages:
Default log message values are provided at each level for all filters. When you select the checkbox for a particular level, the default log message for that level is used. You can specify an alternative log message by entering the message in the text field provided.
All filters require and generate
message attributes, while some consume attributes.
In some cases, it may be useful to log the value of these attributes.
For example, instead of an authentication filter logging a generic
Authentication Failed message, you can use the value of the
authentication.subject.id attribute to log the ID
of the user that could not be authenticated.
Use the following format to enter a message attribute selector in a log message:
${name_of_attribute}
At runtime, the API Gateway expands these selectors to the value of the message attribute. For example, to make sure the ID of a non-authenticated user is logged in the message, enter something like the following in the text field for the Failure case:
The user '${authentication.subject.id}' could not be authenticated.
Then if a user with ID oracle can not be authenticated
by the API Gateway (a failure case), the following message is logged:
The user 'oracle' could not be authenticated.
For more details on selectors, see Selecting Configuration Values at Runtime.
Audit Logging Behavior:
This setting is relevant only in cases where you have configured the API Gateway to log audit trail messages to a database. For more details, see the instructions in the section called “Log to Database”.
You can select the Abort policy processing on database log error checkbox if you have configured the API Gateway to write log messages to a database, but that database is not available at runtime. If you have selected this checkbox, and the database is not available, the filter aborts, which in turn causes the policy to abort. In this case, the Fault Handler for the policy is invoked.
Filter Category:
The category selected here identifies the category of filters to which this filter belongs. The default selection should be appropriate in most cases.
