CentOS-based container which serves up InCommon metadata via MDQ
Shell
Switch branches/tags
Nothing to show
Latest commit 3ab0efb Mar 19, 2018 @pcaskey pcaskey committed on GitHub Enterprise Update README.md
Permalink
Failed to load latest commit information.
container_files sync timestamps Feb 20, 2018
Dockerfile sync timestamps Feb 20, 2018
LICENSE create LICENSE Feb 19, 2018
README.md Update README.md Mar 19, 2018

README.md

Internet2 MDQ Appliance

This CentOS-based container provides an InCommon Per-Entity Metadata server.

It downloads, validates, and verifies the InCommon aggregate, then creates per-entity metadata files and digitally signs them using a key/cert that is generated dynamically on the first run, unless already present (as a result of a container orchestration system, etc).

The generated self-signed certs (signing + www), if used, are 10-year certificates and you can control the subject of the certificates by setting the following 2 environment variables:
CERTGEN_MDQSIGN_SUBJECT
default: /C=US/ST=State/L=City/O=OrgName/CN=mdqsigning.example.org
CERTGEN_WWW_SUBJECT
default: /C=US/ST=State/L=City/O=OrgName/CN=mdqweb.example.org

It can be run with the following command (on a docker-enabled linux host):
docker run -d -p 443:443 tier/mdq-appliance

The container will listen on port 443 (https).

The signing cert is available from /cert.

The container will take a few minutes to start on the initial launch. Watch the logs for the message "Metadata generation complete." (or watch the Docker health status)

Per-entity metadata is automatically updated nightly (job time is randomized on container build between midnight and 5am).

To have the container sign metadata using your own key/cert, overlay the following 3 files at run-time:

  • /keys/mda-signing.key
  • /keys/mda-signing.crt
  • /mda/inc/inc-cert/build.properties (copy from existing repo and include the key's password in the 'sign.uk.keyPassword' property)

To have the container use your own SSL certificate (should be different than the signing cert/key), overlay the following 2 files at run-time:

  • /etc/pki/tls/private/mda-signing-ssl.key (should not be password-protected)
  • /etc/pki/tls/certs/mda-signing-ssl.crt

You can test the server with the following curl commands:

The entire aggregate:
curl -k -I https://127.0.0.1/entities

The entire aggregate, with compression:
curl -k -I -H "Accept-Encoding: gzip" https://127.0.0.1/entities

A specific entity via the URLencoded entityID (picked at random):
curl -k -I https://127.0.0.1/entities/http%3A%2F%2Fadfs.amolf.nl%2Fadfs%2Fservices%2Ftrust

A specific entity via the URLencoded entityID, with compression:
curl -k -I -H "Accept-Encoding: gzip" https://127.0.0.1/entities/http%3A%2F%2Fadfs.amolf.nl%2Fadfs%2Fservices%2Ftrust

A specific entity via the SHA1 hash of the entityID:
curl -k -I https://127.0.0.1/entities/%7Bsha1%7D3e00cf93cb2ce85618e4a448060124021fae9cfc

A specific entity via the SHA1 hash of the entityID, with compression:
curl -k -I -H "Accept-Encoding: gzip" https://127.0.0.1/entities/%7Bsha1%7D3e00cf93cb2ce85618e4a448060124021fae9cfc

The certificate to be used for verification of the signatures on the per-entity metadata:
curl -k -I https://127.0.0.1/cert