Public | Automated Build

Last pushed: 5 months ago
Short Description
A Shibboleth IdP appliance (or base image ready for a configuration overlay)
Full Description

This project is essential abandoned as the work has moved to a more notable location and has more folks working on it than just me (althought I continue to be the primary maintainer. Please check out and


This Docker image contains a deployed Shibboleth IdP 3.1.2 running on Java Runtime 1.8 update 60 and Jetty 9.3.3 running on the latest CentOS 7 base.

This image can be used as a base image overriding the configuration with local changes, or as an appliance and used directly by using a local configuration.

Jetty has been configured to use setuid and http traffic is handled by a non-root user. Ports 443 and 8443 are opened for traffic.

This image requires acceptance of the Java License Agreement (

Image Goal

The goal behind this Dockerfile image is to provide a demonstrably secure end-to-end deployment of every component (Java, Jetty, Shibboleth IdP, and extensions). Each downloaded component is verified against cryptographic hashes obtained from each vendor and stored in the Dockerfile to make the build essentially deterministic. Because of the deterministic nature of the build, users should feel confident in using this Dockerfile/image either directly or as a base for applying their configuration on top of, assuming the Centos7 base and Docker Registry are trusted.


Two methods of using the image described here.

Using as a Base

This image is ideal for use as a base image for ones own deployment.

Assuming that you have a similar layout with your configuration, credentials, and war customizations. The directory structure could look like:

|-- .dockerignore
|-- Dockerfile
|-- conf
|   |-- attribute-filter.xml
|   |-- attribute-resolver.xml
|   |-- credentials.xml
|   |--
|   |--
|   |-- login.config
|   |-- metadata-providers.xml
|   |-- relying-party.xml
|   |-- services.xml
|-- credentials
|   |-- idp-backchannel.crt
|   |-- idp-backchannel.p12
|   |-- idp-encryption.crt
|   |-- idp-encryption.key
|   |-- idp-signing.crt
|   |-- idp-signing.key
|   |-- sealer.jks
|   |-- sealer.kver
|-- keystore
|-- metadata
|   |-- idp-metadata.xml
|-- webapps
    |-- images
    |   |-- dummylogo-mobile.png
    |   |-- dummylogo.png
    |-- WEB-INF
        |-- web.xml

Next, assuming you create a Dockerfile similar to this example:

FROM jtgasper3/shibboleth-idp

ADD conf/ /opt/shibboleth-idp/conf/
ADD credentials/ /opt/shibboleth-idp/credentials/
ADD metadata/ /opt/shibboleth-idp/metadata/
ADD webapp/ /opt/shibboleth-idp/webapp/

ADD keystore $JETTY_BASE/etc/keystore

This will take the base image that is available in the Docker repository and download it. Next, it overrides all of the base files with your local configuration.

The dependant image can be built by running:

docker build --tag="<org_id>/shibboleth-idp" .

Now, just execute the new image:

$ docker run -dP --name="shib-local-test" org_id/shibboleth-idp

The -v parameter is not needed as in the other case because there is no need to import/export the configuration. It could still be used to create a mount point for log files.

Appliance Use

This will use the default container storage to store the idp configuration.

Starting the container

$ docker run -dP --name="idp-test" -v ~/docker/shib-config:/external-mount jtgasper3/shibboleth-idp

If you do not have an existing configuration to import, after starting the container you must run:
$ docker exec -it idp-test
Otherwise you will be running with a well-known (unsafe) encryption/signing key. (Be sure to restart the container to accept the new config.)

Importing an existing configuration

Update the Jetty/Shibboleth config by importing an existing configuration into a running container:

$ docker exec -it idp-test

Press enter to confirm the installation directory, then stop the container and restart it to pick up changes.

Exporting the current configuration

Besure to export any changes and store them elsewhere. If a container is deleted before you export your config, signing/config keys will be losts.

$ docker exec idp-test

Misc Notes on Execution

The Shibboleth IdP logs can be explicitly mapped to local storage by adding -v /local/path:/opt/shibboleth-idp/logs when starting the container.

Other advance docker storage strategies are also possible.

Container Settings

Jetty's Maximum Heap Size Setting

By default this container will execute Jetty with a setting 512m for Java's Maximum Heap Size. This can be overridden by runing the container using the -e JETTY_MAX_HEAP flag like so:

docker run -dP -e JETTY_MAX_HEAP=1g shibboleth-idp

All values must conform to java's -Xmx values.


From source:

$ docker build --tag="org_id/shibboleth-idp"



The following references provided some form of guidance for this project:


Copyright 2015 John Gasper

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
See the License for the specific language governing permissions and
limitations under the License.

Docker Pull Command
Source Repository

Comments (0)