IdPLoggingConfig

Logging

There are many different log files that are used by various pieces of the Shibboleth !IdP. Beyond the error and transaction logs that may be generated by Shibboleth itself, much relevant information is contained in the logs of the applications within which the !IdP runs. Be aware that various trust arrangements may include requirements on the duration and manner of storage of log information to maintain both user privacy and sufficient information to comply with access and identity auditing and tracking when necessary.

Errors that occur prior to the initiation of Shibboleth will appear in Apache or Tomcat logs(for example, catalina.out , /var/log/httpd/access_log , and /var/log/httpd/error_log . Errors encountered in the operation of Shibboleth will generally appear in the Shibboleth logs, but certificate-related issues, configuration, and session handling problems can all still appear in the Tomcat and Apache logs.

=<Logging>=

This container element identifies a logging method for the !IdP itself to use and may not occur more than once. Three different logging methods may be specified depending on what is placed inside this element. If nothing is specified, then all logs go to the container console. If ErrorLog and TransactionLog elements are present, more traditional logging flatfiles will be generated at the locations specified. A Log4JConfig element instructs the !IdP to use Log4J logging.

Flat-File Logging

Flat-file logging information is forked into an error log and a transaction log. The former is much more useful for debugging and monitoring the functionality of the !IdP, while the latter contains most information useful for auditing purposes. DEBUG is useful for initial testing, but WARN is recommended for production deployments to avoid enormous logfiles.

=<ErrorLog level="level" location="URL">=

Paired with a TransactionLog element, this will log any errors encountered by the !IdP above a certain logging threshold to a flat file at the referenced URL . Valid levels in order of decreasing sensitivity are DEBUG , INFO , WARN , ERROR , and FATAL . If no logging is desired, specify OFF ; defaults to WARN .

Must be contained by a Logging element.|

=<TransactionLog location="URL">=

Paired with an ErrorLog element, this will log all transactions that the !IdP is involved in. The information in this file is sensitive and may be useful for auditing and security purposes. Must be contained by a Logging element.

Log4J Logging

The Shibboleth !IdP also supports Log4J logging, sent through Log4J's standard mechanism. The location of the log file, the level at which the log is output, the formatting of the logs, and many more options may be configured by editing the value of the Log4JConfig attribute described below. This is typically located at /WEB-INF/classes/conf/log4j.properties . The default is setup to log to the console of the servlet container, with a level of WARN , but there is also a commented out example in the file to give a possible alternate configuration.

=<Log4JConfig location="pathname"/>=

This element informs Shibboleth to utilize Log4J as a logging system and points to the relevant configuration file using the location attribute. A basic configuration is included with the distribution at /WEB-INF/classes/conf/log4j.properties . This is set up to log to the console of the servlet container with a level of WARN , but there is also a commented-out example in the file to give a possible alternate configuration. This element must be contained by a Logging element and may not be paired with a TransactionLog or ErrorLog element.

`catalina.out`

Much of the Shibboleth !IdP functions within the Tomcat JRE. Information will appear in Tomcat's logfiles in several circumstances:

Malformed IdP.xml ;
Malformed resolver.xml ;
Errors passing sessions from Apache to Tomcat, e.g. simultaneous session mismatches;
Other initiation errors

Most relevant Tomcat output is found in catalina.out . Other information regarding errors in session handling may be present in catalina_out .