Child pages
  • InCommon Shibboleth IdP Training - Operation
Skip to end of metadata
Go to start of metadata

Observing your IdP

  • curl -k
    • Is the IdP running?
    • If the status page is blocked from the docker host VM, you can view the status page, accessed from inside the VM like this:
  • docker ps
    • Is the container running on this node?
  • docker logs <containerID>
    • Is the IdP reporting trouble?
  • docker exec -it <containerID> bash     (Windows users change 'bash' to 'cmd')
    • Give me a shell on this running container
  • docker service ps shib-idp      (only if you are using swarm)
    • Is the swarm service running?  On how many nodes?


The Linux-based IDP container writes most logging information to <stdout> and is available via the 'docker logs <containerID>' command.

The Windows-based container does not yet do the above, so you must either mount a volume over the c:\opt\shibboleth-idp\logs directory or examine the files from the container.

For production operations, you can configure docker to also send these logs to several different backend systems (splunk, etc.).  And/Or, you can configure the IdP itself to send its logs to a remote syslog server.  This aggregates logs from all running nodes in one place.  You can do this by configuring a 'SyslogAppender' in the IdP's logging configuration.  See the bottom of this page for an example.


The IdP maintains some basic configuration and operational information at the /idp/status URL.  This URL can be periodically polled for a quick check on the IdP's overall health and, in fact, periodic checks of it are baked into the IdP container as a docker healthcheck and can be viewed in the output of the 'docker ps' command.


You can easily write simple scripts to parse the IdP log files and generate reports based on the IdP activity.  The IdP also has a metrics subsystem which can generate reports.  See this page for more info.


If your IdP is acting up, the first place to check is the log output from the IdP container (easily available using 'docker logs <containerID>').  If you need to increase the level of detail written to this file, that can be configured in the IdP's logback.xml.  In certain situations, there may be useful diagnostic information in Tomcat's logs as well.  They are also written to <stdout> and available in the 'docker logs <containerID>' command.

The next place to check would be the Shibboleth wiki.

Finally, there is a Shibboleth users mailing list with a large community of members.


For "burned" (and secret-based) container builds, your complete configuration (IdP + Tomcat) should be available on your build machine.  Then, to upgrade your container, simply rebuild your local container, making sure to include the '–pull' option, which says to pull the latest image from the public repo instead of relying on local cache. 

Customizing Your IdP

  • The UI for the login page and error pages is in the config/shib-idp/views directory.
  • If you need to add custom extensions, these can be placed in the config/shib-idp/edit-webapp directory.

  • No labels