Shibboleth IdP - Log server usage (Centralized logs)

In Finnish

Shibboleth-IdP natively supports a centralized log service through its own F-Tticks implementation.F-ticks is easy to configure and the format of the logs can be adjusted freely. In the following example, we will go through a slightly more complicated configuration that has been implemented in a two-node Shibboleth IdP cluster so that both servers work as syslog servers, in which case both servers have the same content from the audit logs.

in use:

• Centos 7.7
• Shibboleth-IdP 5.1.2

F-Ticks

F-ticks style logging can be configured directly in Shibboleth-IdP's configuration file as follows:

# F-TICKS auditing - set a salt to include hashed username
idp.fticks.federation=<TUNNISTE>
idp.fticks.algorithm=SHA-256
idp.fticks.salt=<SUOLA>
idp.fticks.loghost=<SYSLOG PALVELIN>
idp.fticks.logport=514

This alone is not enough for the messages to go to the Syslog server, you still need to connect the IDP-FTICKS adder to the right logger in the logback.xml file.

<logger name="Shibboleth-Audit" level="ALL">
  <appender-ref ref="${idp.audit.appender:-IDP_AUDIT}"/>
  <appender-ref ref="IDP_FTICKS" />
</logger>

Rsyslog

If you are setting up your own syslog service, remember to enable UDP or TCP message reception. If you want, you can also still direct Shibboleth-Audit messages to their own file or/and to another server, more on this later.

# Provides UDP syslog reception
$ModLoad imudp.so
$UDPServerRun 514

# Provides TCP syslog reception
#$ModLoad imtcp.so  
#$InputTCPServerRun 514

.
.

#### RULES ####
# Shibboleth-Audit logs to its own file
:msg, contains, "Shibboleth-Audit"                      /var/log/shibboleth-audit

Firewalls

As you noticed from the Rsyslog section, logitus uses port 514 and depending on which transmission format you use (TCP or UDP), you must allow traffic from the sender of messages to port 514 with the correct protocol on the syslog server end.

• UDP messages are only sent, but the delivery of the messages is not ensured
• TCP messages are sent and it is verified that the message got there.

Two syslog servers

If necessary, you can configure several adders and add the necessary number of these to the logger. Another alternative way is to keep the configuration as above (Without the two adders) and use only the local syslog server where the logs are forwarded. In the following example, we make an adder to Shibboleth IdP that uses a standard value (localhost) because the value is not defined in the idp.properties file (which is the purpose in our case)

<appender name="IDP_FTICKS2" class="ch.qos.logback.classic.net.SyslogAppender">
  <syslogHost>${idp.fticks.loghost2:-localhost}</syslogHost>
  <port>${idp.fticks.logport:-514}</port>
  <facility>AUTH</facility>
  <suffixPattern>[%thread] %logger %msg</suffixPattern>
</appender>

<!-- We will also add this to the previous logger -->

<logger name="Shibboleth-Audit" level="ALL">
  <appender-ref ref="${idp.audit.appender:-IDP_AUDIT}"/>
  <appender-ref ref="IDP_FTICKS" />
  <appender-ref ref="IDP_FTICKS2" />
</logger>

The same example using rsyslog for message placement and forwarding, with one addition (Without the above configuration).

#### RULES ####
# Shibboleth-Audit logs to their own file
:msg, contains, "Shibboleth-Audit"                      /var/log/shibboleth-audit.log
# Shibboleth-Audit logien edelleen lähetys toiselle syslog serverille.
:msg, contains, "Shibboleth-Audit"                      @<Another syslog server>

# An alternative configuration if you make logs crosswise between two nodes, to avoid loops forward only your own logs, not those from elsewhere.
#### RULES ####
if $msg contains "Shibboleth-Audit" then {
  /var/log/shibboleth-audit
  if $hostname == "<LOCALHOST>" then @<REMOTE_HOST>
  & stop
}