Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


The logging configuration for the IdP is located at $IDP_HOME/conf/logging.xml. This file is checked for changes every 5 minutes and is reloaded if changes have been made. This means a deployer can keep the logging level at WARN until a problem occurs and then change the logging to DEBUG to get more information if the problem persists, all without restarting the IdP.


idp-audit.log contains a log entry for each time the IdP sends data to a relying party. These messages include the audit event time, IdP and relying party IDs, request and response binding, communication profile ID, request and response ID, principal name, authentication method, and released attribute of the current user. This log is written in the machine parsable format auditEventTime|requestBinding|requestId|relyingPartyId|messageProfileId|assertingPartyId|responseBinding|responseId|principalName|authNMethod|releasedAttributeId1,releasedAttributeId2,|nameIdentifier|assertion1ID,assertion2ID,|
Note the name identifier and assertion IDs were add added in Shibboleth 2V2.1.

idp-process.log contains messages logged during the normal operation of the IdP. This log is meant to be human readable and contains messages that indicate what the IdP is currently doing, encountered errors, warning messages that may indicate potential problems, etc.


Log files can be automatically compressed by adding the suffix ".zip" or ".gz" to the the <FileNamePattern> of an log file appender in $IDP_HOME/conf/logging.xml.
Consult the the Logback documentation for further information.





Unique identifier for the user's IdP session. This information is available once a session has been created.


The Servlet container JSESSIONID attribute


The IP address of the remote user-agent. This is the user's browser for front-channel requests and the SP for back-channel requests.

Code Block
titleExample Logging Pattern using the IdP Session IDxml

<Pattern>%date{HH:mm:ss.SSS} - %level [%logger:%line] - [%mdc{idpSessionId}] - %msg%n</Pattern>
Code Block
titleExample Logging Pattern using Client IP in Audit Log


Preventing Access and Audit Log Entry Duplication


To prevent duplication of the audit and/or access log entries to idp-process.log, add the attribute additivity="false" to the Shibboleth-Access and Shibboleth-Audit logger elements:

Code Block

<logger name="Shibboleth-Access" level="ALL" additivity="false">
    <appender-ref ref="IDP_ACCESS" />

<logger name="Shibboleth-Audit" level="ALL" additivity="false">
    <appender-ref ref="IDP_AUDIT" />

Adding a Warn-Level Log

You can create a log that captures all warnings, errors, etc. from the main process log, but excludes certain "common" warnings. The techniques shown can be adapted to filter messages out of the other logs, if so desired. The example also limits the size of the stack traces from Java exceptions.

Code Block
    <!-- Add an appender below the existing ones. -->
    <appender name="IDP_WARN" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- Example of filtering out messages by searching the log message. -->
        <filter class="ch.qos.logback.core.filter.EvaluatorFilter">      
                <expression>event.getMessage().indexOf("trying its failover connector") >= 0</expression>
        <!-- Suppress anything above below WARN. -->
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <Pattern>%date{HH:mm:ss.SSS} - %level [%logger:%line] - %msg%n%ex{3}</Pattern>

    <!-- Modify root logging category at end of file and add new appender. -->
    <root level="ERROR">
        <appender-ref ref="IDP_PROCESS" />
        <appender-ref ref="IDP_WARN" />