Config choices for tier/shibbidp_configbuilder_container

Darren Boss darren.boss at
Wed Oct 2 08:45:29 EDT 2019

This might not be the right forum for discussing the configuration choices
in the tier/shibbidp_configbuilder_container image but they caused me some
frustration and I'm curious to know if this was a purposeful decision or
possibly some of this configuration was accidentally left in.

In the profile-intercept.xml file the intercept/attribute-release has an
activation condition related to a FERPA attribute which only enables the
attribute release consent flow if it finds this attribute to be true/yes. I
had done some modifications in the intercept configuration so when I was
trying to get my configuration working with the tier/shib-idp image, I was
assuming that it was something in my own configuration that I had messed up
or not merged into the configuration generated by the config builder. Seems
like an odd decision to only trigger attribute release consent only when a
FERPA attribute is present for a user.

That being said, I'm very pleased to see the docker images for many of
these projects being built via CI and available to the community. One thing
I'd like to see is the images run the services under a non-root account.
You wouldn't run the tomcat or jetty server as root on a virtual machine so
why run as root in the containerized deployment.

I haven't done an empirical test yet but it does seem like the tier/tap
image is loading a lot faster than what I was experiencing with the
Unicon shib image I was basing my deployment on previously. That is likely
due to the change in the JVM used (Azul vs. Corretto). I've been able to
drop my initial delays for the Kubernetes health probes way back from what
I was previously using even with Jetty tweaks in place.
Darren Boss
Senior Programmer/Analyst
Programmeur-analyste principal
darren.boss at
(o) 416.228.1234 x 230
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list