Basic Reporting for Shibboleth Identity Provider

This page relates to deployments on Linux or similar platforms. If you're running Windows then IdPBasicReportingWindows may be more useful

The Shibboleth IdP records requests and responses in the IdP Audit log. By default this takes the format, set in .../conf/audit.xml:

<util:map id="shibboleth.AuditFormattingMap">
    <entry key="Shibboleth-Audit" value="%T|%b|%I|%SP|%P|%IDP|%bb|%III|%u|%ac|%attr|%n|%i|%X" />
 </util:map>

Previous versions of the IdP defaulted to logging in a slightly different format which doesn't include the SAML bindings so you should check the format your IdP is using. Upgraded instances retain the old behaviour.

First, identify which field in the pipe-separated file you'd like to report on. For example, the output binding (%bb) is at position 7 and the SP entityid (%SP) is at position 4.

Using standard UNIX tools, a brief report can be created of the bindings in use for a given period of time:

cd /opt/shibboleth-idp/logs # adjust for your IdP's deployment
zcat idp-audit-*.log.gz | cut -d"|" -f 7 | sort | uniq -c

This might produce output similar to:

      8
     14 urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding
      5 urn:oasis:names:tc:SAML:1.0:profiles:browser-post
  10895 urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
      1 urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
     56 urn:oasis:names:tc:SAML:2.0:bindings:SOAP

On some systems you may need to use gzcat instead of zcat

The log files are automatically rotated daily and then compressed. This command will look at all available logs in September 2020 and do a pivot table type operation on column 7 to produce a count of each value.

The above output shows that the vast majority of requests are serviced using SAML2 bindings (urn:oasis:names:tc:SAML:2.0:...). The first line occurs when the aacli test tool is used without a specific binding requested and can be safely ignored.

To check which entities are using the older SAML1 bindings, run the following:

zcat idp-audit-*.log.gz | grep urn:oasis:names:tc:SAML:1.0: | cut -d"|" -f 4 | sort | uniq -c

Output might look like:

      9
      4 https://auth.galegroup.com/shibboleth
      1 https://portal.moonshot.ja.net/shibboleth
      1 https://sp-vaas-stage.asknet.de/shibboleth
      4 https://test.ukfederation.org.uk/entity

Here the 9 "blank" entities are likely related to invalid requests sent to the SOAP (back-channel) endpoints and can also be ignored.

These entities should, therefore, be the target of any remediation conversations to discover why the older bindings are in use and how to move to SAML2.

Explanation of pivot-table commands

Which SAML bindings are in use?

zcat <files> |       # Decompress the log files and pass through
   cut -d"|" -f 7 |  # Extract field 7 from a pipe ("|") separated input stream
   sort |            # Sort the output for the next command
   uniq -c           # Group the sorted output and produce a numerical count

Which flows are using SAML1 bindings?

zcat <files> |                          # Decompress the log files and pass through
   grep urn:oasis:names:tc:SAML:1.0: |  # Select lines matching this pattern
   cut -d"|" -f 4 |                     # Extract field 4 from a pipe ("|") separated input stream
   sort |                               # Sort the output for the next command
   uniq -c                              # Group the sorted output and produce a numerical count