Let Your Docker Containers Speak

If you are like me, you have probably come to the same conclusion that Docker does wonders with the automation of much of the needed infrastructure while working on a particular development task. For example, I primarily keep myself busy in the realm of Identity and Access Management (IAM) and there does not a day go by where I find myself in need of a running SAML service provider, a CASified PHP application protected by mod_auth_cas running inside Apache, or a full blown Grouper deployment for which I might be trying to add a changelog consumer, etc.

Docker can automate and (more importantly) isolate all of that noise, allowing me to focus on the task at hand. Today and while I have opted for both approaches given context and need, my preference is to keep the core platform/application I am working on outside the running Docker ecosystem while leaving all of the stuff-I-need-for-the-integration components inside. I find that this strategy allows for faster builds and more performant/natural debugging and diagnostics. However, one problem I run into often is: how do I connect the two separate environments? Or put another way, how do I let a component running in Docker make a back-channel call to something outside running on the host?

Being so far away from home can be challenging. This blog is about that problem.

That Problem

My docker setup usually is based on this project, which is the wonderful produce of my esteemed colleague, @jtgasper3. As the perfect IAM testbed, it is composed (catch the pun?) of an LDAP server, a Shibboleth SP, Apache httpd, a CASified PHP application, simpleSAMLphp, a Shibboleth IdP and possibly more.

I simply enable/disable components I need running in the package and viola! It takes care of the rest. I am not going to bore you with all the intricate details of how this is all organized docker-wise, but one thing that is perhaps relevant is that each running component is tagged with a networks configuration that simply controls the application networking via custom networks where each can be linked to a driver configuration (i.e. bridge, the default for the Docker engine). This might come in handy, should you decide to go fancier and beyond what I explain here for a solution.

Long story short, the issue had to do with the dockerized Shibboleth SP unable to make a SOAP query to my IdP running outside. If you think about it, this sort of makes sense. What runs inside does not necessarily know anything about what’s on the outside. It might seem like everything is simply running on the same machine, but localhost for you, an outsider, is a very different unknown to the Shibboleth SP container running in its own network.

I needed an inside man.

One Solution

I am convinced there are better solutions that muck around with native docker networking configuration, bridging host and container. Indeed, one can set up extra hosts, perhaps define a host network mode of some kind, etc. Who knows! That was a rabbit hole I didn’t want to venture into and so I settled for the following simpler albeit temporary solution.

export DOCKERHOST=$(ifconfig | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | \
                  grep -v | awk '{ print $2 }' | \
                  cut -f2 -d: | head -n1)

If you open up your terminal and run that command, you might see something like:


Sweet! Next, I was able to modify the relevant configuration files and use anywhere the dockerized Shibboleth SP needed to make a call to the outside world. While this works fine, I should note that it is absolutely a temporary solution as hardcoding an IP address that might change later on obviously is a broken path but it did suffice my development needs at the time.

Post-credits Scene

…and oh, if you need to find a quick way to SSH into a running Docker container, put the following in your profile:

function dockerssh() {
    export CID=$(docker ps -aqf "name=$1"); docker exec -it $CID /bin/bash

Then use as follows:

dockerssh [container-name]

…and you’re in.


Misagh Moayyed

Related Posts

Apereo CAS - Extending Webflows

Learn and master extending CAS 5 Spring Webflow definitions.

Apereo CAS - Administrative Endpoints & Monitoring

Gain insight into your running Apereo CAS deployment in production. Learn how to monitor and manage the server by using HTTP endpoints and gather metrics to diagnose issues and improve performance.

Apereo CAS - Custom Authentication & Attribute Sources

Master writing custom authentication handlers/schemes in CAS and learn how to design custom data sources that can produce user claims and attributes.

Apereo CAS - User Interface Customizations

A short tutorial on Apereo CAS user interface customizations, including themes, localization and dynamic views for all those who enjoy front-end development and suffer from instant gratification.

CAS Multifactor Authentication with Google Authenticator

A short walkthrough to demonstrate how one might turn on multifactor authentication with CAS using Google Authenticator, leveraging a variety of triggers.

CAS 5.3.x Deployment - WAR Overlays

Learn how to configure and build your own CAS deployment via the WAR overlay method, get rich quickly, stay healthy indefinitely and respect family and friends in a few very easy steps.

CAS 5.3.0 RC4 Feature Release

...in which I present an overview of CAS 5.3.0 RC4 release.

Apereo CAS - Identity Impersonation

You do not always have to be you. Allow the Apereo CAS server to allow you to pretend to be another person for fun and profit.

Apereo CAS - Customized Settings

Extend the Apereo CAS server to allow custom configuration properties and settings.

Apereo CAS - Handling Multiple Logout URLs

Extend the Apereo CAS server to allow for multiple logout URLs during SLO operations.