Diag log description - SSO

Introduction

One of logs written by Ubisecure SSO is the diag log. Diag logs are divided into multiple types and contain diagnostic information about configuration, initialization or some runtime events. The logs are written to files that are usually named according to the convention uas_diag3.[data].log (where [date] is formatted as YYYY-MM-DD). Log file names may be altered by configuration settings.


General format

The log consists of fields separated by spaces. Each line represents one log entry and starts with a timestamp in ISO 8601 format. The next value represents the type of log entry. The last field is the message.

General log entry format:

TimestampTypeMessage


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 entry is generated during system startup and initialization. Contains information about initialized components, crucial parameters, possible warnings and errors.

Logger: diag.init

Example:

2021-08-03 16:38:53,619 init SingleLogoutProtocol: started
2021-08-03 16:38:53,629 init SessionFactoryLDAP: root=cn=ServerSession,ou=System,cn=Ubilogin,dc=test dynamicObjectSessionStore=false
2021-08-03 16:38:53,629 init SessionFactoryLDAP: started

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:

2021-08-03 16:38:52,241 environment  Provider: SunJGSS
2021-08-03 16:38:52,241 environment Services:
2021-08-03 16:38:52,241 environment GssApiMechanism.1.2.840.113554.1.2.2 = sun.security.jgss.krb5.Krb5MechFactory (max strengh)
2021-08-03 16:38:52,241 environment GssApiMechanism.1.3.6.1.5.5.2 = sun.security.jgss.spnego.SpNegoMechFactory (max strengh)
2021-08-03 16:38:52,241 environment Properties:
2021-08-03 16:38:52,241 environment GssApiMechanism.1.2.840.113554.1.2.2 = sun.security.jgss.krb5.Krb5MechFactory
2021-08-03 16:38:52,241 environment GssApiMechanism.1.3.6.1.5.5.2 = sun.security.jgss.spnego.SpNegoMechFactory

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:

2021-06-16 07:42:01,812 protocol TokenServlet: protocol.oauth2.TicketProtocolOAuth2Exception: [application-clientid] Invalid ticket request: code_verifier

Login

The login entry is generated at runtime to diagnose ubilogin authentication mapping issues. 

Logger: diag.login

Example:

2021-08-03 16:38:53,619 login DEBUG Locator.findUbiloginAuthMapping(testlogin): (&(objectClass=ubiloginAuthMethod)(cn={0})(ubiloginAuthMapping={1})): names.size()=1

Method

This type of entry is used for diagnostic of runtime errors of authentication methods

Logger: diag.method

Example:

2021-06-16 01:43:26,253 method com.ubisecure.ubilogin.sso.ubilogin.authorizer.MethodMenuFilter:UbiloginAgent[cn=CustomerID API,ou=eIDM Services,cn=Ubilogin,dc=example]:[MethodStatus[password.2,true]]

Mapper

Mapper entries are used when mapping users to groups. They are created for runtime diagnostic.

Logger: diag.mapper

Example:

