Shibboleth Idp3 as docker install on AWS

Ryan Rumbaugh rrumbaugh at
Fri May 15 12:23:59 UTC 2020

In our case, containers and their orchestration has helped us tremendously. If you support just one IdP, with a small team or a team of one, then I don't see much benefit with the Shib IdP container (other than exposing you to Docker and container concepts). I suppose it lets you bypass the installation of Shib in a way, but you still need to what you are doing to the extent you are placing the right configuration files in the right places (Tomcat & Shib).

For us, we support six IdP's with a team of five and every member of the team, all at various levels of experience, technical knowledge, and not necessarily dedicated to SSO, are capable of onboarding new services via configuration changes and getting them deployed to our test/staging servers by merging feature branches in Gitlab into a specific IdP branch. Six IdP's means we have 12 production containers all running on Docker Swarm and 12 more for test. When we inherited the six IdP's all were at various versions of you name it, (java, linux, tomcat, jetty) so the use of ITAP containers helped us standardize as well.

What using containers will eventually allow us to do is scale those out rather easily. Admittedly we are not quite there yet, but what we're working towards is being able to either predict heavy demand (course drop/add, high enrollment) and scale our services up or down appropriately.

Using containers has also given members of the team experience with Docker, CI/CD, and orchestration to the extent that managing our ITAP Grouper Swarm containers is a piece of cake. 

Ryan Rumbaugh


On 5/14/20, 9:37 AM, "users on behalf of Joseph Fischetti" <users-bounces at on behalf of Joseph.Fischetti at> wrote:

    Non-NU Email

    The way I've always handled it is that Tomcat points to a symlink for the current deployment.
    Update the symlink and restart tomcat to switch deployments.
    Rollback is just as simple.

    It's also not immutable, so you can make configuration changes and utilize reloadable services on the fly.

    Pushing from test to prod is as simple as tar -> scp -> untar -> symlink, which is all scripted.

    Docker sounds like unnecessary overhead and complexity in this case.  Perhaps I'm missing something.
    For Consortium Member technical support, see 
    To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list