Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: link to examples

...

Info

Paths and file names below assume a default installation location (/opt/shibboleth-idp) and unchanged logging/logback configuration. Though you might prefer to adjust your logging config and or make /opt/shibboleth-idp/logs a symbolic link to another file system/volumedirectory. You might also want to remove the "idp-" prefix from all the {process,warn,audit,consent-audit} log files since they'll likely end up in one IDP-specific logging directory anyway (and having all files start with the same letter isn't overly useful). But again, the examples below can't match local deployment decisions and so have been written to match a default IDP installation's behaviour. So please adjust as needed.

Table of Contents
maxLevel5
minLevel3

...

Code Block
languagebash
titleTrail all Tail relevant logs at once
multitail -f /opt/shibboleth-idp/logs/idp-process.log /var/log/tomcat9/access.log -l 'journalctl -u tomcat9.service -f'

...

Code Block
languagebash
titleAudit events for a given UserID
fgrep '|someuser99|' /opt/shibboleth-idp/logs/idp-audit.log
Code Block
languagebash
titleWhat attributes and NameIDs would be going out for person X to service Y?
/opt/shibboleth-idp/bin/aacli.sh --saml2 -n someuser99 -r https://test-sp.aco.net/shibboleth


Code Block
languagebash
titleFailed logins in Jan 2019
zgrep ' failed$' /opt/shibboleth-idp/logs/idp-process.log.201901*

...

The aacli is a very useful tool to test what data the running IDP would send for a given subject (replace SOME_USERID below with the login name the subject would enter during authentication) to a given SP. Not only does that help verifying your attribute resolver  and attribute filter configuration when you're making changes to either (or both), it can also be useful in debugging access problems someone experiences at a given SP as you can easily compare what data would go out for different subjects (e.g. in cases where access works vs. where it failsfor one person but fails for another) without needing the subjectsubjects' s cooperation in this issue (or access to their password).

...

Code Block
languagebash
titleCan be done for whole months or even years
loganalysis.py -cul /opt/shibboleth-idp/logs/idp-audit.log.201812*
21 unique relying parties
15 unique userids
406 logins

Maybe try one of the structured output formats for easy post-processing, e.g. JSON:

Code Block
languagejs
titleCan be done for whole months or even years
$ loganalysis.py -j /opt/shibboleth-idp/logs/idp-audit.log.20200[1-6]*
{
  "stats": {
    "logins": 8327,
    "rps": 211,
    "users": 150
  },
  "logins_per_rp": {
    "https://sp.example.org/saml": 29,
    "https://wiki.example.edu/shibboleth": 163,
    "usw.": "usf."
  }
}

For more see the built-in help ( loganalysis.py --help) or the examples in the documentation.

Debugging

Code Block
languagebash
titleLog SAML Messages on DEBUG
$EDITOR /opt/shibboleth-idp/conf/logback.xml  # Set <logger name="PROTOCOL_MESSAGE" level="DEBUG"/> and save
/opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.LoggingService

...