...
| Code Block |
|---|
| language | bash |
|---|
| title | What IDP version is currently installed |
|---|
|
$ /opt/shibboleth-idp/bin/version.sh
45.10.20 |
Optional (and will only work if you've installed the JSTL libraries as part of the IDP installation):
...
| Code Block |
|---|
| language | bash |
|---|
| title | Watch IDP und Webserver logs |
|---|
|
multitail -f /opt/shibboleth-idp/logs/idp-process.log /var/log/tomcat9tomcat10/access.log |
| Code Block |
|---|
| language | bash |
|---|
| title | Search for IDP Warnings and Errors |
|---|
|
egrep 'WARN|ERROR' /opt/shibboleth-idp/logs/idp-process.log |
...
| Code Block |
|---|
| language | bash |
|---|
| title | Tomcat STDOUT/STDERR (formerly catalina.out) |
|---|
|
journalctl -u tomcat9tomcat10.service -ef |
| Code Block |
|---|
| language | bash |
|---|
| title | Trail all relevant logs at once |
|---|
|
multitail -f /opt/shibboleth-idp/logs/idp-process.log /var/log/tomcat9tomcat10/access.log -l 'SYSTEMD_COLORS=false journalctl -u tomcat9tomcat10.service -f --no-pager' |
Who logged in and where, with what attributes sent
...
| Code Block |
|---|
| language | bash |
|---|
| title | Failed logins in Aug 2020 March 2024 CE |
|---|
|
zgrep ' failed$' /opt/shibboleth-idp/logs/idp-process.log.202008202403* |
| Code Block |
|---|
| language | bash |
|---|
| title | Successful logins today |
|---|
|
fgrep succeeded /opt/shibboleth-idp/logs/idp-process.log |
...
| Code Block |
|---|
| language | bash |
|---|
| title | HTTP User-Agent IP address in audit and access log |
|---|
|
fgrep 192.168.1.99 /opt/shibboleth-idp/logs/idp-audit.log /var/log/tomcat9tomcat10/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 be sending out for a given subject (replace to a given SP. 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 your attribute resolver and attribute filter configuration when you're making changes to either (or both)them, 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 for someone where access works vs. where it fails) without needing the subject's cooperation in this issue (or access to their password).
| Code Block |
|---|
| language | bash |
|---|
| title | Attributes (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 |
|---|
| language | bash |
|---|
| title | Can 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
...
| language | bash |
|---|
| title | Log SAML Messages on DEBUG |
|---|
...
protocol messages
You may never actually need this but if you do here's now:
Set <logger name="PROTOCOL_MESSAGE"
...
level="DEBUG"/> in /opt/shibboleth-idp/conf/logback.xml, save and reload the logging configuration:
| Code Block |
|---|
| language | bash |
|---|
| title | Log SAML Messages on 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 (and harmful, to the IDP's performance) DEBUG messages.
Locally managed Service Provider Metadata (non-eduID.at)
See our IDP 4 5 Metadata configuration documentation.
