Diag log description - SSO
Introduction
All Ubisecure SSO applications deployed to SSO Tomcat print diagnostic information to the shared SSO diagnostic log. In the default installation the file is named sso_diag.YYYY-MM-DD.log and it resides in the ubilogin/logs folder.
See Understanding SSO logger configuration about the technical details.
General format
Each line in the diagnostic log file represents one log entry with a set of fields separated by a space.
General log entry format:
Timestamp | Context | Type | Level | Message |
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Each log entry starts with a timestamp in the following format: YYYY-MM-DD hh:mm:ss,SSS.
The next field contains the name of the application printing the events the first field after the timestamp. The application name is the same as the webapp folder in the installation:
uasubiloginlogviewersearchsso-apitotppasswordpassword-resetcdcotpserver
The type of log entry is either one of the predefined Entry type or a fully qualified class name.The predefined Entry types are especially in use by the SSO Authentication server (uas) and are explained later in this document.
Log level is one of the well-known logging levels: TRACE, DEBUG, INFO, WARN, or ERROR. The default levels to log are: INFO, WARN and ERROR. You may configure the desired level to log based on the type of the log entry. How to modify the log levels is described in the end of this document.
The last field is the log message. In case of SSO API (sso-api) the log message is preceded by two additional fields: IP address and the authenticated user name (sub).
In case of an exception the log entry is followed by the exception stack trace only if DEBUG level is set for the type of this log entry. This rule applies only to the Ubisecure developed code and is meant for preserving disk space.
Entry types
There are currently thirteen possible log entry types: init, environment, protocol, login, method, mapper, acl, authz, ui, session, identity, inboundmapping and tech.
Each of these will be detailed with example content for each field in the listing below.
Init
An init entry is generated during system startup, initialization, and stopping. Contains information about initialized components, crucial parameters, possible warnings and errors.
Logger: diag.init
Examples:
|
Environment
This type of entry is also generated on startup and contains information related to the runtime environment and configuration. Data may be written in many rows and the structure of the data is indicated by the row indentation.
Logger: diag.init.environment
Example:
|
Protocol
Protocol entries are generated for diagnostics of protocols, usually connected with runtime errors.
For some exceptions of type TicketProtocolException and its subtypes, such as TicketProtocolOAuth2Exception and TicketProtocolSAML2Exception, the issuer of the request (which is the client_id or entityId of the application) is shown in square brackets.
Logger: diag.protocol
Example:
|
Login
The login entry is generated at runtime to diagnose SSO authentication mapping issues. Happy-case entries are seen only if DEBUG level is specified for this type.
Logger: diag.login
Example:
|
Method
This type of entry is used for runtime diagnostic of authentication methods.
Logger: diag.method
Example:
|
Mapper
Mapper entries are used when mapping users to groups. They are created for runtime diagnostic.
Logger: diag.mapper
Example:
|
Acl
Another type of runtime diagnostic entry is access control, named acl.
Logger: diag.acl
Example:
|
Authz
Auths entries are related to authorization diagnostic and are created at runtime.
Logger: diag.authz
Example:
|
UI
These entries are used for runtime diagnostic of user interface issues. Happy-case entries are seen only if DEBUG level is specified for this type.
Logger: diag.ui
|
Session
Session entries are generated for diagnostics of session handling, usually connected with runtime errors. Happy-case entries are seen only if DEBUG level is specified for this type.
Logger: diag.session
Example:
|
Identity
This type of entry is used for runtime diagnostic of identity creation and encoding.
Logger: diag.identity
Example:
|
Inboundmapping
This specific type is used for diagnostics of attributes mapping.
Logger: diag.inboundmapping
Example:
|
Tech
Tech entries are used for miscellaneous diagnostics messages.
Logger: tech
Example:
|
Logger configuration
The default logger configuration is detailly explained in Understanding SSO logger configuration.
We don't recommend modifications to the default Diagnostic log configuration except tuning the log levels especially when troubleshooting issues.
Configuring log levels for predefined Entry types
The Diagnostic log levels for predefined may be configured either via SSO Management UI or via the configuration file.
Configuring via SSO Management UI
Configuring via SSO Management UI Logging tab is the recommended way as no server restart is required and in a clustered environment the change applies to both nodes.
See Management UI logging configuration for guidelines.
Configuring with Logback configuration files
It is also possible to override the default levels for the Entry types in the logger configuration file which resides in the following location in the default installation:
Windows:
C:\Program Files\Ubisecure\ubilogin-sso\ubilogin\custom\logging\include-logback.xmlLinux:
/usr/local/ubisecure/ubilogin-sso/ubilogin/custom/logging/include-logback.xmlTo change the default levels please modify the DefaultLevels value in this section:
<!-- (1) Default levels for Diagnostic logs entry types -->
<turboFilter class="com.ubisecure.common.logging.MarkerBasedLogFilter">
<DefaultLevels>audit=info;tech=debug;diag.*=info;diag.init.environment=warn</DefaultLevels>
</turboFilter>The syntax for DefaultLevels is the following:
the delimiter for individual entry type settings is semicolon (;)
the entry type key is one among these listed in section Entry Types in lowercase (
diag.init,diag.init.environment,tech, etc.);diag.*can be used to specify all entry types starting withdiagthe case.insensitive default level is one of these:
trace,debug,info,warn,error,offand is specified after equal sign (=), e.g.tech=infothe default level if not specified is
off
Configuring log levels for arbitrary classes
The log levels for arbitrary classes may be configured only via configuration file include-logback.xml.
You can specify package name, part of the package name, or a fully qualified class name. You can also define the log level of any of the SSO or 3rd party libraries.
Please add your definitions to the following section in the configuration file:
<!-- (10) Customise log levels -->
<!-- Some examples -->
<logger name="com.ubisecure.saml2" level="DEBUG" />
<logger name="com.ubisecure.saml2.metadata.URLMetadataLocator" level="INFO" />
<logger name="org.apache.activemq" level="WARN" />