ESOE Logging Design

Enterprise Sign On Engine Technical Architecture
Written by Bradley Beddoes
September 2006

Architecture design by Bradley Beddoes
Incorporates SAML 2.0, and (L)XACML 2.0 OASIS standards

Contributions by:
Shaun Mangelsdorf
Andre Zitelli

Edited by:
Bradley Beddoes
Shaun Mangelsdorf
Andre Zitelli

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119

Logging Processor

Component Lead Bradley Beddoes
Package NA
Type NA
Implemented Interfaces NA
Exceptions NA

The logging processor is responsible for distributing interesting events that are occuring inside the ESOE to registered logging handlers, these handlers may inturn distribute messages to any medium which they implemented for including syslog, flatfile, databases, webservices or snmp to name a few examples.

The logging processor is not a concrete class, it is instead conceptual and makes use of the Log4j package.

Handlers are responsible for actually carrying out some kind of action in regards to logging an event. Log4j specifies that handlers are invoked when they meet some specific criteria. The criteria are all laid out inside the log4j.xml document distributed as part of the ESOE.

Handlers MAY log data to any source they wish, syslog, flatfile, databases, webservices or snmp for example.

Handlers SHOULD timestamp every message they log, where the backend system can't reasonably be manipulated to store timestamps they MAY be left out, however this must be clearly indicated in the associated documentation for the handler.

The ESOE defines three additional logging levels of AUTHN, AUTHZ and INSANE these are implemented as extenstion levels to log4j.


This level is for events that are directly related to success or failure of a principal to authenticate, it should only be called once for each authenctication attempt


This level is for events that are directly related to permit or deny states when a principal requests access to some resource at a remote SPEP. It should only be called once for each resource access attempt.


This level is utilised for logging any data which would be highly unusual to ever want to see and for large volumes of data, examples of this MAY include but are not limited to complete http handshake data, full SAML documents and encrypted/encoded data blocks.