2021-06-16 01:43:26,258 mapper ubilogin.mapper.RegisteredMapper:Identity[UBILOGIN&password.2&<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" NameQualifier="ldap:///cn=Ubilogin,dc=example">cn=d3857c0f-bf12-4de8-80cd-60ab2abaeeb3,ou=Users,ou=eIDM Users,cn=Ubilogin,dc=example</saml:NameID>]:[UbiloginGroup[cn=eIDMUser,ou=eIDM,ou=eIDM Users,cn=Ubilogin,dc=example], UbiloginGroup[cn=Password Users,ou=Password,ou=System,cn=Ubilogin,dc=example], UbiloginGroup[cn=CustomerID API Users,ou=eIDM Services,cn=Ubilogin,dc=example], UbiloginGroup[cn=Authenticated Users,ou=System,cn=Ubilogin,dc=example], UbiloginGroup[cn=eIDMUser,ou=eIDM Groups,cn=Ubilogin,dc=example]]

Acl

Another type of runtime diagnostic entry is access control, named acl.

Logger: diag.acl

Example:

2021-06-16 01:43:31,799 acl ubilogin.authorizer.saml2.SubjectAccess:Identity[UBILOGIN&password.2&<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" NameQualifier="ldap:///cn=Ubilogin,dc=example">cn=d3857c0f-bf12-4de8-80cd-60ab2abaeeb3,ou=Users,ou=eIDM Users,cn=Ubilogin,dc=example</saml:NameID>]:true

Authz

Auths entries are related to authorization diagnostic and are created at runtime.

Logger: diag.authz

Example:

2021-06-16 01:43:31,800 authz ubilogin.authorizer.UsernameAuthorizer:Identity[UBILOGIN&password.2&<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" NameQualifier="ldap:///cn=Ubilogin,dc=example">cn=d3857c0f-bf12-4de8-80cd-60ab2abaeeb3,ou=Users,ou=eIDM Users,cn=Ubilogin,dc=example</saml:NameID>]:urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName:password.2.grant_type=password&password.2.dn=cn%3Dd3857c0f-bf12-4de8-80cd-60ab2abaeeb3%2Cou%3DUsers%2Cou%3DeIDM+Users%2Ccn%3DUbilogin%2Cdc%3Dexample&password.2.ldap=ldap%3A%2F%2F%2Fcn%3DUbilogin%2Cdc%3Dexample

UI

There is separate type of ui entries and represents diagnostic of user interface issues. Created at runtime. 

Logger: diag.ui

2021-06-16 03:12:33,876 ui unmarshalJSON: protocol.oauth2.TicketProtocolOAuth2Exception: The requested application is invalid: javax.json.stream.JsonParsingException: Unexpected char 60 at (line no=1, column no=1, offset=0)

Session

Session entries are generated for diagnostics of session handling, usually connected with runtime errors.

Logger: diag.session

Example:

2021-08-05 11:04:28,021 session SessionStoreGC.gc(1628168668021)
2021-08-05 12:53:31,370 session expired SingleSignOnSession _7beddef3b05b8034a3265c455d73e64edfc6fb1b

Identity

This type of entry is used for diagnostic of runtime errors on identity creation and encoding.

Logger: diag.identity

Example:

2021-06-16 03:19:36,992 identity X509IdentityFactory.createIdentities(): Identity[UBILOGIN&password.2&<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" NameQualifier="ldap:///cn=Ubilogin,dc=example">cn=d3857c0f-bf12-4de8-80cd-60ab2abaeeb3,ou=Users,ou=eIDM Users,cn=Ubilogin,dc=example</saml:NameID>]

Inboundmapping

Separate type of entries is inboundmapping. It's used for diagnostics of attributes mapping.

Logger: diag.inboundmapping

Example:

2021-08-09 14:28:08,340 inboundmapping WARN InboundMappingTable: ubiloginAttributeName: cn=1,cn=imt.soso.1,cn=Server,ou=System,cn=Ubilogin,dc=test

Tech

Tech entries are used for miscellaneous diagnostics messages.

Logger: tech

Example:

Configuration

The Diag log may be configured either via configuration file (log4j.properties) or via SSO UI.

Configuring via log4j.properties file

The log4j.properties file is located in web application directory for the UAS module (tomcat/webapps/uas/WEB-INF/log4j.properties) and contains the configuration of all logs for the UAS. By convention the lines responsible for the diag log are set as follows:

log4j.logger.ubilogin.tech = INFO, Diag, C
log4j.logger.ubilogin.diag = INFO, Diag
log4j.logger.ubilogin.diag.init = INFO, C


log4j.appender.Diag = com.ubisecure.log4j.DailyFileAppender
log4j.appender.Diag.File = @logs.dir.esc@/uas3_diag
log4j.appender.Diag.layout = org.apache.log4j.PatternLayout
log4j.appender.Diag.layout.ConversionPattern = %d{ISO8601} %c{1} %m%n

The upper lines are responsible for setting the logging level and assigning logger types to the Diag log. The lower lines define the naming and layout of the files.
These changes are stored locally on each node. To change these settings you need to manually apply the same changes on all nodes, a restart of Tomcat may also be required.

Configuring via UI

If you would like to change the logging level only, there is an alternative to manual file-based changes. In the UI of SSO application at the Home level there is Logging tab. When you click on it, all loggers with a custom (non default) configuration for the UAS module are listed:


Here you can also select the logger type (including diag options) and choose the level from: Default, Debug, Info, Warning, Error and Off.

When you click "update" the logging level for the selected logger will change and the list of UAS loggers will be updated.
If you select a logging level other than Default the logger will appear in the list. If the Default level is selected, the logging level for the selected logger will be reset to the default and will not be presented in the list.