Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of Contents
maxLevel5
minLevel3

Who and how am I

Code Block
languagebash
titleWhat IDP version is currently installed
$ /opt/shibboleth-idp/bin/version.sh
3.4.6

...

Code Block
languagebash
titleWhat does the IDP think of its own state?
/opt/shibboleth-idp/bin/status.sh

Applying updates

See IDP 3 Updates for detailed instructions.

What's happening right now

Code Block
languagebash
titleWatch IDP und Webserver logs
multitail -f /opt/shibboleth-idp/logs/idp-process.log /var/log/tomcat9/access.log

...

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

Who logged in and where, with what attributes sent

Code Block
languagebash
titleAudit log
multitail -f /opt/shibboleth-idp/logs/idp-audit.log

...

Code Block
languagebash
titleHTTP User-Agent IP address in audit and access log
fgrep 192.168.1.99 /opt/shibboleth-idp/logs/idp-audit.log /var/log/tomcat9/access.log

What data will go out for userid X to service Y

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 fails) without needing the subject's cooperation in this issue (or access to their password).

Code Block
languagebash
titleAttributes (and NameID) that would be sent
/opt/shibboleth-idp/bin/aacli.sh --saml2 -n SOME_USERID -r https://test-sp.aco.net/shibboleth

Statistics

ACOnet has contributed a log analysis tool for parsing the Shibboleth IDP's audit logs. For the current day use  /opt/shibboleth-idp/logs/idp-audit.log.

...

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

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

Make sure to undo this after you're done to avoid filling up file systems/volumes/disks with unnecessary DEBUG messages.

Locally managed Service Provider Metadata (non-eduID.at)

See our IDP 3 Metadata configuration documentation.