Understanding SSO logger configuration - SSO

SSO authentication server (uas)

Linux installation /usr/local/ubisecure/ubilogin-sso/ubilogin/webapps/uas/WEB-INF/classes/logback.xml:

Windows installation C:\Program Files\Ubisecure\ubilogin-sso\ubilogin\webapps\uas\WEB-INF\classes\logback.xml:

Notes:

• The attribute debug="true" in the configuration element facilitates troubleshooting for the logging configuration

  • When set to true, logback will print status information to the console as it processes the configuration

  • In Windows installations, see the note about Troubleshooting the log configuration at the end of this page

  • All other web applications except uas has this setting as false in order not to repeat the status information many times

• The attribute scan="false" in the configuration element disables scanning of changes in the logger configuration files (logback.xml and include-logback.xml)

  • If set to true, logback will reload the logging configurations found in both files

  • The interval to scan for any file changes is defined by the scanPeriod setting

  • All web applications have this set to false by default

• The LOG_CONTEXT property is individual for each web application and is the same as the folder name of that application

Linux installation: /usr/local/ubisecure/ubilogin-sso/ubilogin/custom/logging/include-logback.xml

Windows installation: C:\Program Files\Ubisecure\ubilogin-sso\ubilogin\custom\logging\include-logback.xml

Each section of this file is explained below.

• SSO diagnostic log levels especially for the uas application can be set by entry types, see Diag log description

• DefaultLevels element specifies the default levels for each entry type

• Without this definition the default level is off

• Default level can be overridden here or the level in use can be set via the management UI

• Audit log is enabled by default

• In order to enable Statistics log, DefaultLevels element values need to be modified

• By default, log files are rotated on a daily basis and the old files are never deleted

• By removing comment signs from these properties and specifying the amount of days you need to preserve, you can make logback to delete the old files automatically

• Property LOG_FILE_MAX_HISTORY applies to SSO diagnostics log (sso_diag.<YYYY-MM-DD>.log)

• Property AUDIT_LOG_FILE_MAX_HISTORY applies to uas and SSO management (ubilogin) audit logs and statistics log (uas3_audit.<YYYY-MM-DD>.log, uas3_statistics.<YYYY-MM-DD>.log, management_audit.<YYYY-MM-DD>.log)

• Property PASSWORD_AUDIT_LOG_FILE_MAX_HISTORY applies to password and password-reset audit log (password_audit.<YYYY-MM-DD>.log)

• Log format is specified for each logback appender with pattern properties

• The format for file appenders are compatible with e.g. Logviewer

• Diagnostic log pattern is the same for all web applications except sso-api has even more fields in it, the fields are:

  • date-timestamp

  • web application name e.g. uas, ubilogin, sso-api etc.

  • either the entry type (init, tech, method etc.) or fully qualified class name (e.g. com.ubisecure.saml2.metadata.URLMetadataLocator)

  • log level

  • sso-api only: remote IP address of the caller

  • sso-api only: authenticated user calling the API

  • log message

  • exception message

    • the full stack trace is printed only in case of debug level set to the entry type or fully qualified class name of this log event

    • full stack trace is printed always in case of a third party library logging an exception

• Audit log patterns are compatible with previous releases

• We don’t recommend you to modify these settings except CONSOLE_LOG_PATTERN can be altered if desired

• Windows installation: <property name="LOG_FOLDER" value="C\:\\Program Files\\Ubisecure\\ubilogin-sso\\ubilogin/logs" />

• These settings define the log folder which is set during the installation process (platform specific) and the log file base names

• The noteworthy thing with file appenders is that a time based rolling policy on daily basis has been defined like in the previous releases

• Because the file element on top of the rollingPolicy element is commented out, also the current day's file has the date in its name (e.g. sso_diag.2022-11-25.log)

  • In linux systems it is possible to remove the comment signs from the file element and have the current day’s file without date in its name (e.g. sso_diag.log)

  • Only the files with the date in their names are visible in the Logviewer application

• The maxHistory element is defined only if the respective property is set in the beginning of this configuration file

  • Logback system works in such away that the arrival of the first event after midnight will trigger a rollover, and if maxHistory has been specified the old files are deleted at that time

  • If no events are written to a particular log file rollover happens in restart when the appender is being started. In this case the old files are not deleted if you don’t add this definition to your logback configuration: <cleanHistoryOnStart>true</cleanHistoryOnStart>
    Example when password applications are not in use:

    <property name="PASSWORD_AUDIT_LOG_FILE_MAX_HISTORY" value="1" /> ... <appender name="PASSWORD_AUDIT_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> ... <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${LOG_FOLDER}/password_audit.%d{yyyy-MM-dd}.log</fileNamePattern> <cleanHistoryOnStart>true</cleanHistoryOnStart> <if condition='isDefined("PASSWORD_AUDIT_LOG_FILE_MAX_HISTORY")'> <then> <maxHistory>${PASSWORD_AUDIT_LOG_FILE_MAX_HISTORY}</maxHistory> </then> </if> </rollingPolicy> </appender>

• In order to activate Management audit log, the level attribute here must be set to INFO

• If you are not interested in this feature, you may delete the whole section, as even if you have no events for them, these definitions will create empty files each day when the system is restarted

• This section in relevant only if you utilise the SatuHetu utility.

• This section is used by Ubisecure’s Identity Cloud service and is not relevant for customer installations.

• In this section the default level INFO is specified for each appender

• This means that the default logging level for all Java classes, implemented by Ubisecure or third parties, is INFO

• If you don’t utilise console logging, you may remove CONSOLE appender from this list

• If you don’t utilise file appenders, you may remove them from this list. Note: if you have no events for the file appenders they will still create empty files each day when the system is restarted

• You should keep at least FILE and AUDIT_FILE appenders here

• In this section you can override the default level INFO for any Java package or class

• You can set a higher level in order to reduce logging

• You can set a lower level when troubleshooting

Windows installation example (the paths differ in the linux installation)