Studio Developer Manual / Version 2406.0
Table Of ContentsIn order to support the detection of attacks and analysis of incidents, authentication failures as well as successful authentication events are logged by CoreMedia Studio. Example 11.1, “Example Output” shows some typical log entries.
2015-07-07 13:43:30 [WARN] Http401AuthenticationFailureHandler [] - Failed login - User: Rick, IP: 127.0.0.1 (http-bio-8080-exec-8) 2015-07-07 13:51:11 [INFO] Http200AuthenticationSuccessHandler [] - Successful login - User: Rick (coremedia:///cap/user/8), IP: 127.0.0.1 (http-bio-8080-exec-6)
Example 11.1. Example Output
Marker Hierarchy
To get a better overview of security events you might want to duplicate or even redirect such events to extra access logs. To do so CoreMedia Studio uses a SLF4j Marker hierarchy
coremedia - root marker
security - security related entries
authentication - for example login or logout events
authorization - events such as missing rights for certain actions
Example 11.2. Marker Hierarchy
Filtering
Filtering log entries is described in
Logback's Online Documentation, Chapter 7: Filters.
To redirect or duplicate security related log events you will define a filter for an appender using the
JaninoEventEvaluator.
Mind that you will require a runtime dependency on org.codehaus.janino:janino
.
<appender name="access" class="ch.qos.logback.core.FileAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator> <expression><![CDATA[ event.getMarker() != null && event.getMarker().contains("authentication"); ]]></expression> </evaluator> <OnMismatch>DENY</OnMismatch> <OnMatch>ACCEPT</OnMatch> </filter> <encoder><pattern>${log.pattern}</pattern></encoder> <file>access.log</file> </appender>
Example 11.3. Configure Access Log
Example 11.3, “Configure Access Log” shows an example of how to log authentication events
to a file named access.log
. marker
refers to a variable exported by
JaninoEventEvaluator
before parsing. Only authentication events will be logged here.
<appender name="security" class="ch.qos.logback.core.FileAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator> <expression><![CDATA[ event.getMarker() != null && event.getMarker().contains("security"); ]]></expression> </evaluator> <OnMismatch>DENY</OnMismatch> <OnMatch>ACCEPT</OnMatch> </filter> <encoder><pattern>${log.pattern}</pattern></encoder> <file>security.log</file> </appender>
Example 11.4. Configure Security Log
Example 11.4, “Configure Security Log” shows an example how to log any security related events
to a file named security.log
. As security
contains authentication
,
also authentication log entries will go here.
<appender name="default" class="ch.qos.logback.core.FileAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator> <expression><![CDATA[ event.getMarker() != null && event.getMarker().contains("security"); ]]></expression> </evaluator> <OnMismatch>NEUTRAL</OnMismatch> <OnMatch>DENY</OnMatch> </filter> <encoder><pattern>${log.pattern}</pattern></encoder> <file>default.log</file> </appender>
Example 11.5. Configure Default Log
Example 11.5, “Configure Default Log” shows an example for an appender which ignores any security related log entries. You might want to use this approach to hide login/logout entries from unauthorized personal.
<logger name="com.coremedia" additivity="false" level="info"> <appender-ref ref="security"/> <appender-ref ref="access"/> <appender-ref ref="default"/> </logger>
Example 11.6. Configure Logger
Example 11.5, “Configure Default Log” eventually binds all appenders to the given logger.
<turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter"> <Marker>security</Marker> <OnMatch>DENY</OnMatch> </turboFilter>
Example 11.7. Suppress Security Logging
Example 11.7, “Suppress Security Logging” is just another example in case you completely want to suppress security log entries using so called turbo filters.