Diag log description - SSO
- John Jellema
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:
| Timestamp | Type | Message | |
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 |
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 |
Protocol
Protocol entries are generated for diagnostics of protocols, usually connected with runtime errors
Logger: diag.protocol
Example:
2021-06-16 07:42:01,812 protocol TokenServlet: protocol.oauth2.TicketProtocolOAuth2Exception: Ticket validation error |
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) |
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:
2021-06-16 00:27:12,111 tech ping: the system is alive |
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.appender.Diag = com.ubisecure.log4j.DailyFileAppender |
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.